Slackware-Current
Forum rules
Behave
Behave
Slackware-Current
I have Slackware back! The installer kept selecting the wrong EFI partition, the one from Arch, and I didn't want it touching that so I did not let it install elilo. At the end of the installation I dropped back out to the console chrooted into /mnt (the new install root still mounted by the installer) and edited fstab, umounted /boot/efi then mounted the correct partition to /boot/efi, and then ran eliloconfig. That fixed it. It also shows up in the motherboard's UEFI menu. The last time I installed Slackware I had to manually format the EFI partition, and I had to do that again this time. I don't know why the installer kept insisting on using another drive's EFI partition. I have lots of work to do on it, including installing Grub. I did get my data drive mounted already.
Re: Slackware-Current
UEFI sure is a stupid way to boot. While it gets rid of some legacy limitations, it's a regression in other ways. Imagine, an operating system's boot loader can screw up EFI boot entries so bad you can't boot anything. Nope, no legit way to clear that data. A BIOS flash might erase that NVRAM. (CMOS clear jumper doesn't). That royally pissed me off, efibootmgr (grub uses that to write to NVRAM) corrupting my boot data. (I wonder if that's fixed after 3 years of bios updates... don't want to find out)
You SHOULD be able to use the same EFI partition and that would be the the correct thing to do, moreover, I would only want one boot loader installed. EXCEPT, that Arch symlinks the EFI partition to /boot in an EFI setup.
P.S. I meant to say, if you have your Arch booting with Grub, and you have your Slackware booting with elilo, I wouldn't install Grub in Slackware. Leave it alone. Moreover, Grub isn't very well supported in Slackware, elilo is the recommended boot loader for EFI.
You SHOULD be able to use the same EFI partition and that would be the the correct thing to do, moreover, I would only want one boot loader installed. EXCEPT, that Arch symlinks the EFI partition to /boot in an EFI setup.
P.S. I meant to say, if you have your Arch booting with Grub, and you have your Slackware booting with elilo, I wouldn't install Grub in Slackware. Leave it alone. Moreover, Grub isn't very well supported in Slackware, elilo is the recommended boot loader for EFI.
Re: Slackware-Current
Here's another wonderful thing about UEFI bioses. They can be easily compromised. First of all, shit can be dumped in the EFI partition. One example is the boot logo image file, some biosen copy that there and it's read from there at boot time. Guess what? The image loaders use vulnerable code that can execute code to run in the UEFI bios. Unlike CIH of the 90's that simply corrupted the bootstrap routine, these UEFI bioses can run infected code. Format your hard drive until blue in the face, the BIOS has been altered. Oh, and Secure Boot doesn't check things like that (logo image) and has nothing to do with the BIOS itself.
BIOS doesn't store the image file in the EFI partition? No problem, another vector is the vendor's own BIOS flash updaters. You know, the kind that run in Windows or through Windows update. Guess what's not verified by checksum? That's right, the logo image, because it's vendor customizable
One would think that turning off the boot logo would fix it, but here's the thing about low level programming... it would be just as likely that it parses the data anyway and just doesn't display it. It'll be something probably read at the same time as other data, before the decision.
I don't see any mention of this fix in any of MSI's BIOS updates. Maybe they silently fixed it, or maybe not. It was common code (the image parsers).
P.S. I just read that MSI boards were not vulnerable to this (it's called "LogoFail") because they don't allow the logo to be changed. It's part of the BIOS image. I always disable boot logos though, I hate them. Fast boot too, I hate that. I want it to initialize hardware properly on every boot (it does not actually cut any perceptible time on my rig anyway)
BIOS doesn't store the image file in the EFI partition? No problem, another vector is the vendor's own BIOS flash updaters. You know, the kind that run in Windows or through Windows update. Guess what's not verified by checksum? That's right, the logo image, because it's vendor customizable
One would think that turning off the boot logo would fix it, but here's the thing about low level programming... it would be just as likely that it parses the data anyway and just doesn't display it. It'll be something probably read at the same time as other data, before the decision.
I don't see any mention of this fix in any of MSI's BIOS updates. Maybe they silently fixed it, or maybe not. It was common code (the image parsers).
P.S. I just read that MSI boards were not vulnerable to this (it's called "LogoFail") because they don't allow the logo to be changed. It's part of the BIOS image. I always disable boot logos though, I hate them. Fast boot too, I hate that. I want it to initialize hardware properly on every boot (it does not actually cut any perceptible time on my rig anyway)
Re: Slackware-Current
Yeah I read about LogoFail a while back.
Looks like Pat is planning to move to Grub for Slackware 15.1:
From Linuxquestions.org
Looks like Pat is planning to move to Grub for Slackware 15.1:
- slackware_grub.jpg (65.6 KiB) Viewed 262 times
Re: Slackware-Current
Ahh good then. It used to be "good luck with grub"
Grub is more practical. It evidently can be trouble though, on some EFI bios implementations (cough, cough) with its efibootmgr back end.
I personally see no benefit in booting through EFI. Enabling CSM mode doesn't change your whole bios or anything, it just allows booting using old school methods too. Because I'm going old school I kept the MBR partition tables, but I still could have still used GPT partitions (or use LVM) for most all of the disk and eliminated the need for extended partitions, but why mess about doing complicated things for mostly cosmetic reasons.
Grub is more practical. It evidently can be trouble though, on some EFI bios implementations (cough, cough) with its efibootmgr back end.
I personally see no benefit in booting through EFI. Enabling CSM mode doesn't change your whole bios or anything, it just allows booting using old school methods too. Because I'm going old school I kept the MBR partition tables, but I still could have still used GPT partitions (or use LVM) for most all of the disk and eliminated the need for extended partitions, but why mess about doing complicated things for mostly cosmetic reasons.