Autor: Adam Borowski Fecha: A: dng Asunto: Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make
them unbootable
On Sun, Nov 12, 2017 at 09:36:17PM +0100, Joerg Reisenweber wrote: > On Sun 12 November 2017 19:45:02 Adam Borowski wrote:
> > On Sun, Nov 12, 2017 at 12:14:33PM +0100, Joerg Reisenweber wrote:
> > > The "too much work" argument is a very embarrassing one - it's the genuine
> > > duty of distro maintainers to take care of exactly such stuff. The
> > > argument
> > > that something was "too much work" (for the distro maintainers, or even
> > > the
> > > developers) is moot unless you're doing all that for yourself or for
> > > developers instead of your users.
> > > Claiming that a decision whether to put a package into /bin or /usr/bin
> > > (resp *sbin*) was "too much work" is also outright silly, there's zero
> > > additional workload in placing the package into the right location,
> > > except for the needed knowhow and decision itself. It's just for the
> > > laziness of developers of boot/init process when they demand to
> > > indiscriminately have access to *all* existing binaries in /usr
> >
> > The work involved is not just "zero", it's _massive_. Have you looked at
> > how extensive dependency chains can be for complex setups? Try mounting a
> > filesystem over wifi that requires a fancy authentication daemon.
>
> Sorry, I think when you take up on the task to develop and maintain an init
> system,
And what exactly developing an init system (which is unrelated to making a
distribution) has to do with this?
> and you want to mount a filesystem via WiFi (what a weird idea)
What's wrong with this?
> *before* you mounted /usr/
Most large companies use a non-trivial method of authentication, sometimes
downright bizarre.
>, and then you claim that's *too much work* aka too
> complicated for *you* to accomplish this the right way and thus you need all
> /usr/ in root, then really so sorry to tell you I think you're simply not up
> to the task at hand
Have you _tried_ doing so? Or even listened to anyone who did?
Supporting every use case -- even just use cases widespread in the wild --
is a massive task. That your machine at home is content with a particular
setup doesn't make it worthwhile to provide a separate scheme just to cater
for that special snowflake. A generic, powerful and low-effort scheme
exists (initrd) thus doing it the hard way is a waste of time. What's most
important, not _your_ time.
> Anyway thanks for proving my point that it's just about laziness (or - now I
> have to add - maybe mere incompetence) of the systemd cabal and freedesktop
> folks and other proponents of /usr( in rootfs.
And what exactly systemd has to do with this? Newsflash: Debian does _not_
run systemd inside initrd.
> > Every
> > involved package, and every library recursively depended upon by one of
> > those packages, would need to be moved to /{bin,sbin,lib}/.
> >
> > Debian, with its north of 1000 developers, decided that, despite trying,
> > it's a lost cause. Do you think Devuan with 5 can do better?
>
> Yes, since those 5 understand that the other 995+ don't give a damn about
> where /usr/ lives since their apps get started *after* init and mount of
> filesystems
It's way more than 5 people whose packages get run before remote (and even
local) filesystems get mounted. And those people are tired with jumping
through hoops for no benefit.
> > And if all you want is merely separate /usr, the whole extra cost is
> > installing "tiny-initramfs" which includes a trivial initrd whose features
> > (and complexity) are limited to:
> > * CPU microcode
> > * /usr
> > * root=UUID
> > * root on nfs in some configurations
> > * _very_ minimal module loading, with no real automation. This is usually
> > inadequate for distribution kernels, you need to recompile your kernel
> > with required pieces statically.
> >
> > At least microcode is mandatory on any modern x86 CPUs,
> >
> ...since this is *obviously* completely unrelated to mounting /usr/
> Why don't systemd and "friends" mount /usr/ via such minimal ramdisk?
initrd acts _before_ the filesystem /bin/init is on is even mounted.
It is possible to run a separate copy of systemd inside initrd, Red Hat
does so.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U.
⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift
⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters
⠈⠳⣄⠀⠀⠀⠀ relevant to duties], shall be punished by death by shooting.