Re: /usr is not mounted. This is not supported.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Tom Gundersen wrote:

> On Tue, Oct 25, 2011 at 2:12 PM, clemens fischer ... wrote:

(Removed email.  No need to atract spammers!)

>> What patch would that be?  THE-FAVOURITE-SEARCH-ENGINE didn't pull
>> anything useful for "patch Thomas-Bächler busybox".  Can somebody point
>> us to the relevant code, please?
>
> Thomas is right, that is not strictly speaking needed (but see below).
>
>> A hook to mount the users /usr would presumably go right before
>>
>>  "if [ -x /lib/udev/udevd ]; then"
>>
>> in "/lib/initcpio/init"?
>
> This is what I had in mind:
> <https://github.com/teg/mkinitcpio/commit/76dacf8b9de9cc0409741840b1d8e449862fc846>.

But what is this?

    10  +In order for this to work, /usr needs to be in your /etc/fstab and it
    11  +should be marked for not being fsck'ed (the last option should be 0).

This is getting weird.  Who/what is going to fsck(8) /usr then?

> To make it work nicely, we should also add the dual logic to shutdown:
> <https://github.com/teg/mkinitcpio/commit/42610beb5a317d63dc76dabb72a9061a799b280b>,
> which will pivot back to the initramfs and unmount /usr cleanly. This
> is where we need some busybox work, and I guess this patch should be
> discussed a bit more, maybe it is not the best way to do it.

Pardon me, but I'm not sure I want to keep all of the initramfs around
after regular operation of the system commences.

>> Are the symlinks in "/dev/disk/by-label/" by then?  I guess not, since
>> udevd rules are responsible for setting them up, right?

I object to prohibit the use of LABEL/UUID to identify /usr (or any
other fs for that matter) if that's what all this boils down to.  I keep
a backup and a rescue system around, with some filesystems shared
between them.  Sometimes I shuffle them around, eg. for testing
alternatives like btrfs etc.  For consistently identifying them they get
labels, and I'm sure other people rely on labels as well.

>> So how do the boot-loaders do this?  My first thought was to have
>> a kernel command line parameter
>> "mnt_usr_from=/dev/disk/by-label/my-usr" or whatever and then use
>> busybox' ``mount "$mnt_usr_from" /usr''.
>>
>> I do find it annoying to have /usr with all the bulky GUI crap,
>> audio-tools and whatnot in "/".  FreeBSD has a clean separation
>> between what's needed to bring up, build and run a basic system ( ->
>> /usr ) and user-toys, including all the GUI and multimedia stuff ( ->
>> /usr/local ).
>>
>> I always regret linux cramming everything into /usr.  Some vital
>> programs needed at startup are in /[s]bin, some in /lib, but look at
>> the rules in /lib/udev/rules.d/: while vboxdrv and alsa-restore could
>> equally well run when /usr is finally up, the device-mapper rules
>> check for dmsetup residing in usr/sbin, although they are needed
>> early!
>
> It is currently a mess. I agree with the people advocating putting
> everything in /usr (and symlink /bin, /sbin and /lib for
> compatibility). That obviously requires being able to mount /usr from
> initramfs.

... which is more complicated than I thought.  We should agree on
a clean future-proof concept.


clemens



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux