FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 12-19-2011, 07:10 PM
Roger Leigh
 
Default Bug#652459: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

On Sun, Dec 18, 2011 at 03:37:43AM +0100, Marco d'Itri wrote:
> On Dec 17, Roger Leigh <rleigh@codelibre.net> wrote:
>
> > So WRT mounting /usr (and potentially /etc and other filesystems),
> > I've pushed patches upstream for util-linux (initramfs mount option)
> > and initramfs-tools (generate /etc/fstab from host and mount after
> > rootfs).

(Merging this and the reply to #652459)

I'd just like to clear up a few points about the desired behaviour and
requirements for the initramfs. I have some ideas about other ways
to achieve this goal.

> > 1) Generation of /etc/fstab in the initramfs, including the rootfs
> > and all the filesystems desired to be mounted
> This is highly suboptimal, because it suddenly makes the initramfs not
> generic anymore.
> The initramfs should:
> - mount / as usual
> - look at the rootfs fstab
> - mount /usr using the information from the rootfs fstab

Regarding keeping the initramfs generic, we already permit hardcoding of
the rootfs into the image. This is overridden by root=xxx, but still
permitted. I'm not sure I see the difference between hardcoding the
root device rather than an fstab entry.

There is of course the addition of the mount options, which might be
incompatible if the fstype of the rootfs changes.

> > 2) In local mountroot(), rather than just mounting the rootfs, loop
> > over all mountpoints in /etc/fstab and mount them.
> If there is no need to mount file systems other than /usr, why do it?

It would permit additional flexibility for initramfs extensions by
users. I'm not sure if this is necessarily a good or bad thing. If
it's desirable not to permit this, I'm sure we can find a better way.

Mounting /usr is obviously the main goal here. Whether or not we
migrate stuff to or from /usr, we would still need to have the ability
to mount /usr in the initramfs for compatibility with systems with a
separately-mounted /usr, in order to privide the guarantee that /usr
is available in early boot.

Mounting /etc separately is not essential, but this would be a nice-to-
have feature for those who wish to encrypt it.

> > and other files to the root filesystem. It additionally permits
> > mounting of /etc separately, thereby permitting it to be
> > encrypted and/or writable while the root filesystem is
> > unencrypted and/or read-only.
> I do not believe that this is desireable, it is complex and would come
> for free anyway by a / -> /usr move.

Why would it come for free? You would still have files in places other
than /etc on the rootfs. And if we are deprecating a separate /usr, it
doesn't solve the problem at all, since everything would be on the rootfs,
and then everything would be encrypted. As mentioned earlier in the
thread, encrypting /etc is an entirely different problem than mounting
/usr separately--a separate mount would IMO be the best solution to this
problem, and mounting it in the initramfs is certainly technically
possible.


Regarding the objections above, which are primarily concerned with the
creation of a non-generic initramfs, how does this alternative suggestion
sound:

- The addition of usr= options analogous to the root= options which
permit the bootloader to specify the /usr filesystem to mount. By
default would do nothing, but grub could be updated to generate
such options on systems with a separate /usr.
- We could also add an additional etc= option with the same semantics.

I'll be happy to implement this if this sounds more acceptable than the
existing approach. It does, I think, address your primary criticisms.


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.



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111219201051.GB5437@codelibre.net">http://lists.debian.org/20111219201051.GB5437@codelibre.net
 
Old 12-19-2011, 10:11 PM
"J.A. Bezemer"
 
Default Bug#652459: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

On Mon, 19 Dec 2011, Roger Leigh wrote:

[..]


Regarding the objections above, which are primarily concerned with the
creation of a non-generic initramfs, how does this alternative suggestion
sound:

- The addition of usr= options analogous to the root= options which
permit the bootloader to specify the /usr filesystem to mount. By
default would do nothing, but grub could be updated to generate
such options on systems with a separate /usr.


Nonsense, should come from /etc/fstab.



- We could also add an additional etc= option with the same semantics.


Something like this would be necessary to support separately mounted /etc,
but I see that as a completely separate discussion. Also note that you
would need to patch _all_ existing bootloaders for _all_ arches to
automatically include that option in any generated config file (namely by
parsing the one&only main config location which is /etc/fstab or possibly
/etc/fstab.d).


Related issue: how to specify desired fsck options (such as FSCKFIX) for /
and /etc, while /etc is not yet mounted.



Next, you'll be arguing that /etc/fstab should be moved to /. And
/etc/default/rcS too.



Oh, and now that I'm at it, do we also have initramfs support for
bootlogd? and keyboard-setup? and hwclockfirst? (Last two could be
required for proper fsck on various arches.) Plus their config files.



Best regards,

Anne Bezemer



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: Pine.LNX.4.64.1112192352230.14883@wormhole.robuust .nl">http://lists.debian.org/Pine.LNX.4.64.1112192352230.14883@wormhole.robuust .nl
 
Old 12-19-2011, 11:15 PM
Roger Leigh
 
Default Bug#652459: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

On Tue, Dec 20, 2011 at 12:11:39AM +0100, J.A. Bezemer wrote:
>
> On Mon, 19 Dec 2011, Roger Leigh wrote:
>
> [..]
> >
> >Regarding the objections above, which are primarily concerned with the
> >creation of a non-generic initramfs, how does this alternative suggestion
> >sound:
> >
> >- The addition of usr= options analogous to the root= options which
> > permit the bootloader to specify the /usr filesystem to mount. By
> > default would do nothing, but grub could be updated to generate
> > such options on systems with a separate /usr.
>
> Nonsense, should come from /etc/fstab.

Of course. In case it wasn't implicit from the above, this information
would necessarily need to be taken from /etc/fstab by update-grub or
its equivalent for other bootloaders when generating grub.cfg (or its
equivalent). They presumably already do the same for / (or look at the
current rootfs), so it's simply copying existing practice for the
rootfs.

> >- We could also add an additional etc= option with the same semantics.
>
> Something like this would be necessary to support separately mounted
> /etc, but I see that as a completely separate discussion. Also note
> that you would need to patch _all_ existing bootloaders for _all_
> arches to automatically include that option in any generated config
> file (namely by parsing the one&only main config location which is
> /etc/fstab or possibly /etc/fstab.d).

Agreed. In order to guarantee that /usr is always available, we will
need to support this for all bootloaders.

As an aside, this support would only be required for situations where
a separate /usr is used /and/ stuff on /usr is required for early boot.
Support for minor tools/platforms might not be required since the other
solution is simple: keep /usr on the rootfs if you need those
guarantees.

Either way, having support in the initramfs is a prerequisite for
updating the bootloaders.

> Related issue: how to specify desired fsck options (such as FSCKFIX)
> for / and /etc, while /etc is not yet mounted.

I would presume that this would be unchanged. By the time fsck is
run, you'll have / and additionally /etc and/or /usr mounted, so
keeping it on /etc will be just fine.

> Next, you'll be arguing that /etc/fstab should be moved to /. And
> /etc/default/rcS too.

No. I'm simply proposing a way to make additional guarantees about
the availability of /usr in early boot. Nothing else is changed
except for when /usr is mounted.


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.



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111220001514.GD5437@codelibre.net">http://lists.debian.org/20111220001514.GD5437@codelibre.net
 
Old 12-20-2011, 11:17 AM
"J.A. Bezemer"
 
Default Bug#652459: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

On Tue, 20 Dec 2011, Roger Leigh wrote:

On Tue, Dec 20, 2011 at 12:11:39AM +0100, J.A. Bezemer wrote:

On Mon, 19 Dec 2011, Roger Leigh wrote:

[..]


Regarding the objections above, which are primarily concerned with the
creation of a non-generic initramfs, how does this alternative suggestion
sound:

- The addition of usr= options analogous to the root= options which
permit the bootloader to specify the /usr filesystem to mount. By
default would do nothing, but grub could be updated to generate
such options on systems with a separate /usr.


Nonsense, should come from /etc/fstab.


Of course. In case it wasn't implicit from the above, this information
would necessarily need to be taken from /etc/fstab by update-grub or
its equivalent for other bootloaders when generating grub.cfg (or its
equivalent).


Apologies for not being clear enough: there should not be a usr= parameter
at all. Not in grub.cfg, and not anywhere else. The initramfs itself can
(i.e. should) easily read it directly from /etc/fstab.


(As I remember seeing elsewhere in this discussion: you could define a
mount option "mount-in-initramfs" in /etc/fstab that the initramfs should
look for to find out which filesystems it has to fsck && mount.)



Best regards,

Anne Bezemer



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: Pine.LNX.4.64.1112201247070.18826@wormhole.robuust .nl">http://lists.debian.org/Pine.LNX.4.64.1112201247070.18826@wormhole.robuust .nl
 
Old 12-20-2011, 03:56 PM
Roger Leigh
 
Default Bug#652459: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

On Tue, Dec 20, 2011 at 01:17:41PM +0100, J.A. Bezemer wrote:
>
> On Tue, 20 Dec 2011, Roger Leigh wrote:
> >On Tue, Dec 20, 2011 at 12:11:39AM +0100, J.A. Bezemer wrote:
> >>On Mon, 19 Dec 2011, Roger Leigh wrote:
> >>
> >>[..]
> >>>
> >>>Regarding the objections above, which are primarily concerned with the
> >>>creation of a non-generic initramfs, how does this alternative suggestion
> >>>sound:
> >>>
> >>>- The addition of usr= options analogous to the root= options which
> >>>permit the bootloader to specify the /usr filesystem to mount. By
> >>>default would do nothing, but grub could be updated to generate
> >>>such options on systems with a separate /usr.
> >>
> >>Nonsense, should come from /etc/fstab.
> >
> >Of course. In case it wasn't implicit from the above, this information
> >would necessarily need to be taken from /etc/fstab by update-grub or
> >its equivalent for other bootloaders when generating grub.cfg (or its
> >equivalent).
>
> Apologies for not being clear enough: there should not be a usr=
> parameter at all. Not in grub.cfg, and not anywhere else. The
> initramfs itself can (i.e. should) easily read it directly from
> /etc/fstab.

OK, that does make sense. And it can remain entirely generic, without
requiring any special bootloader support.

/etc would be the exception to this, so I guess you would be happy
with that being made into a separate option? This would be a
rare choice, so just patching update-grub should be sufficient.
Anyone else who wished to avail themselves of it could just edit the
kernel command-line.

> (As I remember seeing elsewhere in this discussion: you could define
> a mount option "mount-in-initramfs" in /etc/fstab that the initramfs
> should look for to find out which filesystems it has to fsck &&
> mount.)

This is still a possibility. I discussed an initramfs option for
/etc/fstab, but upstream would perfer us to use comment=initramfs
or the new free-form x- options e.g. x-initramfs. Like /usr, this
could be mounted after the rootfs, with the exception of /etc, as
mentioned above.

WRT fsck, I think we would continue to mount r/o prior to fsck, as
for the rootfs, and then remount r/w afterward in checkroot.


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.



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111220165603.GG5437@codelibre.net">http://lists.debian.org/20111220165603.GG5437@codelibre.net
 

Thread Tools




All times are GMT. The time now is 09:42 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org