Igor Pashev <pashev.i...@gmail.com> writes:
> 07.12.2011 04:43, Marco d'Itri пиÑеÑ:
>> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=12a362be5c1982f80dbfb75bda070208a2c99cdf
>>
>> Discuss.
>>
>
> I don't see any reason to move all into /usr from /,
> and make initrd for minimal system:
>
> Making self-contained initrd is the same problem
> as making self-contained /
>
> So why overhead?
One problem for a "minimal" / is that there are so many different setups
there, even more for Debian than for RH, and minimal has so many
different meanings. Because of that more and more stuff has ended up in
/ over the years and it isn't quite so minimal anymore.
The initramfs on the other hand is made to fit. So if /usr isn't on a
networking filesystem (NFS) then you won't get networking stuff in the
initramfs. No raid then mdadm isn't included. No lvm and the initramfs
gets smaller again. And only select modules for one kernel are in
there. Huge space saving again. So an initramfs will/can be minimal.
The initramfs only needs to be self-contained for exactly one use
case. The one where it is building on. The / needs to be self contained
for every crazy setup any Debian user can think of. And initramfs is
configurable by the admin. If something is missing he can add
it. Properly fixing a not self-contained / on the other hand is
difficult.
So I don't agree that making a self-contained / is the same problem as
making a self-contained initramfs.
On the other hand initialy making initramfs support all the crazy things
people do with /usr will be fun.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ty5b4d0r.fsf@frosties.localnet
