Date: Sun, 17 Nov 2002 14:59:00 -0800 From: Peter Wemm <peter@wemm.org> To: Lamont Granquist <lamont@scriptkiddie.org> Cc: hackers@FreeBSD.ORG Subject: Re: Shrinking /(s)bin: A Proposal Message-ID: <20021117225900.BD9742A7EA@canning.wemm.org> In-Reply-To: <20021116232006.N1254-100000@coredump.scriptkiddie.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Lamont Granquist wrote:
>
> RedHat systems have only two statically linked binaries in their systems
> and it is one of the things that I viscerally hate about RedHat. You have
> to look on another system or lookup on the net which shell to use instead
> of /sbin/init and then play around with a massively minimal set of things
> you can do to the filesystem in order to fix your system. I hate that.
> I particularly hate that because whenever it comes up I just did something
> stupid enough to nuke my libc and I'm not a happy camper. I want to just
> boot into single user and fix the system.
>
> Also, the lack of 'mv' being statically linked is what caused me to learn
> so much about how to recover from libc being nuked on RedHat boxes. Its
> good to have any common utilities people might think of to use to update
> libc to be statically linked.
>
> Of course I can see where on early-90s era systems, or on embedded
> systems, you'd want to go with the smallest /[s]bin you can get in which
> case the buildworld option makes perfect sense. I have no use for this
> option though. I'm happy to gleefully burn through the 20MB of disk
> space. 20MB of disk space is cheap these days -- 99% of FreeBSD users
> will never notice that it is gone...
Have you been actually reading this?
peter@daintree[2:55pm]/-101> cd /rescue
peter@daintree[2:55pm]/rescue-102> file rescue
rescue: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 5.0, statically linked, stripped
Note: Static linked.
peter@daintree[2:55pm]/rescue-103> file sh
sh: symbolic link to rescue
peter@daintree[2:55pm]/rescue-104> file cp
cp: symbolic link to rescue
peter@daintree[2:55pm]/rescue-105> file init
init: symbolic link to rescue
....
Adding things like mv etc to this is *trivial*.
If you get hosed, and have to drop into single user, we'll arrange it so
that $PATH has got /rescue at the beginning. Since adding things like mv
to the static linked crunched binary is trivial, you'd actually be seeing
an improvement over the bloat case.
> On Fri, 15 Nov 2002, Peter Wemm wrote:
> > Robert Watson wrote:
> > >
> > > On Thu, 14 Nov 2002, Doug Rabson wrote:
> > >
> > > > > : I'm open to patches for building /[s]bin as dynamic. If you have
> > > > > : time and can coordinate with lukem@netbsd.org to build the patch, I
> > > > > : would appreciate it.
> > > > >
> > > > > % make NOSHARED=NO buildworld
> > > > >
> > > > > No patches necessary. We do this all the time at work, and it works
> > > > > fabulously. I do this for disk based systems that have / and /usr on
> > > > > the same file system too.
> > > >
> > > > To do it right for split root/usr installations requires a few patches
> > > > though. The rtld and the libs required for /[s]bin need to move to / an
d
> > > > compat symlinks created from /usr. A suitable crunchgen'ed binary for
> > > > /recover would be useful too.
> > >
> > > I had some local patches that did a subset of this -- moved ld.so to /lib
,
> > > as well as installing shared libraries to /lib instead of /usr/lib for th
e
> > > base system. I seem to recall I also had to tweak some defaults in ld.so
> > > or rtld or the like, though. I agree that the right path to support full
y
> > > dynamic systems properly is to adopt the approach taken by NetBSD: provid
e
> > > a decent /recover with crunchgen, etc. I do use fully dynamic stuff for
> > > some local test boxes, makes upgrading libc code for development purposes
> > > much easier, as well as supporting dlsym() for /sbin, which is very usefu
l
> > > in my environment.
> >
> > For what its worth:
> >
> > peter@daintree[4:55pm]/rescue-222# ls
> > -sh@ dumpfs@ ipmon@ mount_portalfs@ rm@
> > [@ dumpon@ ipnat@ mount_std@ rmdir@
> > adjkerntz@ echo@ kenv@ mount_udf@ route@
> > atacontrol@ ed@ kill@ mount_umapfs@ routed@
> > badsect@ expr@ kldconfig@ mount_unionfs@ rtsol@
> > camcontrol@ fdisk@ kldload@ mv@ savecore@
> > cat@ fdisk_pc98@ kldstat@ natd@ setfacl@
> > ccdconfig@ fsck@ kldunload@ newfs@ sh@
> > chio@ fsck_ffs@ ldconfig@ newfs_msdos@ shutdown@
> > chmod@ fsck_msdosfs@ ln@ nfsiod@ slattach@
> > clri@ fsdb@ ls@ nos-tun@ sleep@
> > comcontrol@ fsirand@ mca@ pax@ spppcontrol
@
> > conscontrol@ gbde@ md5@ ping@ startslip@
> > cp@ getfacl@ mdconfig@ ping6@ stty@
> > date@ gpt@ mdmfs@ ps@ swapon@
> > dd@ growfs@ mkdir@ pwd@ sync@
> > devd@ hostname@ mknod@ quotacheck@ sysctl@
> > devfs@ ifconfig@ mount@ raidctl@ test@
> > df@ init@ mount_cd9660@ rcorder@ tunefs@
> > dhclient@ ip6fw@ mount_ext2fs@ rcp@ umount@
> > disklabel@ ipf@ mount_msdosfs@ realpath@
> > dmesg@ ipfs@ mount_nfs@ reboot@
> > domainname@ ipfstat@ mount_ntfs@ rescue*
> > dump@ ipfw@ mount_nullfs@ restore@
> > peter@daintree[4:55pm]/rescue-223# ls -l ./rescue
> > -rwxr-xr-x 1 root wheel 2725532 Nov 15 16:52 ./rescue*
> > peter@daintree[4:55pm]/rescue-224# ./sh
> > # ./ls -l ./rescue
> > -rwxr-xr-x 1 root wheel 2725532 Nov 15 16:52 ./rescue
> >
> > That's 2.7M to replace roughly 30M of /bin + /sbin.
> >
> > Warner quoted some numbers for a dynamic / case. I think we'd be looking
> > in the order of a few megs of shared libs, plus about 2MB for /bin+/sbin.
> >
> > ie: a reduction from ~30M to somewhere in the area of about 7MB, and that
> > includes the crunched static /rescue/*.
> >
> > This might actually fit on my SMP Pentium-90 box that was installed late
> > 1995. :-)
> >
> > I didn't spend much time on the crunch stuff, I was mostly curious to see
> > how it worked and what it could do. I was suprised at how easy it was
> > to produce a binary. I haven't polished it up and haven't done
> > any bmake glue.
> >
> > Cheers,
> > -Peter
> > --
> > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
> > "All of this is for nothing if we don't go to the stars" - JMS/B5
> >
> >
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-hackers" in the body of the message
> >
> >
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
>
Cheers,
-Peter
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021117225900.BD9742A7EA>