On Fri, Apr 15, 2011 at 03:26:59PM +0100, Edward Allcutt wrote: > On Fri, 15 Apr 2011, Roger Leigh wrote: > >On Fri, Apr 15, 2011 at 01:38:34PM +0100, Edward Allcutt wrote: > >Your assumption is correct in that this is a fallback. This is the > >special case for chroots, also co-opted for vservers, which don't "boot" > >per se, and don't run the rcS scripts. The consequence of this is that > >we can't do any setup at boot time; the chances are that no filesystems > >will be mounted at all, and if there are, we don't have any control over > >that process. This means that the migration in postinst is unfortunately > >a "best effort"; I'd like to make it more reliable if at all possible. > > In the case described, with a writable / and no tmpfs, what is the downside > to my suggestion? /run would remain linked to /var/run forevermore[0] if > the boottime switcheroo does not happen, but that doesn't seem so terrible. > Both /run and /var/run will remain writable and effectively the same location, > which points to the other isn't terribly important in the short term. ... > Copying the contents is the main thing I'm objecting to. I'm proposing creating > symlinks which do allow a transparent transition and leaving it to the admin to > switch the links around at a convenient time if rc scripts are skipped. Thanks for making me reconsider the approach we were taking with chroots. This is a much better strategy. This does make a lot of sense in a chroot environment, and I've now switched to symlinking /run → /var/run /run/lock (/var/run/lock) → /var/lock /run/shm (/var/run/shm) → /dev/shm This ensures no files are moved during the upgrade, and files are accessible via the old and new paths. Unlike for a host system, we don't start using the new locations as the default, and symlink to them from the old locations. We do it the other way around. If the admin wishes to complete the transition, they will need to move the contents and create the old→new symlinks by hand. This also "solves" the vserver issues, since /var/run and /var/lock will remain directories. But that's a vserver bug needing addressing separately, since at some point in the (distant) future (>= wheezy+1) we will want to ship /var/run and /var/lock as symlinks, and (longer term) remove them entirely perhaps. So with this change in place, upgrading chroots/vservers is as reliable as for hosts. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Attachment:
signature.asc
Description: Digital signature