Major LILO bug in Slackware64 current

I downloaded and burned Slackware64 current to disc. I then tried to install on a laptop that had worked just fine with Linux before.
This time however LILO complains that a newly wiped SSD, which has only 1 partition, is somehow not "linear" and refuses to install to its MBR. This is an old system without EFI.
Has anyone else seen this? Unless I'm somehow "not holding it right", I think Patrick may have to downgrade LILO.

LILO hasn't been touched since Apr 2018 (which was due to the mass rebuild of the whole system and didn't have any changes). The previous rebuild and almost all of the rebuilds before that have been to add features to liloconfig.

Can you post the actual error and we can try and figure out what is the issue?

Originally Posted by bassmadrigal Can you post the actual error and we can try and figure out what is the issue?

Hi,
Here's the sequence of events.

1. I wiped my Crucial M4 SSD by doing dd if=/dev/zero of=/dev/sdb

2. I put this SSD into a ~2008 laptop which already had another Crucial M4 SSD in it (a smaller one).

3. I booted slackware64-current, ran fdisk, set up one partition, and then set it up as a LUKS partition. All very standard stuff.

4. Ran setup, everything installed, got to the point where LILO install happens and it ran.

5. It said Fatal error: only linear boot device supported.

6. I recalled that the SSD had a DOS label, so I thought maybe filling the drive with all 0's had put it in some legacy mode that fdisk and LILO don't like, so I rebooted, repartitioned with a GPT label and repeated the process-- same result.

Originally Posted by MozillaUser3172 Has anyone else seen this? Unless I'm somehow "not holding it right", I think Patrick may have to downgrade LILO.

I did a clean install of Slackware64-current yesterday with a newer -current ISO. I had no issues with LILO.

Originally Posted by MozillaUser3172 3. I booted slackware64-current, ran fdisk, set up one partition, and then set it up as a LUKS partition. All very standard stuff.

You'll need an unencrypted /boot if you're using LUKS.

Originally Posted by volkerdi You'll need an unencrypted /boot if you're using LUKS.

Until the Slackware installer switches to using GRUB by default.
https://wiki.archlinux.org/index.php...ncrypted_/boot
https://wiki.archlinux.org/index.php...rtition_(GRUB)

PS Argon2 support from cryptsetup will eventually not make its way in GRUB 2.06, but at least the PBKDF2 key derival function is already supported in pre-2.06. So there will be a full support of LUKS1 and a partial support of LUKS2 in this version.

Originally Posted by volkerdi You'll need an unencrypted /boot if you're using LUKS.

Ah yes, I did skip that step, thanks.

I wonder though if the LILO developers realize what a misleading error message they're producing. It caused me to look for the wrong thing in the wrong place, and not to reflect on whether I left out a step.

Originally Posted by Didier Spaier Until the Slackware installer switches to using GRUB by default. https://wiki.archlinux.org/index.php...ncrypted_/boot

Having an unencrypted boot partition is risky. Any organization whose operatives can get physical access to your computer can in theory replace your kernel with a special kernel that contains spyware.

Originally Posted by MozillaUser3172 Having an unencrypted boot partition is risky. Any organization whose operatives can get physical access to your computer can in theory replace your kernel with a special kernel that contains spyware.

Yeah. It's up to you, to make sure they can't do that.

After that, let's hope you have a system that's still usable.

Originally Posted by MozillaUser3172 Having an unencrypted boot partition is risky. Any organization whose operatives can get physical access to your computer can in theory replace your kernel with a special kernel that contains spyware.

Yes, but the linked to article proposes a way to use an encrypted boot partition.

Hi,

Originally Posted by MozillaUser3172 Having an unencrypted boot partition is risky. Any organization whose operatives can get physical access to your computer can in theory replace your kernel with a special kernel that contains spyware.

You're right. In my case, after installing/upgrading kernel and generate initrd.gz, I keep a checksum (sha256sum) of these files on another computer. When I had to restart my computer I can check integrity.
Unless I forgot something, I'll see if something wrong.