Add support for BIOS/extlinux setups

[bstaletic]

I've only implemented the BIOS/legacy boot + extlinux combination, because that's what I am using.

The current krenel_re matches lines like these:

    KERENEL /boot/vmlinuz
    LINUX /boot/vmlinuz.old

A few things to discuss there:

1. KERNEL tells extlinux to guess the format of the kernel image, which is why LINUX is preferred for linux kernels. Do we want to support KERNEL?
2. Absolute paths in extlinux are relative to the filesystem containing extlinux.conf. If /boot is its own partition, then the above line would be LINUX /vmlinuz.old. I do not know if eclean-kernel can handle that, even if extlinux.py were to implement that logic.
3. Relative paths are relative to extlinux.conf. I do not know if eclean-kernel can handle that, even if extlinux.py were to implement that logic.

The config file is also a bit more complex than in my implementation: https://wiki.syslinux.org/wiki/index.php?title=Config#Location_and_name

The previous link also shows the EFI layout.

[bstaletic]

Here's how eclean-kernel behaves on my system before this patch:

DEBUG:root:Sorter: <ecleankernel.sort.VersionSort object at 0x7f0326881010>
DEBUG:root:Layout failed: <class 'ecleankernel.layout.blspec.BlSpecLayout'>; exception: /boot/[EFI/]loader not found
DEBUG:root:Layout: <ecleankernel.layout.std.StdLayout object at 0x7f03268812b0>
DEBUG:root:Bootloader failed: <class 'ecleankernel.bootloader.lilo.LILO'>
DEBUG:root:Bootloader failed: <class 'ecleankernel.bootloader.grub2.GRUB2'>
DEBUG:root:Bootloader failed: <class 'ecleankernel.bootloader.grub.GRUB'>
DEBUG:root:Bootloader failed: <class 'ecleankernel.bootloader.yaboot.Yaboot'>
DEBUG:root:Bootloader: <ecleankernel.bootloader.symlinks.Symlinks object at 0x7f0326881400>
other 6.11.10-test [6.11.10-test]
- systemmap: /boot/System.map-6.11.10-test
- config: /boot/config-6.11.10-test
- vmlinuz: /boot/vmlinuz-6.11.10-test
- modules: /lib/modules/6.11.10-test
- build: /lib/modules/6.11.10-test/../../../usr/src/linux-6.11.10-test
- last modified: 2024-11-23 13:38:41
other 6.11.9-test [6.11.9-test]
- systemmap: /boot/System.map-6.11.9-test
- config: /boot/config-6.11.9-test
- vmlinuz: /boot/vmlinuz-6.11.9-test
- modules: /lib/modules/6.11.9-test
- last modified: 2024-11-18 17:52:09

And fater:

DEBUG:root:Sorter: <ecleankernel.sort.VersionSort object at 0x7f3cf3e78ec0>
DEBUG:root:Layout failed: <class 'ecleankernel.layout.blspec.BlSpecLayout'>; exception: /boot/[EFI/]loader not found
DEBUG:root:Layout: <ecleankernel.layout.std.StdLayout object at 0x7f3cf3e79160>
DEBUG:root:Bootloader failed: <class 'ecleankernel.bootloader.lilo.LILO'>
DEBUG:root:Bootloader failed: <class 'ecleankernel.bootloader.grub2.GRUB2'>
DEBUG:root:Bootloader failed: <class 'ecleankernel.bootloader.grub.GRUB'>
DEBUG:root:/boot/extlinux/extlinux.conf found
DEBUG:root:Bootloader: <ecleankernel.bootloader.extlinux.EXTLINUX object at 0x7f3cf3e792b0>
other 6.11.10-test [6.11.10-test]
- systemmap: /boot/System.map-6.11.10-test
- config: /boot/config-6.11.10-test
- vmlinuz: /boot/vmlinuz-6.11.10-test
- modules: /lib/modules/6.11.10-test
- build: /lib/modules/6.11.10-test/../../../usr/src/linux-6.11.10-test
- last modified: 2024-11-23 13:38:41
other 6.11.9-test [6.11.9-test]
- systemmap: /boot/System.map-6.11.9-test
- config: /boot/config-6.11.9-test
- vmlinuz: /boot/vmlinuz-6.11.9-test
- modules: /lib/modules/6.11.9-test
- last modified: 2024-11-18 17:52:09

Well... I've just realized that even without my patch, the "symlinks bootloader" finds the two kernels in my /boot. I can live with that, but maybe we could improve syslinux support.

[mgorny]

It's been a while since I've used non-blspec layout but I'm not sure if it's supposed to be recognizing them as "other" rather than "std".

[mgorny]

1. `KERNEL` tells extlinux to guess the format of the kernel image, which is why `LINUX` is preferred  for linux kernels. Do we want to support `KERNEL`?

I don't think this will cause us to do anything about non-Linux kernels, will it?

2. Absolute paths in extlinux are relative to the filesystem containing `extlinux.conf`. If `/boot` is its own partition, then the above line would be `LINUX /vmlinuz.old`. I do not know if eclean-kernel can handle that, even if `extlinux.py` were to implement that logic.

I think that's the same case as LILO — but I honestly have no clue how we're dealing with it there.

3. Relative paths are relative to `extlinux.conf`. I do not know if eclean-kernel can handle that, even if `extlinux.py` were to implement that logic.

Isn't that just a matter of rewriting the paths?

[bstaletic]

It's been a while since I've used non-blspec layout but I'm not sure if it's supposed to be recognizing them as "other" rather than "std".

The second and third debug lines say that the blspec layout failed (because non-EFI) and that std works. Only in the output of --list-kernels does it say "other". Looks like standard layout returns Kernel objects with layout == 'other'.

>>> from ecleankernel.layout.std import *
>>> std = StdLayout()
>>> std.find_kernels()[0]
Kernel(version='6.11.10-test', layout='other')

That feels like a whole different problem that can be addressed in a different pull request.

1. KERNEL tells extlinux to guess the format of the kernel image, which is why LINUX is preferred for linux kernels. Do we want to support KERNEL?

I don't think this will cause us to do anything about non-Linux kernels, will it?

Gentoo wiki discourages users from using KERNEL, to avoid syslinux misdetecting the kernel image type. The detection is based on file extensions. I don't think eclean-kernel would work on a COMBOOT image, for example. I was just wondering if we should heed wiki's warning and only process LINUX lines from extlinux config.

2. Absolute paths in extlinux are relative to the filesystem containing extlinux.conf. If /boot is its own partition, then the above line would be LINUX /vmlinuz.old. I do not know if eclean-kernel can handle that, even if extlinux.py were to implement that logic.

I think that's the same case as LILO — but I honestly have no clue how we're dealing with it there.

You might be right. I couldn't find anything on the internet defining LILO absolute paths.

3. Relative paths are relative to extlinux.conf. I do not know if eclean-kernel can handle that, even if extlinux.py were to implement that logic.

Isn't that just a matter of rewriting the paths?

It is and I may have expressed myself poorly. Since paths are relative to either /boot/extlinux/ or /boot/syslinux, I would guess eclean-kernel wouldn't know that automatically. I will mess around with relative paths and introduce the changes needed to support them.