mount(8) in /stand?

Giorgos Keramidas keramida at ceid.upatras.gr
Fri Feb 6 21:26:40 PST 2009


On Sat, 07 Feb 2009 03:16:46 +0100, Ivan Voras <ivoras at freebsd.org> wrote:
> Judging by Google's results I'm only one of many people frustrated by the
> lack of mount(8) in the "emergency holographic shell". My problem is that
> I have everything I need to install the system (on a "netbook" laptop -
> no CD reader) on the USB drive I booted from, but no way to get to the
> data (the network drivers need to be patched before they can be used so
> net install is out, sysinstall doesn't recognize the directory structure,
> has no way of mounting msdosfs, etc.). I see the mount executable is ~~
> 17 kB:
>
> -r-xr-xr-x  1 root  wheel  17232 Dec 29 15:29 /sbin/mount*
>
> This is about the third time I needed it in similar circumstances so is
> probably not unreasonable to request it be crunched in for the future?
> It's certainly one of the basic emergency utilities.

You have to account for the size of several mount_xxx executables too.
My userland is now installed with DEBUG_FLAGS='-g' so the sizes are not as
large as they seem below, but we need at least *some* of these to be in
`/stand' before `/stand/mount' is usable e.g. for cd9660 mounts:

% keramida at kobe:/sbin$ ls -ld mount*
% -r-xr-xr-x  1 root  wheel  - 47382 Feb  6 23:33 mount
% -r-xr-xr-x  1 root  wheel  - 23848 Feb  6 23:33 mount_cd9660
% -r-xr-xr-x  2 root  wheel  - 31741 Feb  6 23:33 mount_mfs
% -r-xr-xr-x  1 root  wheel  - 27946 Feb  6 23:33 mount_msdosfs
% -r-xr-xr-x  2 root  wheel  - 60590 Feb  6 23:33 mount_nfs
% -r-xr-xr-x  2 root  wheel  - 60590 Feb  6 23:33 mount_nfs4
% -r-xr-xr-x  1 root  wheel  - 27835 Feb  6 23:33 mount_ntfs
% -r-xr-xr-x  1 root  wheel  - 19567 Feb  6 23:33 mount_nullfs
% -r-xr-xr-x  1 root  wheel  - 20836 Feb  6 23:33 mount_udf
% -r-xr-xr-x  1 root  wheel  - 21853 Feb  6 23:33 mount_unionfs
% keramida at kobe:/sbin$ 

Then, there's the obstacle of mount_nfs{,4} and all the symbols they will
pull into the crunched binary.  This may actually increase the disk space
requirements of /stand a fair bit.

With disks becoming cheaper every day, it may be sensible to include
mount_xxx binaries in the default `/stand' for most of the installations,
but provide WITHOUT_MOUNT_XXX knobs to allow striping of the parts that
risk bloating /stand too much for smaller, embedded installations of BSD.



More information about the freebsd-arch mailing list