On Thu, Mar 23, 2017 at 5:01 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > We solved reliable booting 20 years ago - it's a simple as "set up > separate boot partition and use Lilo". Been working reliably for me > and all the systems I've installed and managed since 1995.... :/ The problem doesn't happen with a separate boot volume; different bootloader isn't necessary. No one is actively supporting LILO anymore. There are apparently so many uses cases people want to support that it doesn't support that no one cares to bring it up to speed. It's like saying the old ice box works just fine since 1895, just that it's someone else's fault they don't deliver ice blocks anymore. > > <feel free to insert you own "rocking chairs and lawn" comments :P> > >> But I sincerely doubt anyone on this list gives a flying fuck about >> bootloader problems. > > Nobody should care, because in future we should be replacing the > bootloader with "copy kernels into EFI partition and boot from EFI". > i.e. bypassing the need for a bootloader altogether. Worked > perfectly well for booting ia64 machines 10-15 years ago.... Unworkable for dual boot, let alone multibooting. The ESP is too small, no installer team is going to take responsibility for growing it, Windows gets confused when there's more than one on a disk, and the UEFI spec has no standardization for firmware boot managers, so there's no way to provide generic documentation for the built-in boot manager: and thus the bootloader needs to also be a boot manager in order to document it. And that leaves us right back to each distro owning it's own bootloader even on UEFI systems, where they have no idea WTF other distros have been installed (yes they will all see Windows, but it won't discover each other because Windows is not really a competitor, again leaving us with distros eating each others babies, etc.) > >> Actually, characterizing the distros as >> uncooperative is too polite. They actively sabotage each other. It's >> so bad, they even sabotage themselves (try doing back to back side by >> side installations of Fedora). Each distro's grub is effectively a >> fork. Fedora ostensibly uses mostly upstream stuff, but with grub the >> upstream copy has 200+ hacks that are Fedora specific, SUSE has more >> and more invasive hacks, both of them are mutually incompatible. The >> distros don't agree. They're different operating systems that just so >> happen to share a kernel (or an init service). This fact isn't going >> to get solved on this list. > > Yup, that's exactly what I was implying is the problem - everyone > has their own special snowflake rather than working together to > produce one simple, robust, reliable solution to a well known problem... Unsolvable. Systemd folks wrote up the bootloaderspec, and about 10 minutes later there was a more sane fork by Matthew Garrett, and 10 minutes later there were three implementations, all of which are mutually incompatible with each other. Still no cross distro cooperation either. >> So if you have something else for me to actually act on, I'm happy to >> try and push this forward so a teeny tiny handful of users can >> actually do single volume XFS booting and not end up face planted when >> they do offline updates. Thanks. > > *As I always say*: fix the root cause of the problem, don't hack > around it because that almost always makes things worse in the long > run. Hacking code into systemd to work around a distro-specific > and/or bootloader bug is simply not a viable long term solution to > the collaboration problems that have been pointed out here... OK well in three replies you're still vague on precisely how the bootloader is even involved in this problem, seeing as it doesn't make any changes to the disk during kernel update, at all. If you want to implicate grubby for doing the wrong thing, that'll need more detailed explanation. From what I can tell the problem is systemd initiates a reboot, while root fs is still mounted rw, the kernel tolerates this and leaves the fs dirty, and the bootloader can't handle the fallout and can't be expected to handle it. It's either systemd needs to not do reboots when root fs can't be remounted-ro; and therefore must not have indefinite exemptions from killing processes that don't hold rw mount on volumes. LIterally any bad program could exist somewhere at sometime, not exit, and thus cause this problem. So even if plymouth is an instigator in this case, the central problem seems to be either systemd for the indefinite kill exemption, or it's the kernel for doing a reboot when a file system is still dirty. And I don't know nearly enough about the separation of responsibilities between systemd and the kernel to have a clue whether the root cause is systemd or the kernel. But I'm unconvinced it's plymouth, dracut, grubby, or the bootloader, even though all of them are instigators. And by the way, the freeze/unfreeze idea was your idea. So to bring that up, and then in the very next email say it's fucked up to actually insert it somewhere if multiple remount attempts fail is bizarre. Since it's sufficiently fucked up to get you to actually write out the words fucked up, maybe the idea shouldn't have been mentioned in the first place? Why mention a bag of dicks as a solution if you're just doing to say oh shit that's a bag of dicks are you fucking crazy? Don't do that! -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
