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 <[email protected]> OpenPGP ID 0xEB04D09C _______________________________________________ Help-grub mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-grub
