SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
the day will come when it clears out and blacklists all keys in nvram. Then Alien's liveslak or slackware won't boot because it's key has been blacklisted.
As far as I understand it, the Microsoft signing keys that were used to sign vulnerable bootloader binaries will be blacklisted. As a consequence, those vulnerable bootloaders will no longer be allowed to boot your computer because its signing public key is gone.
But Alien Bon signs his bootloader with his own (non-microsoft) key, which is why you have to import his certificate (the public key) into the MOK. His certificate will therefore remain usable and liveslak ISOs remain bootable under Secure Boot.
The next time I decide to upgrade and find no decent motherboards have CSM/Legacy included or force Secure Boot, I intend to resort to UEFItool (modern version of modbin as I understand it) and have my way with it.
The next time I decide to upgrade and find no decent motherboards have CSM/Legacy included or force Secure Boot, I intend to resort to UEFItool (modern version of modbin as I understand it) and have my way with it.
Usually, the Secure Boot only motherboards has no CSM/Legacy module in UEFI because I guess it makes no sense in this design.
Distribution: Slackware64 {15.0,-current}, FreeBSD, stuff on QEMU
Posts: 458
Rep:
Quote:
Originally Posted by business_kid
Then Alien's liveslak or slackware won't boot because it's key has been blacklisted. But I can boot windows 11 (hurray). I then do what exactly?
Surely, he'd acquire a new shim when and if that happens. This whole mess is just one more reason why Windows belongs on VMs and not bare metal, so far as I'm concerned.
Surely, he'd acquire a new shim when and if that happens. This whole mess is just one more reason why Windows belongs on VMs and not bare metal, so far as I'm concerned.
In fact, all he will do will be the downloading of a new shim package from Fedora repos.
Anyway, considering the whole mess of Slackware's boot managers and kernels management, the replacing of 2 EFI binaries in the ESP would be rather a fart in the wind...
People, let's be honest. IF by the grace of Santa Claus, overnight all Windows users would start using Slackware, each day in this forum would be over 10000 new threads about broken boots.
And yes, I know about what I talk, because I have used various Microsoft software since I have built from scratch my first IBM PC/XT compatible. It was 40 years ago, or something. In fact, even before, because the first seen Microsoft software was games for a Z80 computer, also built from scratch. Lots of fun and soldering in that old times.
Hey, the people still do this from scratch. This video bellow made me remember of that old days.
As far as I understand it, the Microsoft signing keys that were used to sign vulnerable bootloader binaries will be blacklisted. As a consequence, those vulnerable bootloaders will no longer be allowed to boot your computer because its signing public key is gone.
But Alien Bon signs his bootloader with his own (non-microsoft) key, which is why you have to import his certificate (the public key) into the MOK. His certificate will therefore remain usable and liveslak ISOs remain bootable under Secure Boot.
Aahh. If that's wrong, please correct it. If that's right, It nicely dispels all the FUD, and I can relax. In fact the only ones who get caught then are the the distros who sucked up to M$ in the first place and had their shim registered.
As for modern boxen not working on Legacy, they probably do work on legacy. You need
the box set on legacy
No gpt disks but at least one MBR one.
An old fashioned boot loader.
Most folks forget the MBR formatted disks, and the old fashioned boot loader.
Last edited by business_kid; 05-17-2023 at 09:34 AM.
No bootloaders weren't that complicated but every other week you got the Form boot virus, or Ping Pong, or half a dozen others. I was lucky enough to avoid having my BIOS chip overwritten on pc & laptop because I ran a checker for the CIH boot virus on April 23rd. The thing would overwrite the BIOS on April 26th! If I had suffered those consequences it would have been very difficult for my business.
Maybe I've misunderstood you, business_kid, but I have two different disks, one NVME and the other an SATA "spinner", both formatted with GPT partitioning and between them they have 6 Linux operating systems that boot from LILO, not elilo, LILO.
Maybe I've misunderstood you, business_kid, but I have two different disks, one NVME and the other an SATA "spinner", both formatted with GPT partitioning and between them they have 6 Linux operating systems that boot from LILO, not elilo, LILO.
You hardly have uefi in your BIOS, then?
EDIT: 40 Posts in this thread, with 53 "found this post useful" recommendations. Is that a record?
Last edited by business_kid; 05-18-2023 at 05:41 AM.
As for modern boxen not working on Legacy, they probably do work on legacy. You need
the box set on legacy
No gpt disks but at least one MBR one.
An old fashioned boot loader.
It should work with gpt too, because gpt disks have a dummy mbr where you can load a small bootloader like LILO. It's a bit trickier with GRUB2 because only a stub goes in the mbr and the rest has to go somewhere else. On an mbr disk, it goes in the gap that's traditionally left between the mbr and the first partition, but on a gpt disk you need a separate first partition labelled as bios-boot and without a filesystem on it. Messy but doable.
It should work with gpt too, because gpt disks have a dummy mbr where you can load a small bootloader like LILO. It's a bit trickier with GRUB2 because only a stub goes in the mbr and the rest has to go somewhere else. On an mbr disk, it goes in the gap that's traditionally left between the mbr and the first partition, but on a gpt disk you need a separate first partition labelled as bios-boot and without a filesystem on it. Messy but doable.
Doable, as you wrote, and not so messy. In the code snippet below extracted from the current Slint intaller EFI is set only it the directory /sys/firmware/efi exists at time of installation:
Code:
gettext "Installing the GRUB bootloader..."
# Install with --target=i386-pc except in case of a GPT if no BIOS boot partition is available
# in the same drive as the root one, which is allowed in manual partitioning mode and EFI booting.
echo
INSTALLINLEGACYMODE="yes"
if [ "$(lsblk -lno pttype "$DRIVEPATH"|head -n 1)" = "gpt" ] && \
! lsblk -lno parttypename|grep -q 'BIOS boot'; then
unset INSTALLINLEGACYMODE
fi
if [ "$INSTALLINLEGACYMODE" ]; then
chroot $SLINT grub-install --target=i386-pc "$DRIVEPATH" 1>>$INSTALL/log 2>>$INSTALL/errors
fi
# Install with --target=x86_64-efi except if there is is no ESP in the same drive as the root one.
if [ "$AUTO" ] || [ -f $INSTALL/esppath ]; then
if [ "$EFI" ]; then
chroot $SLINT grub-install --target=x86_64-efi --bootloader-id=slint-$SLINTVERSION "$DRIVEPATH" 1>>$INSTALL/log 2>>$INSTALL/errors
else
chroot $SLINT grub-install --target=x86_64-efi --no-nvram --bootloader-id=slint-$SLINTVERSION "$DRIVEPATH" 1>>$INSTALL/log 2>>$INSTALL/errors
fi
cp $SLINT/boot/efi/EFI/slint-$SLINTVERSION/grubx64.efi $SLINT/boot/efi/EFI/BOOT/BOOTx64.EFI
echo "EFI\slint-$SLINTVERSION\grubx64" > /SLINT/boot/efi/startup.nsh
fi
This way the installed system will boot in both EFI and Legacy modes regardless of the partition table type, except if the user chose to manually partition the drive but:
in case of a GPT did not set up a BIOS boot partition it will not boot in Legacy mode
did not set up en EFI system partition it will not boot in EFI mode
Last edited by Didier Spaier; 05-18-2023 at 11:52 AM.
Sound a bit too much like work to me. The one laptop I messed with much here (A Samsung) was very strict about enforcing UEFI on a gpt disk. I believe Dell had a handier BIOS. What have you got?
Sound a bit too much like work to me. The one laptop I messed with much here (A Samsung) was very strict about enforcing UEFI on a gpt disk. I believe Dell had a handier BIOS. What have you got?
In my computer's firmware setting menu the user can set the machine to boot either in EFI mode only or in EFI as well as in Legacy modes, regardless of the partition table type. Thus if I display the firmware's boot menu at startup I can choose to boot off the same drive in either legacy or EFI mode just selecting the relevant boot entry. This comes very handy for testing various configurations.
Last edited by Didier Spaier; 05-18-2023 at 08:45 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
). I then do what exactly?
