Re: F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Fri, Nov 18, 2022, at 12:35 PM, Timothée Ravier wrote:
>> No, the install script install script in an RPM trigger, so the write is
>> still carried out by RPM.
>> 
>> I don't agree.  Just because a user can mess with files on the system
>> doesn't mean the rpmdb is a lie, nor is it reasonable to go recheck all
>> paths on the filesystem just in case they've done so, or create a daemon
>> to provide an interface for doing that.
>
> Note that this change here is only about Fedora Silverblue & Kinoite 
> (and maybe IoT later). In those variants, /usr is read only and not 
> expected to be changed by users. The rpmdb is thus pretty much 
> guaranteed to match the content of the system by design for /usr.
>
> On rpm-ostree based systems, system composes (image builds), package 
> installation and updates are done "offline" so /boot is not available. 
> The bootloader is not updated by an RPM trigger and this is why we need 
> an additional tool to perform the update at another time. We've created 
> a daemon because we need the update to be reliable so it should not 
> fail if your SSH connections fails or if you Ctrl-C it in the middle, 
> etc. This daemon is really small

I wouldn't even call it a daemon, at least not really.  More in:
https://github.com/coreos/bootupd/pull/401/files

That said, I think Robbie is effectively saying "bootupd seems over-engineered" and that's not *entirely* wrong.  It certainly could be simpler; yes, in theory we don't strictly need `bootupctl validate`.  But...things like having status information going to the journal in a reliable fashion have proven *very* useful in the past.  Most classically of course, dnf/apt type systems don't do this and it definitely makes things harder to debug after the fact.

The discussion about offline versus live installs touches on
https://github.com/coreos/bootupd/issues/108
and we probably should have an option to do that.
_______________________________________________
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
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux