Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • starshipeleven
    replied
    Originally posted by sireangelus View Post
    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.

    Leave a comment:


  • sireangelus
    replied
    Originally posted by starshipeleven View Post
    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.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by skeevy420 View Post
    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?



    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.

    Leave a comment:


  • skeevy420
    replied
    Originally posted by starshipeleven View Post
    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:

    Code:
    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:

    Code:
    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.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by skeevy420 View Post
    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.
    Last edited by starshipeleven; 17 October 2019, 12:46 PM.

    Leave a comment:


  • skeevy420
    replied
    Originally posted by starshipeleven View Post
    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
    A fair while ago (~ 2004) I was told to always create a separate partition for the boot directory. And since then I always have. But after reading a few questions about partitioning questions, I'm
    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.

    Leave a comment:


  • johnc
    replied
    I wonder if they will be making some kind of Time Machine-like application for desktops.

    Leave a comment:


  • Cherijo
    replied
    Originally posted by Chugworth View Post
    Wait, why are we still worrying over boot loaders? Now that we have UEFI (or at least, properly implemented UEFI), there's no need for them. Just use the EFISTUB method. And if you want to select from from multiple operating systems, use the system's boot menu.
    UEFI hasn't been implemented universally for that long. There are still perfectly viable systems out there that exist and rely on BIOS. I'm personally running a NAS based on my 10+ year old Q6600 on a P45 Mobo. I already had it sitting around, and it's perfectly capable as a local media NAS still for my needs. That means if it's on my network, it needs good, current, relevant security patches and a modern OS if at all possible. Hence, we still need bootloaders that play well with BIOS.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by Chugworth View Post
    Wait, why are we still worrying over boot loaders?
    raw UEFI is fine for basic setups, but if you want to boot into a snapshot, or a FreeBSD's ZFS "boot environment" equivalent, or whatever is Stratis's equivalent you will still need something better.

    And if you have a RAID, relying on UEFI stub is a pain in the ass as you would need to update the same EFI partition in all your drives and keep it updated every time you update the kernel. While with (decent) bootloaders like rEFInd this EFI partition is static, do it once use forever.

    Also the amount of UEFI firmware that still sucks out there is staggering.
    Last edited by starshipeleven; 15 October 2019, 04:15 PM.

    Leave a comment:


  • stormcrow
    replied
    Originally posted by jrch2k8 View Post

    [stuff]

    UEFI on the other hand is really dumb and simple with a proper standard, so basically you need a fat32 partition on GUID that contains the loader and a kernel, then the kernel and initramfs do wathever they need to do to boot, hence systemd on UEFI is able to boot anything simply because the handoff is done form the UEFI to the kernel directly and the kernel knows exactly what to do from there regardless of features
    That's the ideal. The reality is there's just as much brokeness with UEFI implementations as there was BIOS. I'd love to get rid of Grub, too, but I doubt you'll get rid of it and rely on UEFI's boot sequence without a working shim to adjust for quirks when it's just as likely to have problems as BIOS+Grub. Case in point, I have an MSI AMD Ryzen board that used to fail to boot if it had more than one EFI entry on the FAT32 partition. It would silently drop to the firmware config screen. Took MSI several months to fix that and only after I pointed out the bug would affect multiple Windows installations as well as non-Windows OSes. It was a silent fix too. They never acknowledged the bug. It just magically got fixed in a firmware upgrade.

    Leave a comment:

Working...
X