From owner-freebsd-hackers Sun Nov 17 14:59: 5 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37D6337B401 for ; Sun, 17 Nov 2002 14:59:01 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id D281F43E42 for ; Sun, 17 Nov 2002 14:59:00 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id BD9742A7EA; Sun, 17 Nov 2002 14:59:00 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Lamont Granquist Cc: hackers@FreeBSD.ORG Subject: Re: Shrinking /(s)bin: A Proposal In-Reply-To: <20021116232006.N1254-100000@coredump.scriptkiddie.org> Date: Sun, 17 Nov 2002 14:59:00 -0800 From: Peter Wemm Message-Id: <20021117225900.BD9742A7EA@canning.wemm.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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