On Wed, Jun 15, 2016 at 2:17 PM, Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > On 06/15/2016 03:46 PM, Chris Murphy wrote: >> I don't understand the technical reason for the 1st reboot. The >> substantial risk for updates is the user environment. If that's killed >> off even multi-user.target is far less risk to do updates in. But I >> don't see why system-update.target can't be isolated from >> graphical.target rather than mandating a reboot to get there. > > I tried to cover this in an earlier post, but the first reboot is to protect > against things like "user temporarily mounted over /usr/lib/foo so updating the > foo package isn't actually modifying the persistent system" and "there's a > memory-leak bug in the kernel so 99% of system RAM is held by kernel space while > trying to update" or other unpredictable things that can happen according to > chaos theory when system as complex as a modern Fedora has been running for > days/weeks/months without a reboot. The first reboot puts the system into a > (mostly) known state, which is basically a band-aid around a thousand other > unpredictabilities. To me this sounds like user sabotage. But lets say I accept this as sufficiently common that it needs accounting for... Systemd could unmount everything down to nearly going back to the initramfs without a reboot, then remount everything per the usual fstab generator rules just like at startup time, and then commence the update. Or probably faster and more reliable would be an nspawn container that bind mounts the fs per the usual fstab generator rules like at startup time, and does the offline update in the container environment, which inside that container would be like a new boot (sorta). The alternatives appear to have more problems and limitations. We can't have delayed or scheduled unattended updates on encrypted rootfs since the user needs to enter a passphrase; or we need a substantially reworked initramfs that brings up networking much earlier in boot to connect to a key server in order to unlock rootfs. -- Chris Murphy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
