installing slackware on non-uefi system

[John Forkosh]

I've got a regular old fdisk/lilo-based non-uefi boot drive,
but the latest (-current64 as of 2/7/23) version created
a usb install stick that warned me it couldn't find any
efi partitions, and that lilo wouldn't work (which indeed
it didn't) and that I'd have to boot from a usb stick.
Fortunately, I didn't have to do that (boot from usb) since I was
installing on /dev/sda4 and already had an an older slackware
on /dev/sda1 with lilo on the mbr, and only had to add an
sda4 section to that lilo.conf, and then rerun lilo from there.
But I'll eventually want to update that sda1 partition, too,
which is slackware from Sept 2019, and had no such efi problem
when installed back then.

So how do you make a -current install usb that just recognizes
non-efi fdisk partitions? What I'd done, as usual for me, is
rsync -av rsync://mirrors.kernel.org/slackware/slackware64-current/ \
myslackwaredirectory/
and then ran the usb-and-pxe-installers/usbimg2disk.sh script.
But now that I think about it, maybe it did say something about
uefi when it ran??? But I'm not seeing anything related to that
in the script itself (not so far as I can tell, anyway).
Is there any -switch or anything else like that creating
the usb boot/install stick? Or, in general, how do you create
a usb install stick that will install and correctly run lilo
on fdisk partitions, without any efi complaints?

[John Forkosh]

Post by John Forkosh
I've got a regular old fdisk/lilo-based non-uefi boot drive,
but the latest (-current64 as of 2/7/23) version created
a usb install stick that warned me it couldn't find any
efi partitions, and that lilo wouldn't work (which indeed
it didn't) and that I'd have to boot from a usb stick.
Fortunately, I didn't have to do that (boot from usb) since I was
installing on /dev/sda4 and already had an an older slackware
on /dev/sda1 with lilo on the mbr, and only had to add an
sda4 section to that lilo.conf, and then rerun lilo from there.
But I'll eventually want to update that sda1 partition, too,
which is slackware from Sept 2019, and had no such efi problem
when installed back then.
So how do you make a -current install usb that just recognizes
non-efi fdisk partitions? What I'd done, as usual for me, is
rsync -av rsync://mirrors.kernel.org/slackware/slackware64-current/ \
myslackwaredirectory/
and then ran the usb-and-pxe-installers/usbimg2disk.sh script.
But now that I think about it, maybe it did say something about
uefi when it ran??? But I'm not seeing anything related to that
in the script itself (not so far as I can tell, anyway).
Is there any -switch or anything else like that creating
the usb boot/install stick? Or, in general, how do you create
a usb install stick that will install and correctly run lilo
on fdisk partitions, without any efi complaints?

Got an email reply from "mz721" that doesn't seem to have
also been posted here, so I'll reproduce it below...

---------------------------------------------------------------------------
email from "mz721"
---------------------------------------------------------------------------
I apologise if this is all too obvious (I'm new here, and I am sure you know
Slackware a lot better than I do), but ...

Does the noefi boot flag have any effect? I can't image that Lilo would know
anything about that, so I guess not. I recently installed Slack 15 using the
minimal netinstall CD on a very old computer (has to use CD because it could
not boot from USB and the disc drive could not handle DVDs). Definitely a
non-UEFI system! So I think it must be something to do with the install
media/image; whether the USB one assumes UEFI and the ISOs do not ...? Also,
I know Slack installs lilo by default, but I think grub2 is available; maybe
switching to grub? I have sometimes found using a USB DVD drive and the DVD
ISO can give a result different from a USB stick.

Just a few ideas.
---------------------------------------------------------------------------

So is that noefi flag the answer? I didn't know about it, and am
not googling much about it, either. When booting from the usb stick
for the install, I didn't enter any optional boot parameters at
the very beginning. Should I have typed noefi on that line to
fix the problem? I'd just give it a try, but don't really have any
spare partitions for a test, though I suppose I could just exit
and shutdown without installing anything anywhere. But I thought
I'd ask here first.

And thanks, mz721, for the suggestions.

[Henrik Carlqvist]

Post by John Forkosh
the latest (-current64 as of 2/7/23)

I have only experience from stable versions of Slackware like 15.0 and
older.

Post by John Forkosh
warned me it couldn't find any efi partitions, and that lilo
wouldn't work (which indeed it didn't)

In which way did not lilo work?

Did it complain when you ran lilo to install it in MBR?

Did it fail to boot? If so, what did you see on your screen at that
failure?

During the years I have mostly run lilo to boot Slackware installations.
To be able to do that I have on newer machines had to enable legacy boot
in CMOS setup. On some newer machines I have booted with UEFI on GPT
partitions with some other bootloader than lilo, but to my surprise I
have also found that lilo seems to work with a GPT partition and legacy
boot.

regards Henrik

[John Forkosh]

Post by Henrik Carlqvist

Post by John Forkosh
the latest (-current64 as of 2/7/23)

I have only experience from stable versions of Slackware like 15.0
and older.

Yeah, I think I've had this problem before (last install on this
non-uefi box was 8/19/21 using 15.0x64 rc1), but not quite sure.

Post by Henrik Carlqvist

Post by John Forkosh
warned me it couldn't find any efi partitions, and that lilo
wouldn't work (which indeed it didn't)

In which way did not lilo work?

"corrupt partition" fatal warnings. Running lilo -P ignore let
it run to completion, but didn't actually install on root block
("boot = /dev/sda4" in lilo.conf), as far as I can tell.

Post by Henrik Carlqvist
Did it complain when you ran lilo to install it in MBR?

Not at all, but that was an even older install on /dev/sda1,
from -current64 as of 9/1/19.

Post by Henrik Carlqvist
Did it fail to boot? If so, what did you see on your screen at that
failure?

Booted just fine. But I first booted into the above-mentioned
sda1 partition, edited its /etc/lilo.conf to add a section
for the new sda4 install...
# Linux bootable partition config begins
image = /mnt/sda4/boot/vmlinuz
root = /dev/sda4
label = slk150x64sda4
read-only # Partitions should be mounted read-only for checking
# Linux bootable partition config ends
and issued a mount /mnt/sda4/ /dev/sda4 to make that partition
visible. Then reran lilo so it would show up on boot menu. And this
lilo.conf has "boot = /dev/sda" so that it's the 9/1/19 slack15
that's installing on the mbr. And then rebooting indeed showed the
new partition on the boot menu, and booted into it without a hiccup.

Post by Henrik Carlqvist
During the years I have mostly run lilo to boot Slackware installations.
To be able to do that I have on newer machines had to enable legacy boot
in CMOS setup.

Right. Now that you mention it, I recall "legacy boot" on some bioses.
I'll have to check that on this box's bios and see if maybe it's been
somehow reset. (And I also further checked that usbimg2disk.sh script,
which I usually run as
./usbimg2disk.sh -f -s slackware64-current-07Feb2023 -o /dev/sdc
and I'm wondering if I should omit the -f and format the stick
myself before running usbimg2disk.)

Post by Henrik Carlqvist
On some newer machines I have booted with UEFI on GPT
partitions with some other bootloader than lilo, but to my surprise I
have also found that lilo seems to work with a GPT partition and legacy
boot.

Good to know. I've been keeping my boot disks to 2TB (usually
a 2.5" 1TB ssd) so that I could continue using fdisk. But I guess
maybe that's not necessary.

Post by Henrik Carlqvist
regards Henrik

Thanks for all the help.

[Henrik Carlqvist]

"corrupt partition" fatal warnings. Running lilo -P ignore let it run
to completion, but didn't actually install on root block ("boot =
/dev/sda4" in lilo.conf), as far as I can tell.

Ah, I allways install lilo in MBR (/dev/sda), and so did you to get it to
work, but from another multi-boot install.

It was many years since I installed lilo onto the boot block of a
partition. To make it boot that way you will still need to configure some
other boot loader to use that partition as a chain boot.

My guess is that your problem came from different kernels/software having
different opinions upon the geometry of the drive.

regards Henrik

[John Forkosh]

"corrupt partition" fatal warnings. Running lilo -P ignore let it run
to completion, but didn't actually install on root block ("boot =
/dev/sda4" in lilo.conf), as far as I can tell.

Ah, I always install lilo in MBR (/dev/sda), and so did you to get it to
work, but from another multi-boot install.

Yeah, that seems to be the most convenient approach for desktops,
where I typicaly use a 1TB ssd for /dev/sda and a much larger hdd
for /dev/sdb, with sda reserved for slackware installs, and sdb
for my work.

It was many years since I installed lilo onto the boot block of a
partition. To make it boot that way you will still need to configure some
other boot loader to use that partition as a chain boot.

I've never actually intended to chain boot using the boot block.
Just run lilo that way to see that everything's working as it should.
I've always booted directly from the mbr, where lilo's installed
from the /dev/sda1 partition, with whatever -current64 is current
at the time. In this case -current64 was 9/1/19. Then I add sections
to sda1's lilo.conf like
# Linux bootable partition config begins
image = /mnt/sda2/boot/vmlinuz
root = /dev/sda2
label = slk150x64sda2
read-only # Partitions should be mounted read-only for checking
# Linux bootable partition config ends
for partitions 2,3,4, as I install new -current64s, while leaving the
older ones still bootable, until I rotate back to sda1.

My guess is that your problem came from different kernels/software having
different opinions upon the geometry of the drive.

Hmm... that could be it, I suppose. So next time I re-install /dev/sda1
using the mbr for lilo, the problem should go away. And I guess I'll have
to eventually do that, but it's a bit scary since if the problem remains
then the box may not be bootable without reformatting sda, which will
wipe the other installs. Well, I guess it's inevitable, sooner or later.

regards Henrik

Thanks again for all the helpful information.

[King Beowulf]

Post by John Forkosh
I've got a regular old fdisk/lilo-based non-uefi boot drive,
but the latest (-current64 as of 2/7/23) version created a usb install

..

To reiterate and expand on prior comments:

1. BIOS must be set to legacy boot, sometime hidden as CSM =ON to allow
legacy boot

2. Slackware DVD and USB installers are hybrid. Hit F11 or F12 (depending
on motherboard) to get a list of bootable devices. Choose wisely! You
will see 2 entries for the USB stick if the BIOS allows legacy boot and
another for UEFI
NOTE: If legacy is disabled in BIOS, you will only get the UEFI got option
NOTE: Depending on BIOS legacy MBR boot is fallback if no EFI table entry
or partition is found.

3. GPT partition can only be legacy booted via MBR on ONLY /dev/sda.
superblock won't work. Use MSDOS partitions, set bootable flag on the
root partition, and then load LILO into root superblock.
NOTE: GPT does not have partition boot flags
NOTE: you will have to erase the MBR on /dev/sda. legacy boot ALWAYS
looks there 1st.
# dd if=/dev/zero of=/dev/sda bs=446 count=1
(bs=512 deletes the partition MBR+partition table)


Have fun!
-kb

[John Forkosh]

Post by King Beowulf

Post by John Forkosh
I've got a regular old fdisk/lilo-based non-uefi boot drive,
but the latest (-current64 as of 2/7/23) version created a usb install

..
1. BIOS must be set to legacy boot, sometime hidden as CSM =ON to allow
legacy boot

Yeah, I booted into the bios to check, and CSM is indeed ON, as I'd
originally left it (and OS is set to "other", etc). But CSM then has
some subparameters with three choices: Legacy&UEFI, Legacy-only,
UEFI-only. I'd chosen L&U, which seemed to be okay until now,
so I reset to L-only, but haven't tried booting the slackware usb
stick yet.

Post by King Beowulf
2. Slackware DVD and USB installers are hybrid. Hit F11 or F12 (depending
on motherboard) to get a list of bootable devices.

Wasn't aware of that. I usually boot into the bios, which then has
a separate boot menu with those various choices. ...

Post by King Beowulf
Choose wisely!

Isn't that what they told the Captain of the Titanic?

Post by King Beowulf
You will see 2 entries for the USB stick if the BIOS allows legacy boot
and another for UEFI
NOTE: If legacy is disabled in BIOS, you will only get the UEFI got option

... And I think maybe you're right that that's part (maybe all)
of the problem. There were two choices for the usb stick,
one of which was uefi, and I tried booting the other. But that then
just booted the /dev/sda ssd, so I tried several times more until
it finally booted the usb stick. But maybe I unintentionally
booted the uefi option. I'll have to try some additional experiments,
playing with CSM choices and booting the usb install stick.

Post by King Beowulf
NOTE: Depending on BIOS legacy MBR boot is fallback if no EFI table entry
or partition is found.
3. GPT partition can only be legacy booted via MBR on ONLY /dev/sda.
superblock won't work. Use MSDOS partitions, set bootable flag on the
root partition, and then load LILO into root superblock.

Yeah, my /dev/sda (which is typically reserved for slackware installs)
is a 1TB ssd, always <=2TB so I can fdisk it. And running fdisk -l from
this new install shows...
bash-5.2# fdisk -l /dev/sda
Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: SanDisk SDSSDH3
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe64e3ed9

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 488380780 488378733 232.9G 83 Linux
/dev/sda2 * 488382464 976763244 488380781 232.9G 83 Linux
/dev/sda3 * 976764928 1465145708 488380781 232.9G 83 Linux
/dev/sda4 * 1465147392 1953525167 488377776 232.9G 83 Linux
...so it seems to be okay. Even the newly-installed sda4 is marked
bootable, so I guess maybe that lilo -P ignore actually did
something, despite the warnings.

Post by King Beowulf
NOTE: GPT does not have partition boot flags
NOTE: you will have to erase the MBR on /dev/sda. legacy boot ALWAYS
looks there 1st.
# dd if=/dev/zero of=/dev/sda bs=446 count=1
(bs=512 deletes the partition MBR+partition table)
Have fun!
-kb

Thanks a lot for all the very useful information.