Perhaps another way to handle /usr on its own partition/logical volume.

Richard Cranium · 08-21-2016, 06:10 PM

I'll admit that having /usr on another partition is swimming against the stream.

For the rest of you salmon out there, here's what I've changed in the initrd's init script as well as in /etc/rc.d/rc.S. It appears to work for me, but I haven't triggered all the edge cases.

Here's the portion of /boot/initrd-tree/init that I've changed (actual change in bold)...

Code:

  # Switch to real root partition:
  /sbin/udevadm settle --timeout=10
  echo 0x0100 > /proc/sys/kernel/real-root-dev
  mount -o ro -t $ROOTFS $ROOTDEV /mnt
  
  if [ ! -r /mnt/sbin/init ]; then
    echo "ERROR:  No /sbin/init found on rootdev (or not mounted).  Trouble ahead."
    echo "        You can try to fix it. Type 'exit' when things are done." 
    echo
    /bin/sh
  else
      # see if fstab has a /usr entry; if so, attempt to mount it.
      USRLINE=$( /bin/grep -E "^/[^[:space:]]+\s+/usr\s+.*" /mnt/etc/fstab )
      if [ "${USRLINE}" ]; then
	  read USRDEV USRMP USRFS DK1 DK2 DK3<<EOF
${USRLINE}
EOF
	  mount -o ro -t ${USRFS} ${USRDEV} /mnt/usr
      fi
  fi
else
  echo
  echo "RESCUE mode"
  echo
  echo "        You can try to fix or rescue your system now. If you want"
  echo "        to boot into your fixed system, mount your root filesystem"
  echo "        read-only under /mnt:"
  echo
  echo "            # mount -o ro -t filesystem root_device /mnt"
  echo
  echo "        Type 'exit' when things are done."
  echo
  /bin/sh
fi

Here's the portion that I've changed in /etc/rc.d/rc.S...

Code:

  USRLINE=$( /bin/grep -E "^/[^[:space:]]+\s+/usr\s+.*" /etc/fstab )
  if [ "${USRLINE}" ]; then
    echo "Unmounting /usr partition prior to root remount"
    /sbin/umount -l /usr
  fi
  # Remount the root filesystem in read-write mode
  echo "Remounting root device with read-write enabled."
  /sbin/mount -w -v -n -o remount /

So far, this has worked well. Some of the odd udev related errors that used to show up no longer do so. YMMV.

rkelsen · 08-21-2016, 10:23 PM

Quote:

Originally Posted by Richard Cranium

I'll admit that having /usr on another partition is swimming against the stream.

I don't think so... In the old days, even certain subdirs of /usr would (have to!) be on their own partitions...

Quote:

Originally Posted by linked article

"Fedora (and other distributions) have finished work on getting rid of the separation of /bin and /usr/bin, as well as /sbin and /usr/sbin, /lib and /usr/lib, and /lib64 and /usr/lib64. All files from the directories in / will be merged into their respective counterparts in /usr, and symlinks for the old directories will be created instead"

From what I can see, this is not true of Slackware (yet!), and hopefully is not in any future plans...

Quote:

Originally Posted by Richard Cranium

For the rest of you salmon out there, here's what I've changed in the initrd's init script as well as in /etc/rc.d/rc.S.

Why is this necessary? Adding an entry to /etc/fstab should be the end of it. It's no different to having /home or /var on a separate partition. You can even have the installer set it up that way.

Richard Cranium · 08-21-2016, 11:41 PM

Unlike you, I have seen error messages due to udev hooks attempting to run that use stuff in /usr.

That's not meant as a dig, by the way; I didn't see it as a problem either, until I noticed the startup error messages myself as well as the cgroup initialization bug that showed up for me due to a separate /usr mount. The latter has a work-around that Pat merged into the code, but I suspect that these issues will only get worse in time, since a lot of the upstream code assumes that /usr is present as soon as /.

tronayne · 08-22-2016, 01:58 PM

I keep all my systems identical.

Irrespective of drive size, I have 10 partitions with the same names (but not sizes) on all systems: /root, /home, /usr/local, /opt, /var/lib/mysql, /var/lib/pgsql, /var/lib/virtual and /spares.

On the two systems that are headless data base servers there may or may not be a second drive and, on my main work system, there is a second drive used for backing up the whole network (of four servers). Everybody has a zero back up plus daily changes (using cpio) so a failure can be rebuilt by loading the zero then day-by-day archives of changes.

VirtualBox is only installed on my main work system, the other have the partition but not the size (it's about 5G or so).

When I get a new system, I wipe it clean of Windows then install Slackware declaring and formatting the partitions (they're almost always 20G each although that may vary depending upon need).

Thereafter, when I get a new release of Slackware I install and format the root partition but only add the others to fstab without formatting (I hate copying hundreds of gigabytes all over the place).

I get away with that because Slackware installs completely (with install all) in about 8G, nothing goes into anywhere else.

I make heavy use of /opt. It will things like GMT, all the GMT world data files, all the optional world place names and other data. It has Moneydance (my favorite financial program) and its data base (which just keeps on growing). It has VirutalBox software. It has dspace and all its data. It has Grass and all its data. It has OpenOffice or LibreOffice (both of which only link to one place: /usr/bin/soffice).

I will not install optional software in the root tree although I find it almost impossible to install SlackBuilds into my preferred location, /usr/local, so I have SBos cluttering up the root tree.

I came from Unix long before I came to Linux and I try to follow the AT&T SVR4 model for where to put things (thus all the optional software in, glory be, /opt and locally generated software in /usr/local). Who'd-a-thunk-it.

As to putting the "bin" directories in their own partition, that used to be what you did (talking about a 50M drive holding SVR4 here), you made partitions the size of back up media, like, say, DC-600 tape cartridges. Worked pretty well too. Didn't have gigabyte stuff then or you had one or more additional hard drives to hold everything. Them boys down to Bell Labs knew how to get things small and efficient.

So, I can't see that partitioning the bins would present much, if any, problem as long as the setup doesn't use anything from them. Once everything is mounted and the copying starts all the software gets written to whatever partition is declared and mounted for it seems like. When you run setup, you're running from the operating system in memory, loaded before anything else when you boot from the release media.

Maybe I've missed something basic here (and I'm going to see if I can do a complete install with the bins in separate partitions on a spare drive I've got laying around and see what happens).

Hope this helps some.

Richard Cranium · 08-25-2016, 07:23 PM

Well, I have been seeing errors such as these in dmesg on startup...

Code:

[   30.637006] forcedeth 0000:00:0a.0 eth125: renamed from eth1
[   30.641710] udevd[1268]: failed to execute '/usr/sbin/obex-check-device' '/usr/sbin/obex-check-device 1d6b 0001': No such file or directory
[   30.646070] udevd[1269]: failed to execute '/usr/sbin/obex-check-device' '/usr/sbin/obex-check-device 1d6b 0001': No such file or directory
[   30.679988] udevd[1270]: failed to execute '/usr/sbin/obex-check-device' '/usr/sbin/obex-check-device 046d c317': No such file or directory

...

[   30.798338] forcedeth 0000:00:0a.0 eth0: renamed from eth125
[   30.809539] udevd[1274]: failed to execute '/usr/bin/xcmddc' '/usr/bin/xcmddc --i2c /dev/i2c-0 --identify': No such file or directory

rkelsen · 08-25-2016, 07:41 PM

There's an easy way to fix that.

Boot off a live CD/DVD or into a parallel installation, and temporarily mount the partitions you use for / and /usr.

Make a directory called /usr/bin and another one called /usr/sbin on the mounted / partition and copy the "missing" files from the mounted /usr partition to those locations.

Reboot and see if it still complains. If it does, then do the same for whatever else it complains about.

It is rather silly of udev to make this assumption.

Richard Cranium · 08-25-2016, 07:54 PM

I don't think that would work too well.

Code:

root@toshiba:~# ldd /usr/sbin/obex-check-device 
	linux-vdso.so.1 (0x00007ffcf7343000)
	libopenobex.so.2 => /usr/lib64/libopenobex.so.2 (0x00007ffbc724d000)
	libc.so.6 => /lib64/libc.so.6 (0x00007ffbc6e84000)
	libusb-1.0.so.0 => /usr/lib64/libusb-1.0.so.0 (0x00007ffbc6c6b000)
	/lib64/ld-linux-x86-64.so.2 (0x0000559487870000)
	libudev.so.1 => /lib64/libudev.so.1 (0x00007ffbc6a46000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ffbc6829000)
root@toshiba:~# ldd /usr/bin/xcmddc
	linux-vdso.so.1 (0x00007ffec0d29000)
	libXcm.so.0 => /usr/lib64/libXcm.so.0 (0x00007fc7a217b000)
	libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00007fc7a1f75000)
	libXmu.so.6 => /usr/lib64/libXmu.so.6 (0x00007fc7a1d5a000)
	libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007fc7a1b48000)
	libXt.so.6 => /usr/lib64/libXt.so.6 (0x00007fc7a18e2000)
	libSM.so.6 => /usr/lib64/libSM.so.6 (0x00007fc7a16da000)
	libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fc7a14d6000)
	libICE.so.6 => /usr/lib64/libICE.so.6 (0x00007fc7a12bb000)
	libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007fc7a0f7d000)
	libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007fc7a0d5e000)
	libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007fc7a0b5b000)
	libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007fc7a0955000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fc7a0751000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fc7a0448000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fc7a007e000)
	/lib64/ld-linux-x86-64.so.2 (0x000055e61185e000)

rkelsen · 08-25-2016, 09:14 PM

So copy the libraries too... You've already got the list of requirements!

- Or -

Statically compile the binaries, and then put them in there.

suppy · 08-26-2016, 05:20 AM

That sounds like a horrible idea ... next time any of those things get updated, he'll need to manually redo these things, or he'll get version mismatches and eventually failures.

It's not maintainable. The changes to the initrd and the rc.S sounds like a much better solution.

rkelsen · 08-26-2016, 08:33 AM

^ Not if they're statically compiled (the second part of the answer)

bassmadrigal · 08-26-2016, 08:50 AM

Quote:

Originally Posted by rkelsen

^ Not if they're statically compiled (the second part of the answer)

But that means he'd need to recompile them statically every time there's an update pushed, or end up with mismatched, possibly buggy, versions.

This does not seem like a reasonable alternative to his modifications to rc.S and his initrd. It's a lot of extra work for, what I can see, no benefit.

suppy · 08-26-2016, 09:51 AM

@rkelsen, I specifically used the generic phrase "redo these things" to encompass both your alternatives. My answer is equally accurate for either option.

yars · 08-26-2016, 11:20 AM

Modification of the rc.* scripts does not required, but as mentioned above, you need to recompile the packages that is used at boot-time. Static linking is not a strong requirement, but it so if these packages doesn't have the dependencies that lives in /usr. In my case, these packages is xcm, ConsoleKit2, virtualbox-kernel and openobex. I rebuilded these packages to move its used at boot-time parts to right places on /.
P.S. http://www.linuxquestions.org/questi...ts-4175559594/

I maintain a set of patches for mentioned above packages for myself.

rkelsen · 08-26-2016, 08:52 PM

Quote:

Originally Posted by yars

Modification of the rc.* scripts does not required, but as mentioned above, you need to recompile the packages that is used at boot-time.

This is probably the neatest solution of all mentioned here.

The question becomes: Why does udev assume that /usr is available at boot?

Richard Cranium · 08-26-2016, 10:09 PM

If you had followed the link that I provided at the very beginning of thread, you would know the answer to that question.

EDIT: I don't agree that /usr should be considered as available in the early stages of boot. I don't agree with a lot of things that I find myself having to endure. Hence my "swimming upstream" comment.