XPost: uk.comp.os.linux   
   From: java@evij.com.invalid   
      
   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   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)