From Newsgroup: alt.os.linux
On 2025-06-06 13:45, Lew Pitcher wrote:
On Fri, 06 Jun 2025 12:25:35 +0100, Java Jive wrote:
[snip]
I now have this fully working. If it's of any interest here's the code
from rcS. If on first boot, less than 2 HDs are found, it's sets a flag
in the U-boot environment, which survives a reboot, and then does a
reboot. On the second boot, it wipes the reboot flag and carries on the
boot regardless of how many HDs are found. In my case, the reboot
allows the second HD to be detected during the second boot, so the XFS
storage area spread across both HDs becomes available.
[snip]
${SETENV} ${REBOOTFLG} true
${ECHO} "Rebooting to try to pick up slow-spin-up drives ..."
# The following command is valid according to the help parameter, but fails >> # ${UMOUNT} -a
Yah, assuming ${UMOUNT} resolves to something like /bin/umount, then
${UMOUNT} -a
probably would fail here. Primarily while trying to umount the filesystem that has your scripts cwd, and (because the umount failure left that filesystem still mounted) the root filesystem.
Remember, umount can't unmount an active mountpoint (one with mountspoints, open files or directories on it), and
a) your script's cwd is most likely located in one of the filesystems
mentioned in /etc/mtab (and, of course, open, because your active
process lives in that cwd),
b) / is probably in your /etc/mtab, and can't be umounted until all
the filesystems that reside on it are umounted, and
c) your use of the -a option effectively asks umount to unmount /all/
filesystems listed in /etc/mtab ("except the proc filesystem")
Thanks for the explanation, which has led me to look back into PuTTY's
log files investigating further. I think your explanation probably does
fit my current situation, because I've now reinstated the command, and
this is the result as of now ...
BusyBox v1.17.2 (2017-09-14 21:33:20 BST) multi-call binary.
Usage: umount [OPTIONS] FILESYSTEM|DIRECTORY
umount: can't umount /proc: Device or resource busy
... which originally confused me because seeing an abbreviated
explanation of the usage and not noticing the last line led me to
believe that the '-a' parameter had not been accepted. However, I have another log file of apparently the same command used in the same
situation that contains only the last line above, which is a much more reasonable message. In both cases, the system does still reboot.
However, there are other places in the boot scripts, particularly
Zyxel's original scripts, where 'umount -a' appears to fail completely
and just displays the help, here's an example of that ...
Usage: umount [-hV]
umount -a [-f] [-r] [-n] [-v] [-t vfstypes] [-O opts]
umount [-f] [-r] [-n] [-v] special | node...
... so I'm not really sure what is going on in that case, perhaps an
invisible character such as a non-breaking space has found its way into
the script. Generally, the command's output is somewhat confusing and
seems to have been rather poorly written, at least in the cut-down
BusyBox version used on this NAS box.
--
Fake news kills!
I may be contacted via the contact address given on my website: www.macfh.co.uk
--- Synchronet 3.21a-Linux NewsLink 1.2