On 01/06/2016 10:40 AM, Simon McVittie wrote:
On 05/01/16 15:55, Ian Jackson wrote:
Abolishing the distinction between /usr and /
"Merged /usr" is not about removing the distinction between /usr and /,
it's about removing the distinction between subdirectories of /usr and
the corresponding subdirectories of the root, namely /{bin,sbin,lib*}.
"lib*" means lib and lib64 in our case, and maybe lib32 (I forget
whether we have any architectures where that exists). On distributions
that have it, libexec is also in-scope for "merged /usr", but Debian
doesn't have libexec anyway.
I beg do disagree : so far / is almost selfcontained and can be
realisticly used without /usr being mounted. (you even stated this in
your mail after) Booting on / with a non clean/not automagically
repairable /usr works, you do not need to insert a bootable support to
fix things. Putting symbolic link pointing for libraries or binaries to
/usr just breaks that (initrd or not) and it is also said to be broken
in general for people not using initrd...
And yes it does make / growth a lot especially because of systemd
needing a lot libraries or /usr being mounted really early enough. And
you pointed why mounting /usr indeed may require a lot of stuff for
networked mount...
besides the / and /usr merged, I think that a proper/preferred
partitioning scheme has not yet been enough discussed and that the
proposal, while trying to help fixing """"broken""" partitioning scheme
is only one solution to the real problem : what should be available
(partition, file system hierarchy) and in what form (ro:rw, ...) when
init starts.
For sure there is not something as one for all situation solution, but
if we find realistic solutions for people using custom/self generated
kernel or no initrd, or systemd, sysvinit (put your preferred init
system here) or networked file systems and at least document them or
(dreaming a bit) implement the partitioning scheme in installer that
would be good.
I personally think those factors undermine the "/ as recovery" use-case
Probably a install kernel + dedicated recovery initramfs is indeed a
better solution and could be installed by regular installer and updated
via package upgrade (a bit like metest86+ package does). I think most
people complain because :
1) the amount of things that should be present to have a system
reparable/bootable is just going beyond normal especially for
embedded/non PC case,
2) they are told that their system is likely to stop functioning at
some point in time and nobody will fix it because the installation is
going to be flaged as "non standard" no more supported.
And yes the tool proposed does help fixing some cases but not all.
Maybe a an automatic repartitioning tool (iso/usb image) that could use
some extra disk storage to store / + /usr before providing a repartioned
system disk could also be useful for users even if I agree it is
impossible to resolve all partition migration cases especially with old
bios partitioning sheme and their primary/secondary partitions but for
gpt partitionned devices, this should be simpler...
If only fixing the BL remains ...
-- eric
