On Mo, 13.07.20 19:16, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote: > > Yes, because you have to propagate it everywhere, and if you omit it > > things break, since it's a secondary place you store information about > > the root disk in that you strictly need to have to be able to make > > sense of the file system. > > As it relates to Silverblue, how is the 'ostree=' parameter any > different or less fragile than 'root=' or 'rootflags=' and how could > it be made automatically discoverable? That information is currently > in the bootloader configuration file, and the means for switching > between roots is by bootloader menu item. I don't know how ostree works precisely. If they want different ostree versions show up in the boot menu, they of course have to synthesize boot menu items each time they add a new ostree version, and that boot menu item should then clearly be bound to the ostree hash, and for that kind of stuff using the ostree= kernel cmdline param makes things. If however they share the same kernel/boot menu item between multiple versions of the OS tree, then I'd always embedd which version to boot in the fs itself by default, so that the OS file system is self-descriptive (and you thus can boot it consistently with systemd-nspawn --image=). It could be as simple as adding a symlink called "default" to the right ostree hash or so, i.e. taking inspiration from git. When you switch defaults you would then just update where the symlink points. Lennart -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
