DebianThis forum is for the discussion of Debian Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Hi, everyone, I put my /usr in another partition different with that for the root. In that case, when system is booting, it is reported that some scripts or applications cannot be found because they are in the /usr/bin or /usr/sbin rather than in /bin or /sbin, for example, the virtualbox. How can I deal with them?
Thank you very much!
All Virtualbox drivers should be in /lib/modules/<kernel-version>/misc for Sid and should be in the same general area for Squeeze and Wheezy. It may depend on your kernel version. Make sure your /usr partition is set correctly in fstab with UUID=. You can find the correct numbers to use in /dev/disk/by-uuid. Usually running update-grub2 will solve the problem.
I'm not sure how much of this applies on Debian, but here are a couple of ways I've worked around issues with this on Red Hat related systems, which also do not officially support a separate /usr file system:
Method 1: Keep a stub /usr tree under /usr on the root file system.
To find what need to go there, you have to dig through the startup scripts and identify all needed programs, data files, and shared libraries. Takes a while, but it's doable. The ongoing problems are keeping those files up to date and the tricks you have to play to back up that part of the root file system. (Temporarily bind-mounting the root file system to a temporary directory is your friend here.)
Method 2: Arrange to mount /usr along with the root file system early in the boot process.
It's easy enough to do. You just need to edit /etc/dracut.conf to uncomment the "add_dracutmodules" line to read
Code:
add_dracutmodules+="fstab-sys"
and create an /etc/fstab.sys file containing a copy of the "/usr" line from /etc/fstab. Then you need to rebuild the /boot/initramfs image. Reinstalling the kernel will do that, or you can get a hint from the kernel's postinstall script and work out the needed call to /sbin/new-kernel-pkg. You also need to disable the boot-time fsck of /usr by putting a "0" in the sixth field of its /etc/fstab entry. With /usr is already mounted, that fsck will always fail, so you won't be able to boot unless you disable it. The ongoing issue, of course, is that you will never get an automatic fsck of the /usr file system.
I've used both methods successfully, and found method 2 best for me. My /usr is normally mounted read-only, and can easily be checked by "fsck -n" while the system is running.
Last edited by rknichols; 09-23-2011 at 04:13 PM.
Reason: Add change to /etc/dracut.conf
All Virtualbox drivers should be in /lib/modules/<kernel-version>/misc for Sid and should be in the same general area for Squeeze and Wheezy. It may depend on your kernel version. Make sure your /usr partition is set correctly in fstab with UUID=. You can find the correct numbers to use in /dev/disk/by-uuid. Usually running update-grub2 will solve the problem.
If that does not work post more info.
Virtualbox driver is all right. Actually it is just an examaple. I get the first error from udev which reports
can not find /usr/sbin/alsactl : no such a file or directory.
However, /usr/sbin/alsactl exists. It is just because that /usr partition is not mounted at that time.
Thank you so much! It seems very complex, but I will try it. I am just wondering the structure of packages. If they are needed before mounting, they shouldn't be put in other partitions except root because debian installation support seperate /usr /var and so on.
Quote:
Originally Posted by rknichols
I'm not sure how much of this applies on Debian, but here are a couple of ways I've worked around issues with this on Red Hat related systems, which also do not officially support a separate /usr file system:
Method 1: Keep a stub /usr tree under /usr on the root file system.
To find what need to go there, you have to dig through the startup scripts and identify all needed programs, data files, and shared libraries. Takes a while, but it's doable. The ongoing problems are keeping those files up to date and the tricks you have to play to back up that part of the root file system. (Temporarily bind-mounting the root file system to a temporary directory is your friend here.)
Method 2: Arrange to mount /usr along with the root file system early in the boot process.
It's easy enough to do. You just need to edit /etc/dracut.conf to uncomment the "add_dracutmodules" line to read
Code:
add_dracutmodules+="fstab-sys"
and create an /etc/fstab.sys file containing a copy of the "/usr" line from /etc/fstab. Then you need to rebuild the /boot/initramfs image. Reinstalling the kernel will do that, or you can get a hint from the kernel's postinstall script and work out the needed call to /sbin/new-kernel-pkg. You also need to disable the boot-time fsck of /usr by putting a "0" in the sixth field of its /etc/fstab entry. With /usr is already mounted, that fsck will always fail, so you won't be able to boot unless you disable it. The ongoing issue, of course, is that you will never get an automatic fsck of the /usr file system.
I've used both methods successfully, and found method 2 best for me. My /usr is normally mounted read-only, and can easily be checked by "fsck -n" while the system is running.
Checking the Debian installation guide, I see that a separate /usr file system is indeed supported and recommended (except for single user systems with a small disk), which implies that packages really should use the root file system for any files needed before other partitions are mounted. I suspect, though, that this is a case of the installation guide not reflecting the actual needs of the current system. I know it took a while for the Red Hat / Fedora documentation to get rid of all recommendations for a separate /usr. If I were a Debian user, I'd report it as a bug in the documentation and perhaps in the installer too.
That of course still leaves you needing a workaround for your immediate problem. Because of my unfamiliarity with Debian, I really can't offer anything more specific or detailed than what I have already said. For me, method 2 actually turned out to be way easier than I thought it would be.
Thank you so much! It seems very complex, but I will try it. I am just wondering the structure of packages. If they are needed before mounting, they shouldn't be put in other partitions except root because debian installation support seperate /usr /var and so on.
The problem is Debian does not have /etc/dracut.conf. You would have to change the order in /etc/rcS.d but I'm not sure what the risk of doing this would be if any.
Okay on further investigation you will notice durring the initial boot before entering a run level. alsa-utils is at locaton S20 and the everything in /etc/fstab is mounted at S10mountall.sh. Make sure your alsa-utils is at the bottom. Then everything should work as advertised.
It is weird that udev reports that error message to me. It is supposed not to start alsa so early.
Not at all you have one of two problems. Your startup scrips are in the wrong order or /etc/fstab is miss configured. Post your /etc/fstab so someone can help you sort this out
Code:
chevy@sid:~$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# / was on /dev/sdb2 during installation
UUID=306fa650-10f1-45ca-a092-4d04cc303113 / ext3 errors=remount-ro 0 1
# swap was on /dev/sdb3 during installation
UUID=eefdb15d-3ec4-423c-a302-54805faf3422 none swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0
# /dev/sdb1 /home/chevy/Storage auto defaults 0 0
UUID=5de3ac62-e037-47fd-9bfb-5614d48d3bc6 /home/chevy/Storage auto defaults 0 0
And the second one too so a comparison can be made.
Edit: on the off chance that something got added to /etc/modules post that too.
Code:
chevy@sid:~$ cat /etc/modules
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
# Parameters can be specified after the module name.
loop
# Generated by sensors-detect on Sun Sep 11 12:02:49 2011
# Chip drivers
w83627ehf
Last edited by 62chevy; 09-25-2011 at 12:32 PM.
Reason: more info
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# / was on /dev/sda6 during installation
UUID=dfe740b0-c4ce-4388-bada-5b2e068467af / ext3 errors=remount-ro 0 1
# /home was on /dev/sda8 during installation
UUID=5cec433e-3d6d-4ebf-a95e-0ae03b3a118a /home ext3 defaults 0 2
# /usr was on /dev/sda7 during installation
UUID=30e58188-9d66-4e00-b31e-c30336b66112 /usr ext3 defaults 0 2
# swap was on /dev/sda11 during installation
UUID=44ae0517-5d63-4d09-81e0-409e7126e5b0 none swap sw 0 0
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
# Parameters can be specified after the module name.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
Error information when booting: cann't find /usr/
