[Pkg-sysvinit-devel] Processed: Re: Bug#494001: debian-installer: /etc/mtab must be a symlink to /proc/mounts with linux >= 2.6.26

[Roger Leigh]

Henrique de Moraes Holschuh wrote:
> On Wed, 18 Mar 2009, Roger Leigh wrote:
>> On Wed, Mar 18, 2009 at 05:38:38PM -0300, Henrique de Moraes Holschuh wrote:
>>> Are there other parts of Squeeze that would malfunction with Linux kernels
>>> older than 2.6.26 ?
>>>
>>> The version check is pretty much a good idea for safety reasons, I think it
>>> would be better to just leave it in, and we can get rid of it for Squeeze+1.
>> Agreed.  I've attached a new patch with a version check.  I've now
>> tested the patch by installing the package, and it correctly updates
>> the symlink, and also preserves it if already a symlink.  The only
>> corner case we have here is if the admin already deliberately
>> symlinked it somewhere else--we won't link it to /proc/mounts in
>> this case (do we want to trample on the admins changes in this
>> case?).
>>
>> I used dpkg --compare-versions, which I hope is OK for kernel revisions.
> 
> The more I think about it, the less I like this way of doing things.
> 
> You have to adjust to the running kernel, at every boot.  It is *normal* to
> boot on kernel x.y.z, then go back to x.y-1.z, etc.

True, and I did consider this.  However, it was pointed out that since 
squeeze would not run with kernels < 2.6.26, and Lenny uses 2.6.26, so 
this checking was pointless, even on upgrades.  Since the postinst is 
run only once, the version check is probably redundant here as well.

> I.e. call uname, and find out what kernel you're dealing with at that boot,
> and have /etc/mtab set up before mount (or anything else) needs it.  That
> means early initscript, not postinst.

I did originally modify mtab.sh to check the kernel version and then 
either create a symlink or an empty file depending upon the kernel 
version.  However, the consensus was that this was pointless and that it 
should just be done "once and for all" in the postinst.

> In the end, it really means we should teach mount to know what to do by
> itself, and get rid of /etc/mtab, if we want to fix things properly.

What should mount do?  If mtab is a symlink, it then doesn't do any 
updating at all.  Removing mtab itself is a tricker (and IMO separate) 
issue, since many programs are using setmntent(3) to open it and this 
would require the updating of many programs (and the change would also 
be Linux-specific and non-portable).

By the way, if mtab is a symlink on Linux < 2.6.26, then the system will 
continue to work without problems.  I've used Linux systems configured 
this way for many years.  The only potential problems are if other 
programs want to check the extended mount options (such as for diskquota 
checking); for most uses this is not a problem.  The only uses who will 
be affected are those running an old and unsupported kernel version.


Regards,
Roger