On Sun 27 Oct 2024 at 11:26:12 (-0700), pe...@easthope.ca wrote: > A search of "os-prober security" finds several pages. os-prober is > disabled by default in Archlinux and other respected distributions. > > For interest, I enabled os-prober again in /etc/default/grub and ran > grub-install /dev/sda. lsblk reports the USB connected /dev/sdc6 > where Void is installed. Nevertheless the only stanza in > /boot/grub/grub.cfg for Void is from my entry in > /etc/grub.d/40_custom. Os-prober tried and failed. > > A bug in os-prober? A problem with the HDD? A problem with the > SATA-USB2 adapter? A bug in grub2?
Well, it could be because Void apparently isn't a glibc OS. You could check /usr/lib/os-probes/mounted/90linux-distro to see whether the first test would succeed. Or a lazy way: type set -x before you run os-prober and set +x afterwards, and track what it does. You'd probably want to capture the output as it could be voluminous; it looks for linux systems just about last. > An interesting observation is that the USB-connected Void system boots > with no snags when selected directly in the BIOS. To me, that > suggests a problem in grub2 or os-prober. Well, it's presumably not Grub, as you say you can boot Void from your handcrafted menuentry once you've booted into the correct grub.cfg. As for os-prober, it's caught between a rock and a hard place: if it makes wild guesses so that it can always write some crap menuentry, then it's going to be highly insecure. OTOH if it carefully searches for files it recognises, before crafting its menuentry, then it's going to fail on an OS that uses different software, or an unexpected layout, or whatever. In that case, the idea with FOSS is that an early adopter writes and submits a patch in order to increase its repertoire. BTW I forgot to mention, your Grub ls command, which you reported on earlier, will fail to see the Void OS because there's no insmod part_gpt command in the grub.cfg until you press Return on the Void menuentry. So that's ok for booting the Void entry, but up until that moment, Grub can't read GPT partition tables without the part_gpt. So type an insmod part_gpt command first, if you need to type ls. > Rather than spend more time investigating, will put the HDD in the > target machine and work there. I hadn't realised there was one. BTW I assume your second disk, being GPT, has a BIOS Boot partition? Or is this target machine going to boot with UEFI, in which case you need an EFI partition. I think moving disks between differently booting machines can be "fun"; it's why my own disks typically have both a BIOS Boot partition and an EFI partition. The former is only 3MB and ends at sector 8191; the latter can be borrowed for swap in MBR machines. Cheers, David.
