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... 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 [EMAIL PROTECTED] 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 / and > > > 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 the > > 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 fully > > dynamic systems properly is to adopt the approach taken by NetBSD: provide > > 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 useful > > 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 - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > "All of this is for nothing if we don't go to the stars" - JMS/B5 > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
