Dynamic Root Support For FreeBSD Now Available

Dan writes "FreeBSD's Gordon Tetlow has committed his enhancements to enable users to build /bin and /sbin dynamically linked on FreeBSD. His reason to do this is two-fold. One is to give better support for PAM and NSS in the base system. The second is to save some disk space. Currently (on his x86 box), /bin and /sbin are 32 MB. With a dynamically linked root (and some pruning of some binaries), the /bin, /lib, and /sbin come out to 6.1 MB. This should be great for people with 2.x and 3.x era root partitions that are only about 50 MB. Gordon says that there will be a performance hit associated with this. He did a quick measurement at boot and his boot time (from invocation of /etc/rc to the login prompt) went from 12 seconds with a static root to 15 seconds with a dynamic root."

Comments

bad bad bad

[Tirel]

not only will this affect performance, but it will also make it impossible to recover a server if you accidentally delete /usr,

there are less and less reasons to use seperate partitions for root directories, and this is *NOT GOOD*

Re:bad bad bad

[Fweeky]

Er, why? /bin, /sbin and /lib should all be on the same partition, and if you're really screwed, that's what /rescue is for.

Re:bad bad bad

[Nizzt]

Thats why the librarys are in /lib not /usr/lib

Re:bad bad bad

[cperciva]

it will also make it impossible to recover a server if you accidentally delete /usr

No. The libraries used by stuff in /bin and /sbin are being moved into /lib, so everything which is being changed from static to dynamic will still work even if /usr is gone.

Also note that /rescue is still static (and crunched).

Re:bad bad bad

[ctr2sprt]

It's not good as a default, but it's good as an option. So while I hope FreeBSD installs still come with a static bin+sbin, it's nice to have the option, on a make world, to change the behavior if I decide I need to. It's added flexibility without any added complexity. What more could you want?

Re:bad bad bad

[shlong]

" not only will this affect performance, but it will also make it impossible to recover a server if you accidentally delete /usr,"

What wasn't mentioned in the write-up is that /rescue contains statically-link versions of the tools that one would need to recover from problems. It might not be able to recover a deleted filesystem, but if you're trouncing careless around like that then there are plenty of other ways to shoot your feet off too.

good and bad here

[josepha48]

This is good in the case of people who want to run a system off a cdrom or floppy or flash memory. On a cdrom you don't need to worry about deleteing /usr cause it should be burned into the cdrom. Also any partitions that you need end up in ram / memory disks. /dev is a good example of a ram disk. By having a smaller /bin and /sbin one can suddenly have nice small routers / gateways using freebsd, instead of Linux.

I'd imagine that if NetBSD and OpenBSD don't already have this ability it will be a matter of time as the BSD's share much between each other. Just look at the realpath vulnerability that they all were affected by.

Re:good and bad here

[vesamies]

NetBSD is also using dynamic /bin, /sbin, not sure what OpenBSD is doing. This is not much of an ability since /usr/bin, /usr/sbin have always been dynamic, now everything is dynamic. Well, looks like everyone has all-dynamic system now, which is good.

Re:Linux distro's already do this.

[phoenix_rizzen]

"Because Linux does it" is not always a good reason to do something. Linux developers tend to throw anything and everything they can into the mix. BSD developers tend to watch what others do, research the pros/cons, then develop a plan on how to do it right ... before tackling the coding.

Hence, while Linux distros tend to get things first, BSD tends to get things right. :)

My understanding...

[devphil]

...was that, in earlier *nixes, sbin programs were always statically linked, to avoid problems with requiring /usr, or accidentally damaging the dynamic loader, or still functioning while restoring dynamic libs from tape, etc, etc.

Not necessarily FreeBSD, but just some flavor of Unix. The versions of Digital Unix (under different names) which I teethed on were designed like this.

It's always annoyed me that Linux's [/usr]/sbin was dynamically linked.

Re:25%

[JDizzy]

It really depends if your a pesimist, or an optimist. Yes 3 units of 12 is indeed 25%, and since it is 3 units over 12 to 15 it could be seen as an additional 25% extra time. The more correct way to look at it is from the point of view for the number 15. aka the boot was an entire 1/5 faster without dynamic bins.

Besides, there have also been improvements in caching libs in conjunction with linking so that dynamic bin's always load faster. It could also be possible to make certain /bin and /sbin stuff static, but thats what /rescue is for with the crunched bins. Besides, this will only lead to a more optimised ld program and linking system there after. Not having the entire bulk of libc repliated allover the place in /bin and /sbin is entirly acceptible to me. Architecturally speaking that is a big faux pax to leave such a clutter. This is why elf was devised in the first place, and slow to implement Operating Environments is partly to blame for the hindering of cool features like dynamic linking tricks such as thosed used in pam and nss. This is, after all, the reason we have libraries.

Re:Linux distro's already do this.

[Arandir]

Hence, while Linux distros tend to get things first, BSD tends to get things right.

Actually, BSD gets a lot things first. First to have a commercial support, first to have a free and complete operating system, and first to get sued by obnoxious companies :-). More recently, first to implement IP6, Serial ATA, Hyperthreading, etc. I would have to check, but I think they got USB and Firewire first as well.