On Tue, Jul 14, 2020 at 1:45 AM Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > > 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. I'm suggesting the ostree= parameter is analogous to the rootflags=subvol= parameter. Both point to (sub) trees that are separate system roots. > 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. The kernel might be the same or different between ostrees. But if I remove the ostree= hint, the system doesn't boot. -- Chris Murphy _______________________________________________ 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
