Puppy Linux Discussion Forum

More mysteries to solve...

Considering my recent-ish PC: i5-12400, 16G RAM, 2T SSD, NVIDIA GeForce GT 730...

'The shop' set-up the PC with Windows 11 Home in a 'standard' way with GPT on the SSD... and I've created some partitions myself:

sda1:                   TYPE="vfat"  PARTLABEL="EFI system partition"
sda2:                                PARTLABEL="Micro$oft reserved partition"
sda3:  LABEL="Win11-64" TYPE="ntfs"  PARTLABEL="Basic data partition"
sda4:  LABEL="Data-1"   TYPE="ntfs"  PARTLABEL="Basic data partition"
sda5:  LABEL="Data-2"   TYPE="ntfs"  PARTLABEL="Basic data partition"
sda6:                   TYPE="ntfs"  (Micro$oft recovery)
sdb1:  LABEL="F96-CE_4" TYPE="vfat"  (flash LiveUSB)
sdc1:  LABEL="Backup-2" TYPE="ntfs"  (USB HDD) 
sdd1:  LABEL="Backup-1" TYPE="ntfs"  (USB HDD)

I set-up a 'LiveUSB' flash drive using 'frugalpup' (I think it was) so that I can use the LiveUSB to boot many 'frugal' installations of Puppy variants using grub, both on the USB itself and through directories on the 'Windows' partition.

I didn't change the boot order in the BIOS/UEFI so I have to 'press a key' at boot time to select the LiveUSB and boot a Puppy variant.

I got sick of this(!), so I changed the boot order in the BIOS/UEFI and leave the LiveUSB always inserted in a USB3 port... but now, some partitions seem to have gone missing, making the grub configuration such that nothing boots.

Working around in the 'grub>' prompt (where this fool fears to tread) led to these discoveries:-

Original BIOS/UEFI Settings		Revised BIOS/UEFI Settings    
---------------------------		--------------------------

Boot order: 				Boot order: 
  - Internal SSD			  - USB drive
  - USB drive				  - Internal SSD
  					  
grub> ls				grub> ls

(memdisk) 				(memdisk) 
(hd0) (hd0,msdos1)			(hd0) (hd0,msdos1)
(hd1) (hd1,msdos1)			(hd1) (hd1,msdos1)
(hd2) (hd2,msdos1)			(hd2) (hd2,msdos1)
(hd3) (hd3,gpt6)
(hd3) (hd3,gpt5)			grub contents that FAILS:
(hd3) (hd3,gpt4)			   linux (hd3,gpt3) ...
(hd3) (hd3,gpt3)
(hd3) (hd3,gpt2)
(hd3) (hd3,gpt1)

grub contents that WORKS:
   linux (hd3,gpt3) ...
 

So, is there something that I need to update in the BIOS/UEFI *OR* something I need to add in grub.cfg so that the GPT partitions are seen in the 'Revised' set-up?

The guts of the grub.cfg file:-

loadfont /boot/grub/font.pf2
set gfxmode=800x600
set gfxpayload=keep

insmod efi_gop
insmod efi_uga

insmod all_video
insmod video_bochs
insmod video_cirrus
insmod gfxterm
insmod png
insmod jpeg
terminal_output gfxterm

insmod ext2
insmod f2fs
insmod ntfs
insmod exfat

insmod loopback
insmod iso9660
insmod udf

background_image /boot/splash.png
set timeout=20
set default=2

color_normal=light-gray/black
menu_color_normal=light-gray/blue
menu_color_highlight=yellow/green

menuentry "Puppy Linux - F96-CE - frugal (on USB)" {
    linux /vmlinuz pmedia=cd pfix=fsck 
    if [ -e /ucode.cpio ]; then
      initrd /ucode.cpio /initrd.gz
    else
      initrd /initrd.gz
    fi
}

menuentry "PROD - Puppy Linux - F96-CE - frugal - chiron (on sda3)" {
   linux (hd3,gpt3)/Puppy/F96-CE/vmlinuz pfix=fsck pmedia=atahd psubok=true psave=sda3:/Puppy/F96-CE/
   if [ -e /ucode.cpio ]; then
      initrd /ucode.cpio (hd3,gpt3)/Puppy/F96-CE/initrd.gz

   else
      initrd (hd3,gpt3)/Puppy/F96-CE/initrd.gz
   fi
    
}

[ . . . ]

I'd appreciate any clues anyone can suggest... Thanks.

My first thought would be to scrap the (hdx,gpty) notation and use uuids. That avoids problems with the order in which the drives are enumerated. For example:

search --no-floppy --fs-uuid --set=root aaa-bbb-ccc
linux /vmlinuz ....

rcrsn51 wrote: ↑Sun Oct 13, 2024 2:55 am

My first thought would be to scrap the (hdx,gpty) notation and use uuids. That avoids problems with the order in which the drives are enumerated. For example:

search --no-floppy --fs-uuid --set=root aaa-bbb-ccc
linux /vmlinuz ....

Good thought... and works as suggested when the boot order is (SSD, USB)... but the same fundamental problem occurs when the boot order is changed. That is, even via UUID, grub can't find the disks.

I wonder if it might involve the old (I think?) requirement that a bootable partition needs to be the first partition on the physical disk to be seen and usable by grub?

The investigations continue...

Next exploration:

Cold boot
setup: Boot order: USB, SSD
exit setup, save changes
boot
grub -> grub> ls ... GPT available
reboot
grub -> grub> ls ... NO GPT available
reboot
setup: (nothing)
exit setup, not saving changes
grub -> grub> ls ... GPT available
shutdown
cold boot
grub -> grub> ls ... NO GPT available

So, simply entering the BIOS/UEFI 'does something' to allow the GPT disks to become visible.

Like most manuals (at this technical level), the BIOS/UEFI manual is as clear as mud in a beer bottle... but I've tried with and without the CSM being enabled/disabled and the same silliness with grub goes on.

The mind bending continues...

Have you tried making the USB drive GPT?

It's my understanding that GRUB doesn't "discover" drives on its own - it just uses information it gets from the BIOS/UEFI. So the real culprit here may be the UEFI firmware. It may be deciding that if you boot off an external drive, it won't show you the internal drive for security reasons.

That doesn't make a lot of sense, but I have seen many other things in UEFI implementations that didn't make sense either. Remember that the primary purpose of a UEFI setup is to boot Windows. Anything else is an afterthought.

It would be interesting to see what happens on a different machine. All UEFI firmware is different.

I tried this myself with partial success.

On my ISObooter USB drive, I added a GRUB menu entry for a Starter Kit install on the internal GPT drive.

I booted off USB and selected the Starter Kit. It booted correctly off GPT.

But on the next boot, the UEFI firmware ignored my changes and booted off the internal Windows.

I might have been able to run efibootmgr and change the internal UEFI boot order to prefer the USB drive, but I didn't want to risk killing Windows.

BTW, this setup will boot Puppy, KLA and other forum distros with Secure Boot turned ON.

@rcrsn51

I think 'frugalpup' only installs grub onto MBR partitions... but getting into the guts of frugalpup is 'beyond scope' (having had a token look).

Looking at the grub docs (see https://www.gnu.org/software/grub/manua ... index.html), it seems there's a probe command which would force the finding of GPT disks... but the frugalpup I've used under F96-CE seems to use grub 2.04 and probe only seems to be available in 2.12 (that's the version referred to in the docs above). Again, getting into grub 'proper' is 'beyond scope'.

I tried using this 'LiveUSB' on another PC and going through its 'boot menu' was more weird, in that it couldn't see the LiveUSB when trying to do a legacy boot (given the LiveUSB has a MBR boot partition containing grub)... but it worked Ok repeatedly going through the boot menu when booting the LiveUSB via UEFI. I tried a 'what seemed sensible' change to the boot order in this other PC... but it wouldn't boot at all (found no OS)... and, like you, I don't want to risk making a mess of the 'working' setup on this other PC (internal MBR partition with grub 2.04 that boots local Windows 10 and multiple Puppy variants).

Interesting that you had more-or-less the same behaviour where the first (cold?) boot worked but subsequent boots did not. It again points to BIOS/UEFI's being 'strange'... or at least their interactions with grub are so...

I'll keep looking a bit.. but I have various Puppies whining for other reasons that need to be dealt with sooner...

Thanks again for helping out...

Many Win7 machines had early UEFI implementations that were pre-SecureBoot and came from the factory in legacy mode. Switching them now to UEFI can be an adventure. They will often make their own decisions on how to boot depending on what they see on your drives.

rcrsn51 wrote: ↑Mon Oct 14, 2024 12:57 pm

Many Win7 machines had early UEFI implementations that were pre-SecureBoot and came from the factory in legacy mode. Switching them now to UEFI can be an adventure. They will often make their own decisions on how to boot depending on what they see on your drives.

Yup.. The 'other' computer is a Dell Optiplex 9020, so I think that's ~2013 vintage... and the 'current' computer is roughly 2023 (mix of 2022/2023 hardware)... So, it's kinda curious that the older PC/BIOS/UEFI is perhaps behaving sortof more 'consistently'...

The mind boggles...

Anyway, I'll try making another LiveUSB and keep exploring...