Re: Issue with Super Grub2 Disk Hybrid and HP Detachable X2

[Michel Bouissou]

Hi Adrian,

(Still about Super Grub2 key on HP Pavilion Detachable X2 10-N123NF, per
your request)


Le 14/12/2017 à 07:32, adrian15 a écrit :
> It's booting with grub2. Works good. Never had any BIOS issue.
> I understand. You are saying that it's booting with Manjaro's grub2.
Yes. That's grub version 2.02.0-3 from Manjaro's original package,
installed on system.

(I had no trouble with installing other, earlier Linux versions also
using grub, such as Mint 17.x onto said system)
>
>> - Tried the "Detect and show boot methods" option : Screen went black
>> with the USB key access LED blinking fast, so I thought it was doing
>> something... But after 10 minutes it still was, and then I had no other
>> solution than to power-cycle the machine the hard way again.
> I see. Well, sometimes, Super Grub2 Disk takes a while to find all the
> installed Operating Systems. Do you have anything else than Manajaro in
> your system? Maybe many EFI files or many ISO files at /boot/boot-isos/ ?
No. Manjaro is (currently) alone on the machine.

The machine has a (main) 32 GB eMMC on which the OS is installed, plus
an USB-connected HD in the detachable keyboard. This on is fully
encrypted so grub won't find anything there.

The EFI partition holds 3 directories :

- "Manjaro", containing grubx64.efi, which is the default boot entry

- "HP", containing subdirs "BIOS", "BIOSUpadte", "HP SUpport Framework"
and "SystemDiasg" : System manufacturer's stuff that I didn't dare
touching  ;-)

- "Boot", containing bootx64.efi, which I assume to be the original
Windows bootloader remains. I leave it there because I sometimes swap
Linux for Windows back and forth - using system clones I hold on the
additional encrypted HD.

The installed Manjaro's grub has only config entries for booting Manjaro
(2 kernels in normal or rescue mode). Very classic.
> You can alternatively use the option: Boot Manually -> Operating Systems
> so that in only searches kernels (and not sources grub.cfg files).
>
> In such case do you happen to find also the UEFI CMOS memory corrupt
> warning (that you describe in a moment) ?
5 minutes of black screen with blinking USB key LED. Then power cycle
the hard way. No UEFI corruption on reboot.

I have to add that the corruption I noticed the other day doesn'nt
necessarily happen *every* time : the first tim I had noticed SG2 die
into a black screen, I had rebooted and it was OK. It was on the 2nd
same attemp that the BIOS complained about CMOS corruption...

I have a supposition about the reason that may confuse SG2 on this
machine : it's « hard disk » is not a hard disk and is not called /dev/sd*

Being an eMMC, it's called /dev/mmcblk0, gpt partitioned and gdisk shows
it partitioned as :
- /dev/mmcblk0p1 : 260 MB EF00 EFI partition
- /dev/mmcblk0p2 : 16 MB "Microsoft reserved" that I didn't touch, it
being small
- /dev/mmcblk0p3 :  28 GB Linux main ext4 partition
- /dev/mmcblk0p4 : 1 GB Linux swap

But ls also shows :
- /dev/mmcblk0boot0
- /dev/mmcblk0boot1
- /dev/mmcblk0rpmb

I have no clue about these, which partitioning tools do not see, while
they do appear under /dev. When cloning the machine using clonezilla, it
complains not being able to read it, but just skips it.

Maybe SG2 doesn't like this kind of systems ?

(BTW how would it behave with a system running on /dev/nvme* ?)
>> - After deactivating it the machine would accept to boot Manjaro again,
>> BUT while booting I noticed it doing unusual fsck stuff...
> Maybe it was mounted more than X days ago or N times?
No, this is ext4 with a “maximum mount count” set to -1 and “check
interval” to 0-none. So it doesn't usually fsck it.

>
> In the meanwhile you could test all the options of the current SG2D
> 2.02s10-beta5 version, one after another, in the "Boot Manually" menu
> till you find which one is the culprit.
>
> In theory, if my suspicion is right the culprit option would be:
> "grub.cfg - Extract entries".
- Operating Systems : Black screen failure
- grub.cfg - Extract entries : Black screen failure
- grub.cfg - grub2 configuration file : Black screen failure
- menu.lst : Black screen failure
- core.img : Black screen failure
- Disks and Partitions (Chainload) : Black screen failure
- Bootable isos : Black screen failure

It shows a quite consistent behaviour when it comes to searching for
things on "disk"...

You see I had to power cycle it a number of times, but didn't see the
CMOS corruption happen again...

HTH.

Kind regards.

ॐ

-- 
Michel Bouissou <address@hidden> OpenPGP ID 0xEB04D09C