On Tue, May 17, 2011 at 05:37:18PM +0200, Santiago Vila wrote: > On Sat, 14 May 2011, Roger Leigh wrote: > > > Just FYI, initscripts has now entered unstable to introduce /run > > support. If you would like to re-introduce /run into base-files > > that would be great. > > > > There will be a window of potential breakage if base-files is > > upgraded prior to initscripts and initramfs-tools if the system is > > rebooted mid-way. At this point, /run will exist but will not be > > mounted by either initramfs-tools or initscripts. Rather than > > initscripts or initramfs-tools having a strict dependency on a > > new base-files or breaks on older versions (neither of which is true), > > I think the cleanest way would be if base-files could have a > > Breaks on initscripts (<< 2.88dsf-13.3), initramfs-tools (<< 0.99) > > which will ensure that they are upgraded first when doing a > > squeeze→wheezy upgrade. > > I wonder: If it's initscripts the package adding support for /run, why > not just add /run in initscripts and wait until wheezy+1 before adding > it to base-files? > > I feel that we are relying too much on base-files for no particular > reason. In fact, I don't see any benefit of having /run in base-files > at this point.
The main need for this is debootstrap. There's two possible ways
initscripts can handle the migration:
1) Normal system
- on installation, bind mount /var/run to /run, /var/lock to /run/lock
- on reboot, set up /run as a tmpfs and convert the original locations
to symlinks
2) Chroot or other virtual environment
- the above isn't possible (no scripts run on startup etc.)
- on installation, symlink /run → /var/run and
/run/lock (/var/run/lock) → /var/lock
(2) is only desirable on upgrade of a chroot due to issues moving files
and directories. For a clean debootstrap, we want the proper hierarchy.
> > It would be nice if on new installs /var/run and /var/lock could be
> > created as symlinks to /run and /run/lock. This will mean that
> > debootstrapped chroots will have a valid setup here, since they
> > will never be booted directly initscripts can't do this, and
> > it's also too hairy for initscripts to do this to a chroot in its
> > postinst.
>
> Hmm, creating /var/lock as a symlink to /run/lock when /run is still empty
> is not going to be nice either, as it would be a dangling symlink.
Maybe base-files could also provide /run/(lock|shm)? On a normal
system, these will be hidden by the /run tmpfs, but will be used
(potentially) in a chroot environment. This would ensure that the
links are always valid.
> Again: Is it necessary or even useful to rely on base-files for this?
>
> How will this be handled on already running systems? Would be possible
> to do the same for not-yet-running systems?
If it's not done in base-files, I'm not sure where would be best to
do this. initscripts is handling the migration of existing
installations, and it does a perfectly good job for normal systems;
however, chroot environments can't be catered for as well as I'd
like. While we do a best-effort faking of the /run hierarchy using
the existing /var directories and some symlinks, this isn't what we
want for new installs. Unfortunately, by the time debootstrap
configures initscripts, base-files already created /var/(run|lock)
and we can't reliably replace them with symlinks at that point.
In consequence, I would suggest that base-files could provide:
/run
/run/lock
/run/shm
/var/run → /run [symlink]
/var/lock → /run/lock [symlink]
The symlinks could be created in the postinst if they don't already
exist (the directories would cease to be provided by the package
directly).
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.
signature.asc
Description: Digital signature
