LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Debian (http://www.linuxquestions.org/questions/debian-26/)
-   -   Error information when booting: cann't find /usr/ (http://www.linuxquestions.org/questions/debian-26/error-information-when-booting-cannt-find-usr-904645/)

bingmou 09-23-2011 12:47 PM

Error information when booting: cann't find /usr/
 
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!

62chevy 09-23-2011 03:14 PM

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.

rknichols 09-23-2011 05:08 PM

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.

bingmou 09-24-2011 02:59 PM

Quote:

Originally Posted by 62chevy (Post 4480425)
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.

bingmou 09-24-2011 03:06 PM

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 (Post 4480522)
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.


rknichols 09-24-2011 06:34 PM

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.

62chevy 09-24-2011 10:54 PM

Quote:

Originally Posted by bingmou (Post 4481258)
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.

62chevy 09-24-2011 11:12 PM

Code:

:/home/chevy# ls -l /etc/rcS.d
total 4
-rw-r--r-- 1 root root 447 Jul 13 15:41 README
lrwxrwxrwx 1 root root  24 Aug 15 15:57 S01mountkernfs.sh -> ../init.d/mountkernfs.sh
lrwxrwxrwx 1 root root  14 Aug 15 15:58 S02udev -> ../init.d/udev
lrwxrwxrwx 1 root root  26 Aug 15 15:58 S03mountdevsubfs.sh -> ../init.d/mountdevsubfs.sh
lrwxrwxrwx 1 root root  18 Aug 15 15:58 S04bootlogd -> ../init.d/bootlogd
lrwxrwxrwx 1 root root  24 Aug 15 15:58 S05keyboard-setup -> ../init.d/keyboard-setup
lrwxrwxrwx 1 root root  16 Aug 15 17:29 S06hdparm -> ../init.d/hdparm
lrwxrwxrwx 1 root root  21 Aug 15 15:58 S06hostname.sh -> ../init.d/hostname.sh
lrwxrwxrwx 1 root root  25 Aug 15 19:49 S06hwclockfirst.sh -> ../init.d/hwclockfirst.sh
lrwxrwxrwx 1 root root  22 Aug 15 15:58 S07checkroot.sh -> ../init.d/checkroot.sh
lrwxrwxrwx 1 root root  20 Aug 15 19:49 S08hwclock.sh -> ../init.d/hwclock.sh
lrwxrwxrwx 1 root root  27 Aug 15 15:58 S08module-init-tools -> ../init.d/module-init-tools
lrwxrwxrwx 1 root root  17 Aug 15 15:58 S08mtab.sh -> ../init.d/mtab.sh
lrwxrwxrwx 1 root root  20 Aug 15 15:58 S09checkfs.sh -> ../init.d/checkfs.sh
lrwxrwxrwx 1 root root  21 Aug 15 15:58 S10mountall.sh -> ../init.d/mountall.sh
lrwxrwxrwx 1 root root  20 Aug 15 19:47 S10nfs-common -> ../init.d/nfs-common
lrwxrwxrwx 1 root root  31 Aug 15 15:58 S11mountall-bootclean.sh -> ../init.d/mountall-bootclean.sh
lrwxrwxrwx 1 root root  26 Aug 15 15:58 S12mountoverflowtmp -> ../init.d/mountoverflowtmp
lrwxrwxrwx 1 root root  24 Aug 29 23:29 S13ifupdown-clean -> ../init.d/ifupdown-clean
lrwxrwxrwx 1 root root  16 Aug 15 15:58 S13procps -> ../init.d/procps
lrwxrwxrwx 1 root root  19 Aug 15 15:58 S13udev-mtab -> ../init.d/udev-mtab
lrwxrwxrwx 1 root root  17 Aug 15 15:58 S13urandom -> ../init.d/urandom
lrwxrwxrwx 1 root root  20 Aug 15 17:26 S13x11-common -> ../init.d/x11-common
lrwxrwxrwx 1 root root  18 Aug 29 23:29 S14ifupdown -> ../init.d/ifupdown
lrwxrwxrwx 1 root root  20 Aug 15 20:30 S15networking -> ../init.d/networking
lrwxrwxrwx 1 root root  21 Aug 15 20:30 S16mountnfs.sh -> ../init.d/mountnfs.sh
lrwxrwxrwx 1 root root  17 Aug 15 20:30 S16portmap -> ../init.d/portmap
lrwxrwxrwx 1 root root  31 Aug 15 20:30 S17mountnfs-bootclean.sh -> ../init.d/mountnfs-bootclean.sh
lrwxrwxrwx 1 root root  13 Aug 15 20:30 S18kbd -> ../init.d/kbd
lrwxrwxrwx 1 root root  23 Aug 15 20:30 S19console-setup -> ../init.d/console-setup
lrwxrwxrwx 1 root root  20 Aug 15 20:30 S20alsa-utils -> ../init.d/alsa-utils
lrwxrwxrwx 1 root root  21 Aug 15 20:30 S20bootmisc.sh -> ../init.d/bootmisc.sh
lrwxrwxrwx 1 root root  14 Aug 15 20:30 S20fuse -> ../init.d/fuse
lrwxrwxrwx 1 root root  20 Aug 23 21:20 S20lm-sensors -> ../init.d/lm-sensors
lrwxrwxrwx 1 root root  30 Aug 15 20:30 S21stop-bootlogd-single -> ../init.d/stop-bootlogd-single

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.

bingmou 09-25-2011 12:26 AM

It is weird that udev reports that error message to me. It is supposed not to start alsa so early.

62chevy 09-25-2011 01:24 PM

Quote:

Originally Posted by bingmou (Post 4481516)
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

Code:

chevy@sid:~$ ls -l /dev/disk/by-uuid
total 0
lrwxrwxrwx 1 root root 10 Sep 22 13:59 306fa650-10f1-45ca-a092-4d04cc303113 -> ../../sda2
lrwxrwxrwx 1 root root 10 Sep 22 13:59 5de3ac62-e037-47fd-9bfb-5614d48d3bc6 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Sep 22 13:59 75e94858-4356-4dd8-89a3-cbe3c71c1d50 -> ../../sda3
lrwxrwxrwx 1 root root 10 Sep 22 13:59 ae9c975f-317f-4ee8-88d7-c99f409dddfa -> ../../sda1
chevy@sid:~$

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


bingmou 09-26-2011 12:17 AM

here is my /etc/fstab:
Quote:

# /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

# cdrom
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0

# Backup disk was on /dev/sda9
UUID=47506418-b2ec-4940-82a9-e5f9860b7c38 /media/Backup ext3 defaults 0 2

# Multimedia disk was on /dev/sda10
UUID=fe160451-cccf-45db-9e94-7d24ffba5b8a /media/Multimedia ext4 defaults 02
Here is the output of "ll /dev/disk/by-uuid/"
Quote:

lrwxrwxrwx 1 root root 10 9月 25 21:27 2404658904655EB4 -> ../../sdb1
lrwxrwxrwx 1 root root 10 9月 25 18:05 30e58188-9d66-4e00-b31e-c30336b66112 -> ../../sda7
lrwxrwxrwx 1 root root 10 9月 25 18:05 360C55360C54F27B -> ../../sda2
lrwxrwxrwx 1 root root 10 9月 25 21:27 3EB8C1DCB8C19337 -> ../../sdb3
lrwxrwxrwx 1 root root 11 9月 25 18:05 44ae0517-5d63-4d09-81e0-409e7126e5b0 -> ../../sda11
lrwxrwxrwx 1 root root 10 9月 25 18:05 47506418-b2ec-4940-82a9-e5f9860b7c38 -> ../../sda9
lrwxrwxrwx 1 root root 10 9月 25 18:05 5cec433e-3d6d-4ebf-a95e-0ae03b3a118a -> ../../sda8
lrwxrwxrwx 1 root root 10 9月 25 21:27 627b369b-6502-417b-997b-84070ee37f36 -> ../../sdb4
lrwxrwxrwx 1 root root 10 9月 25 18:05 62B64B33B64B06CF -> ../../sda1
lrwxrwxrwx 1 root root 10 9月 25 21:27 A448B6EF48B6BEFC -> ../../sdb2
lrwxrwxrwx 1 root root 10 9月 25 18:05 BCA6C1ACA6C1680A -> ../../sda5
lrwxrwxrwx 1 root root 10 9月 25 18:05 dfe740b0-c4ce-4388-bada-5b2e068467af -> ../../sda6
lrwxrwxrwx 1 root root 10 9月 25 18:05 E2E86073E860483D -> ../../sda4
lrwxrwxrwx 1 root root 11 9月 25 18:05 fe160451-cccf-45db-9e94-7d24ffba5b8a -> ../../sda10



Here is my /etc/modules:
Quote:

# /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.

firewire-sbp2
loop

62chevy 09-26-2011 06:26 PM

The only other thing you can do is look at /etc/rcS.d to see where alsa-utils is loaded, if it's before mountall.sh then that is your problem.

Do you have a default Debian install or have you modified it. (sysvinit vs systemd)

rknichols 09-26-2011 09:40 PM

You might also see if there any udev rules that would call alsactl way back up in the S02udev script.


All times are GMT -5. The time now is 01:25 AM.