Ubuntu's ZFS Trajectory Is Going From Exciting To Even More Exciting

[skeevy420]

complete bullshit, systemd-boot is completely unrelated to systemd init https://wiki.archlinux.org/index.php/Systemd-boot

You know as well as I do that it is very unlikely that a non-systemd distribution will use the systemd-based bootloader. Modular or not, it seems to be one of those absolutes the major distributions tend to have -- all or none.

Are you aware of this revolutionary concept called "boot partition" https://docs.fedoraproject.org/en-US...mmend-x86.html https://en.opensuse.org/SDB:Partitioning ?

Which was available as far back as 9 years or more as a way to work around bootloader limitations? https://superuser.com/questions/6601...boot-partition

https://askubuntu.com/questions/6490/is-a-boot-partition-necessary-anymore

But that leaves us in a state where the entire bootstack is separate from the host OS and that's what I'm trying to get away from with my idea of a simplified boot loader. Just fat32 support and enough features to load a kernel from a partition and use that to scan disks, present a basic text menu of available OSs, and the ability to load the OS the user picks. That's it. That's all it would do and should be able to boot any OS outside of some that use file systems the kernel doesn't understand. I'm only saying kernel because it could work with either the BSD or Linux kernels and tools.

The only "advanced features" would be a config file that lets the user turn off the menu and boot into a predetermined OS if, I dunno, Left Shift isn't held during boot after the user presses F1 over an OS entry in the menu as well as the standard shutdown/reboot options. That's it. No fancy UI; just a scanner and a dumb interface with the most minimal of options.

The OS itself would have to provide the rest of the bootstack -- kernel choices, fancy UIs, Time Machine like options, etc and just has to provide a hook for the simplified boot loader to tie into, like "/boot/loader.cfg" on unencrypted systems, that provides the OS Name & points the simple loader kernel in the right directions. Encrypted OSs/drives would have to provide their loader.cfg on the fat32 partition else there'd be decryption nagging during the scanning phase.

[starshipeleven]

You know as well as I do that it is very unlikely that a non-systemd distribution will use the systemd-based bootloader.

I don't give a shit. You are claiming it does not work without systemd, when it's plain bs.

Solus has forked it for example, but it's not a new software. (it's imho worse because of fragmentation)

But that leaves us in a state where the entire bootstack is separate from the host OS, and that's what I'm trying to get away from with my idea of a simplified boot loader. Just fat32 support and enough features to load a kernel from a partition and use that to scan disks, present a basic text menu of available OSs, and the ability to load the OS the user picks. That's it.

Ah ok I didn't understand it.

You mean dumb bootloader -> Linux+initramfs used as bootloader -> target OS. That's somewhat similar to what Linuxboot project does. https://www.linuxboot.org/ They boot it from flash using the lower-level board init blobs as they are removing UEFI userspace and bootloader, but that is the same concept.

The main benefit is that this "bootloader" is in fact capable of booting anything Linux can boot from, and can be updated easily as there is nothing to port to another kernel every time.

Given what this system is, you should not need even filesystem drivers in the dumb first stage bootloader, you can just write the "linux bootloader" raw to the partition.

The only "advanced features" would be a config file that lets the user turn off the menu and boot into a predetermined OS

writing raw would still allow configuration from OS or within itself, although it would have to be written raw too at a specific address in the "bootloader partition" and you would need a (simple) tool to read/edit it from the OS
(similar to what uboot does with its own config)

The OS itself would have to provide the rest of the bootstack -- kernel choices, fancy UIs, Time Machine like options, etc and just has to provide a hook for the simplified boot loader to tie into, like "/boot/loader.cfg"

That's not "bootstack", that's "bootloader configuration" and falls into the above.

Also, if you think for a second that this can be "generic" you can forget about it, every distro will ship its own configuration which may or may not be compatible. GRUB can be installed in a "generic" way in its own boot partition too (so it can be used like your "Linuxboot" proposal), but no known distro has EVER done that and used anything resembling a standard.

[skeevy420]

I don't give a shit. You are claiming it does not work without systemd, when it's plain bs.

Solus has forked it for example, but it's not a new software. (it's imho worse because of fragmentation)

I wasn't intending to imply or claim that. Only that I think that it seems highly unlikely that systemd-boot would be used (by a distribution) without systemd.

Ah ok I didn't understand it.

You mean dumb bootloader -> Linux+initramfs used as bootloader -> target OS. That's somewhat similar to what Linuxboot project does. https://www.linuxboot.org/ They boot it from flash using the lower-level board init blobs as they are removing UEFI userspace and bootloader, but that is the same concept.

The main benefit is that this "bootloader" is in fact capable of booting anything Linux can boot from, and can be updated easily as there is nothing to port to another kernel every time.

Given what this system is, you should not need even filesystem drivers in the dumb first stage bootloader, you can just write the "linux bootloader" raw to the partition.

Something very similar, but it would also have an MBR loader as well as be able to be tied in to crap like Android's loader.

writing raw would still allow configuration from OS or within itself, although it would have to be written raw too at a specific address in the "bootloader partition" and you would need a (simple) tool to read/edit it from the OS
(similar to what uboot does with its own config)

I thought about that but then thought that people would complain about "binary configuration files" like they do about systemd logs and decided to describe simple to use methods that drum up less Phoronix hate like fat32 & plain text config files.

That's not "bootstack", that's "bootloader configuration" and falls into the above.

Also, if you think for a second that this can be "generic" you can forget about it, every distro will ship its own configuration which may or may not be compatible. GRUB can be installed in a "generic" way in its own boot partition too (so it can be used like your "Linuxboot" proposal), but no known distro has EVER done that and used anything resembling a standard.

That's actually the entire point. Its simplicity is its standard. One config file is all that the OS would need to provide.

An unencrypted system not needing a GUI would only need to provide a "loader.cfg" that contained an entry like:

UUID=15453456bc84823709
HasMenuEntry=Yes
TopMenu=Manjaro Linux
HasSubMenus=Yes
SubMenu1=Manjaro Linux 5.7
    SM1InitMethod=systemd
    SM1Kernel=/boot/vmlinuz-linux57
SubMenu2=Manjaro Time Machine
    Blah
    Yada

which would tell it to use that kernel with systemd.

An encrypted system would need something like this:

UUID=b2340406980b092394
HasMenuEntry=Yes
MenuEntry=Fedora Silverblue 32
UseSubMenu=No
Init=custom

CustomExe=/boot/silverblue-boot-ui

on a config on the fat32 partition that tells the loader that it's a custom init solution, points it to up Silverblue's hypothetical GUI boot and layer management solution, and then quits to let that solution deal with it from there. By default, encrypted distributions would be expected to load up a 2nd simple loader stored on the encrypted volume that the distribution manages.

Easy peasy and any distribution should be able to make use of something that simplified.

[starshipeleven]

I wasn't intending to imply or claim that.

I understand, I just say that what you wrote has a pretty clear unambiguous meaning.

Something very similar, but it would also have an MBR loader as well as be able to be tied in to crap like Android's loader.

I'm pretty sure Android devices have their partition table in the device tree files like all embedded systems (also the bootloader will have that in its own config or it is hardcoded).
But whatever, the "first bootloader" in your system is a dumb thing that just skips to a predetermined area and reads the second bootloader which is the "Linuxboot-like" one.

Depending on the system you are in you can use a MBR-like first bootloader or a device-specific bootloader for Android devices (that is placed in the area the embedded bootloader expects to find its payload, which of course is device-specific because it's embedded hardware)

I thought about that but then thought that people would complain about "binary configuration files" like they do about systemd logs and decided to describe simple to use methods that drum up less Phoronix hate like fat32 & plain text config files.

It's a pipe dream in any case, I'd rather have it done properly like other light bootloaders do (u-boot). There is no reason to have filesystem drivers for the first bootloader in your architecture.

That's actually the entire point. Its simplicity is its standard. One config file is all that the OS would need to provide.

How do you think GRUB works? It's using a single config file for boot entries, you find that file in the boot partition. I t also supports merging files so each distro can add its own little file with its own boot entry and change it or delete it without touching anything else.

which would tell it to use that kernel with systemd.

why does that distro need to specify the init in the bootloader?

on a config on the fat32 partition that tells the loader that it's a custom init solution, points it to up Silverblue's hypothetical GUI boot and layer management solution, and then quits to let that solution deal with it from there. By default, encrypted distributions would be expected to load up a 2nd simple loader stored on the encrypted volume that the distribution manages.

So the bootloader does not know how to use shit and you would have to tell it to chainload the distro's "bootloaders" to do anything not basic? Then what's the point of using Linux in it?

Are you aware that GRUB can be used like that already? How do you think you can use it to boot raw ISO files or Windows?

https://wiki.gentoo.org/wiki/GRUB2/Chainloading

Easy peasy and any distribution should be able to make use of something that simplified.

Congrats, you just reinvented a functionality that is in GRUB for BIOS already and none uses because as I said everyone ships their own full stack and does not care about standards in the boot.

Are you an engineer perhaps? You got lost in engineering details and completely ignored the actual issue (that there is no standard way nor a way to enforce it), and since you ignore how the system works right now, you ended up reinventing the wheel.

I'll tell you what the issue is:
GRUB is not Linux so any driver update in/for Linux will need porting to GRUB. For more complex filesystems none gives a shit, for various reasons you can't change.
The only way you can get the bootloader to have drivers for everything is to use Linux itself as a bootloader like Linuxboot project.

Your dream of standardizing boot process is null and void, you have no way to enforce any rule, each distro does its own thing and ships its own bootloader stack configured however they like.


This is one of the few positive aspects of UEFI, it's enforcing a standard. If you have a UEFI system all the distros MUST place their crap in the EFI partition if they want to boot, it will have to be a UEFI executable, and will place their crap in their own little folder there.

At that point you can simply install your own boot manager (which is what rEFInd actually is) and use that to choose what distro bootloader you want to boot. Any time the distro reinstalls the bootloader you just have to switch again to your own in UEFI configuration.

[sireangelus]

Proxmox is using modern ZoL but it is using a dedicated root partition (RAIDed or not), where it does not enable any feature Grub does not like.

The ZFS storage pools are different.

Nope. I'ts all one giant partition.

[starshipeleven]

Nope. I'ts all one giant partition.

If you installed in BIOS/Legacy/CSM mode it's using GRUB and in that partition it does not enable the features GRUB does not like, and if you do it later it may fail to boot.

If you install in UEFI mode it will use systemd-boot and drop the kernel/initramfs in the EFI partition. In that case the root partition can have any ZFS option enabled (as root will be mounted by Linux kernel, and not by a bootloader anymore). This is the main reason they aren't using GRUB for UEFI systems. So you can simplify the setup. But it's still technically using a "boot partition" where it drops kernel/initramfs images to be loaded by the bootloader, which in this case is the EFI partition.