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 > ArchLinux > ArchLinux General Discussion

 
 
LinkBack Thread Tools
 
Old 10-24-2011, 02:42 PM
Dwight Schauer
 
Default /usr is not mounted. This is not supported.

I've been using Arch Linux for about 4 years now. I have it on a few
important systems at work and it has been doing very well.

This morning I saw "/usr is not mounted. This is not supported." in my
boot up after a recent rc.sysinit update.

What is this, bait and switch? I've been running Linux and BSD systems
since 1996 and typically always have /usr in a separate partition (as
well as /var, /home/ and /tmp, but lately been using a ram /tmp).

Why does /usr even exist if it can't be on a separate partition? Why
not just combine /usr/lib and /lib? And /usr/bin and /bin? And
/usr/sbin and /sbin? Why have the distinction at all if it can't be on
separate partition?

I understand that historically that /usr often use to be on different
drive, and that is not really an issue nowadays. Only this year have I
started not putting /usr into separate partitions because I've been
making thumbdrive installs, and did not really see any benefit to
making so many partitions (automatically created anyways, with a
custom install script).

Does this "/usr is not mounted. This is not supported." mean I'm going
to have to eventually fix (dump/fix/restore) all my systems that are
now currently running fine (and that I and others are depending on at
my work) because Arch Linux no longer supports /usr on a different
partition (due to rc.sysinit failing, not just printing an error
message)? I run Arch Linux on more than 10 systems, and about 6 or 7
of those are at work (where Arch has been working out very well).

I'm not looking forward to redoing all these systems that are running
fine if this is where Arch is headed and rc.sysinit is not fixed to
take out this new requirement.

I know this a bit of a rant, but this "/usr is not mounted. This is
not supported." error message is definitely not getting this day off
to a good start...

Definitely not wanting to give up Arch for such a simple issue....

Dwight
 
Old 10-24-2011, 02:59 PM
Sander Jansen
 
Default /usr is not mounted. This is not supported.

This is not a new thing, it has been "broken" for quite a while.

http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken


Sander

On Mon, Oct 24, 2011 at 9:42 AM, Dwight Schauer <dschauer@gmail.com> wrote:
> I've been using Arch Linux for about 4 years now. I have it on a few
> important systems at work and it has been doing very well.
>
> This morning I saw "/usr is not mounted. This is not supported." in my
> boot up after a recent rc.sysinit update.
>
> What is this, bait and switch? I've been running Linux and BSD systems
> since 1996 and typically always have /usr in a separate partition (as
> well as /var, /home/ and /tmp, but lately been using a ram /tmp).
>
> Why does /usr even exist if it can't be on a separate partition? Why
> not just combine /usr/lib and /lib? And /usr/bin and /bin? And
> /usr/sbin and /sbin? Why have the distinction at all if it can't be on
> separate partition?
>
> I understand that historically that /usr often use to be on different
> drive, and that is not really an issue nowadays. Only this year have I
> started not putting /usr into separate partitions because I've been
> making thumbdrive installs, and did not really see any benefit to
> making so many partitions (automatically created anyways, with a
> custom install script).
>
> Does this "/usr is not mounted. This is not supported." mean I'm going
> to have to eventually fix (dump/fix/restore) all my systems that are
> now currently running fine (and that I and others are depending on at
> my work) because Arch Linux no longer supports /usr on a different
> partition (due to rc.sysinit failing, not just printing an error
> message)? I run Arch Linux on more than 10 systems, and about 6 or 7
> of those are at work (where Arch has been working out very well).
>
> I'm not looking forward to redoing all these systems that are running
> fine if this is where Arch is headed and rc.sysinit is not fixed to
> take out this new requirement.
>
> I know this a bit of a rant, but this "/usr is not mounted. This is
> not supported." error message is definitely not getting this day off
> to a good start...
>
> Definitely not wanting to give up Arch for such a simple issue....
>
> Dwight
>
 
Old 10-24-2011, 03:03 PM
Mantas MikulÄ—nas
 
Default /usr is not mounted. This is not supported.

On 2011-10-24 17:42, Dwight Schauer wrote:

This morning I saw "/usr is not mounted. This is not supported." in my
boot up after a recent rc.sysinit update.

What is this, bait and switch? I've been running Linux and BSD systems
since 1996 and typically always have /usr in a separate partition (as
well as /var, /home/ and /tmp, but lately been using a ram /tmp).


See
<http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken>
for an explanation on why booting without a separate /usr does not
really work, as well as this thread
<http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/1337>.


Note I said "booting". If /usr is mounted by your initramfs, it's
perfectly fine.



Why does /usr even exist if it can't be on a separate partition? Why
not just combine /usr/lib and /lib? And /usr/bin and /bin? And
/usr/sbin and /sbin? Why have the distinction at all if it can't be on
separate partition?


I remember reading a few mailing list posts about this, but can't find
them right now.
<http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/3480> appears
to be relevant -- it's easier to snapshot a single /usr than
/bin+/lib+/sbin+...:


| The point is not to have 6-10 top-level dirs for the system to manage,
| but only a single one. We need a single point to snapshot or share.

--
Mantas M.
 
Old 10-24-2011, 03:05 PM
Thomas Bächler
 
Default /usr is not mounted. This is not supported.

Am 24.10.2011 16:42, schrieb Dwight Schauer:
> I've been using Arch Linux for about 4 years now. I have it on a few
> important systems at work and it has been doing very well.
>
> This morning I saw "/usr is not mounted. This is not supported." in my
> boot up after a recent rc.sysinit update.

Basically, we will not fix any bugs in the future that are the result of
a separate /usr, we will instantly close them instead. The link Sander
posted gives a few examples.

If everything works fine for you, then nothing changes for you.

> Does this "/usr is not mounted. This is not supported." mean I'm going
> to have to eventually fix (dump/fix/restore) all my systems

No. Even if things fail entirely, we will provide a hook for mkinitcpio
that mounts /usr before switching to the real root filesystem. This will
eliminate all your potential bugs. However - this hook hasn't been
written yet.
 
Old 10-24-2011, 06:18 PM
Tom Gundersen
 
Default /usr is not mounted. This is not supported.

On Mon, Oct 24, 2011 at 4:42 PM, Dwight Schauer <dschauer@gmail.com> wrote:
> I've been using Arch Linux for about 4 years now. I have it on a few
> important systems at work and it has been doing very well.
>
> This morning I saw "/usr is not mounted. This is not supported." in my
> boot up after a recent rc.sysinit update.
>
> What is this, bait and switch? I've been running Linux and BSD systems
> since 1996 and typically always have /usr in a separate partition (as
> well as /var, /home/ and /tmp, but lately been using a ram /tmp).
>
> Why does /usr even exist if it can't be on a separate partition? Why
> not just combine /usr/lib and /lib? And /usr/bin and /bin? And
> /usr/sbin and /sbin? Why have the distinction at all if it can't be on
> separate partition?

Several people already pointed out the relevant information about
this, but I thought I should offer my two cents as I was responsible
for the error message.

The situation is currently that lots of tools break silently if /usr
is not mounted at boot. In most cases you will not notice, and in the
cases you do notice it is really difficult to tell what is actually
going on.

From time to time we get bug reports that are really difficult to
debug, and that eventually turn out to be due to a separate /usr. Once
we figure out the cause, we usually end up having to say, sorry, there
is nothing we can do about that, but in the meantime we have wasted a
lot of time. Therefore, we really want to get the message out there
that at the moment things simply don't work as they should with a
separate /usr. Then people will at least know that this is a likely
cause of any weird problems they experience.

There are two ways to solve this: either merge your / and your /usr
partitions, or make your initramfs mount /usr so init won't even know
that /usr is separate.

We are currently working on adding support for the second approach,
but we are not there yet (I have some patches against mkinitcpio to
add this, but they rely on a patch by Thomas against busybox that has
not yet landed upstream).

Cheers,

Tom
 
Old 10-25-2011, 12:09 AM
Dwight Schauer
 
Default /usr is not mounted. This is not supported.

On Mon, Oct 24, 2011 at 1:18 PM, Tom Gundersen <teg@jklm.no> wrote:
> There are two ways to solve this: either merge your / and your /usr
> partitions, or make your initramfs mount /usr so init won't even know
> that /usr is separate.
>
> We are currently working on adding support for the second approach,
> but we are not there yet (I have some patches against mkinitcpio to
> add this, but they rely on a patch by Thomas against busybox that has
> not yet landed upstream).
>

Ok, so it is not as much of a problem as I initially thought it would be.

On new large media installs I'll try to not use /usr until this gets
resolved. On current installs they all seem to be working fine (I've
not noticed any lack of functionality) I'll just wait until the
mkinitcpio patches are completed and mkinitcpio is released with /usr
mount support.

Thanks,
Dwight Schauer
 
Old 10-25-2011, 12:12 PM
clemens fischer
 
Default /usr is not mounted. This is not supported.

Tom Gundersen wrote:

> From time to time we get bug reports that are really difficult to
> debug, and that eventually turn out to be due to a separate /usr. Once
> we figure out the cause, we usually end up having to say, sorry, there
> is nothing we can do about that, but in the meantime we have wasted a
> lot of time. Therefore, we really want to get the message out there
> that at the moment things simply don't work as they should with a
> separate /usr. Then people will at least know that this is a likely
> cause of any weird problems they experience.
>
> There are two ways to solve this: either merge your / and your /usr
> partitions, or make your initramfs mount /usr so init won't even know
> that /usr is separate.
>
> We are currently working on adding support for the second approach,
> but we are not there yet (I have some patches against mkinitcpio to
> add this, but they rely on a patch by Thomas against busybox that has
> not yet landed upstream).

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?

A hook to mount the users /usr would presumably go right before

"if [ -x /lib/udev/udevd ]; then"

in "/lib/initcpio/init"?

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

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!


clemens
 
Old 10-25-2011, 12:18 PM
clemens fischer
 
Default /usr is not mounted. This is not supported.

Thomas Bächler wrote:

> No. Even if things fail entirely, we will provide a hook for
> mkinitcpio that mounts /usr before switching to the real root
> filesystem. This will eliminate all your potential bugs. However
> - this hook hasn't been written yet.

Imagine somebody with a desktop arch-linux. For some reason his system
"fails entirely". Should he or she now mess with a live-CD to backport
the yet unwritten hook once it is finished and doodle on his thumbs
waiting for it? Reinstall everything?


clemens
 
Old 10-25-2011, 01:59 PM
Thomas Bächler
 
Default /usr is not mounted. This is not supported.

Am 25.10.2011 14:12, schrieb clemens fischer:
>> We are currently working on adding support for the second approach,
>> but we are not there yet (I have some patches against mkinitcpio to
>> add this, but they rely on a patch by Thomas against busybox that has
>> not yet landed upstream).
>
> 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?

I am not sure which patch he means. I wrote something recently, but I
only shared that with Tom in private conversations and it is not related
to this issue.

> A hook to mount the users /usr would presumably go right before
>
> "if [ -x /lib/udev/udevd ]; then"
>
> in "/lib/initcpio/init"?
>
> Are the symlinks in "/dev/disk/by-label/" by then? I guess not, since
> udevd rules are responsible for setting them up, right?

Mounting /usr needs to go to the initramfs. It is possible to implement
a mount handler for this. At this stage, the by-label symlinks exist
already.
 
Old 10-25-2011, 02:19 PM
Dwight Schauer
 
Default /usr is not mounted. This is not supported.

On Tue, Oct 25, 2011 at 8:59 AM, Thomas Bächler <thomas@archlinux.org> wrote:
> Mounting /usr needs to go to the initramfs. It is possible to implement
> a mount handler for this. At this stage, the by-label symlinks exist
> already.

Would the /usr location be determined when the initramfs is created,
or would it determine the location at runtime via /etc/fstab? Just
wanted to make sure it is the latter.

By label? Is that assuming /usr location can be guessed by the label?
That would not work on a lot of setups. Even if a mountpoint in label
was used, that does not account for multiple disks attached, all with
Linux installs on them.

Or by by-label do you mean because /etc/fstab is being used, possibly
with a label in the entries (I use by-uuid entries) that the correct
one will be chosen?
 

Thread Tools




All times are GMT. The time now is 10:01 PM.

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