Bruce Dubbs wrote: > I am wondering about making a change to LFS to combine some of the root > directories and /usr. Looking at the sizes on a fairly complete system: > > 22M /lib > 4.9M /bin > 7.6M /sbin > 1.4G /usr/lib > 300M /usr/bin > 15M /usr/sbin > > It seems like the space needed for /usr is really not that much.
Not in absolute terms, but in terms of the percentage of the system,
it's almost everything. :-)
> What I was thinking about doing was changing Section 6.5 - Creating
> Directories from
>
> mkdir -pv /{bin,boot,etc/{opt,sysconfig},home,lib,mnt,opt,run}
> mkdir -pv /{media/{floppy,cdrom},sbin,srv,var}
>
> to
>
> mkdir -pv /{boot,etc/{opt,sysconfig},home,mnt,opt,run}
> mkdir -pv /{media/{floppy,cdrom},srv,var}
>
> ... (create /usr hierarchy)
>
> ln -sv /usr/bin /bin
> ln -sv /usr/lib /lib
> ln -sv /usr/sbin /sbin
>
> case $(uname -m) in
> x86_64) ln -sv /usr/lib /lib64 && ln -sv lib /usr/lib64 ;;
> esac
>
> As far as I can tell, everything should work as before, but we can
> remove some of the things we do to move files and libraries from /usr to
> /.
Well, there's one case that it does hurt, I think, though that case may
not be widely used. That's an unencrypted rootfs, but an encrypted
(e.g.) /home, /usr, and /opt. That won't be possible anymore, without
an initramfs.
(An encrypted rootfs already isn't possible without an initramfs though,
so maybe we just force a few more people in that direction? Not sure if
that's a great idea, but it might work.)
This goes back to the fraction of the system that's encrypted in this
setup. Exposing just the rootfs doesn't seem like a huge deal to me
(though it depends on your risk analysis), but exposing all of /home
seems like a really bad idea, and /usr I'm split about evenly on.
(Of course, exposing /home isn't really relevant here.)
> The restriction, of course, is that /usr must be a part of the
> rootfs, but a recommended size for that could be 20G and not really
> affect anything.
Except the options allowed for the /usr FS. :-)
> While I'm at it, should we remove *.la files in the libraries:
>
> find /usr/lib -name \*.la -delete
As a person who sometimes writes code against libraries in LFS, I'd
rather not. But this might fall into the same category as removing
static libs, or stripping debug symbols.
> We can add that to Section 6.64 - Stripping Again. What I've found is
> that I get a lot of warning messages and sometimes failures when
> packages try to use the .la files, but just removing them seems to fix
> things up without causing other problems.
Hmm, I haven't noticed that. Is this from files that got moved, or from
something else? (.la files encode their original installation directory
in the file itself, in libdir, so if they get moved after installation,
the files need to be edited, otherwise libtool will complain. I don't
*think* that will cause failures to compile, though...)
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
