On Fri, 22.06.12 08:56, Simo Sorce (simo@xxxxxxxxxx) wrote: > On Fri, 2012-06-22 at 13:38 +0100, Richard Hughes wrote: > > On 22 June 2012 12:40, Michal Hlavinka <mhlavink@xxxxxxxxxx> wrote: > > > Well, there is difference between inhibited reboot and "are you really sure > > > you want to reboot and break your system" questions. > > > > Is that a joke? [Click here to break your system] is never a good idea. > > > > > Anyway, what would happen when user press power button or ctrl-alt-delete in > > > yum-update-in-extra-target case? Would it shutdown/reboot (breaking the > > > system) or would it ignore the request? > > > > If the required systemd features land in time, it would ignore the > > ctrl-alt-del when the package manager is locked. > > Oh well, in one of may VMs half of the time systemd ignores my requests > for reboot anyway ... Hmm, did you file a bug? > How do we make sure that if package manager goes crazy the user still > have a way to reboot his system that is not 'press power button for 5 > seconds' ? If you have a shell then systemd actually offers you tree ways to reboot the system, depending on how tough you think you are: # systemctl reboot This does the normal clean reboot, stops all services cleanly, ... # systemctl reboot -f This does not stop all services cleanly, simply kills all processes with SIGTERM and after a short timeout with SIGKILL, but it does try to unmount/detach all file systems/storage devices/swaps/... and the reboots. This is something like a "yes, i want it know, but i don't like fsck delaying my next boot". # systemctl reboot -ff This is the super hardcore reboot. It just invokes the reboot() system call immediately. Your file systems are likely to be dirty on the boot. During the update process you will find that the usualy gettys are available on tty[2-6]. Now, the way how the btrfs snapshotting should be implemented should probably be something like this: a) make a snapshot of the fs, and make it where all changes from now on are written to, but do not make it the default snapshot to be mounted for the next boot. b) make the updates c) if the update succeeded make the previously created snapshot the new default, otherwise just drop it. The result of this will be that the OS will either be in the old state, or in the new state, but not in half-way state. This should also allow the user to hard reboot any time without any ill-effect. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel