Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Adam Borowski]

On Wed, Nov 15, 2017 at 12:56:31PM -0800, Rick Moen wrote:
> Quoting Adam Borowski (kilob...@angband.pl):
> 
> > Because of lack of Unicode, those terminals couldn't do it right.  But
> > that's no more: here's a kernel patch set which makes the tty line
> > discipline handle the Great Runes correctly:
> > https://github.com/kilobyte/linux/commits/runes
> > 
> > "stty olcuc" to enable.
> 
> That's very droll, Adam.  Thank you for that.
> 
> I'm really curious, though:  Is there a real 2017 use-case for 'output
> lower case as upper case', of did you code this bit of brilliance just
> for the lulz?  (I've learned the hard way that what looks like something
> coded on a lark sometimes is serious.)

I was merely mocking Linux implementing olcuc in 1991, when it was already
grossly ridiculous and long since removed from all relevant standards.  I
guess Linus took a manpage and blindly implemented everything without
stopping to think if it makes any sense, when he coded the tty layer in
v0.01.

So with this patch it at least has _some_ use, if you want to train yourself
to read runes.  Otherwise, it's probably time to make it a no-op (still
present in uapi headers to not break compilation of programs that nominally
support it).


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.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Rick Moen]

Quoting Adam Borowski (kilob...@angband.pl):

> Because of lack of Unicode, those terminals couldn't do it right.  But
> that's no more: here's a kernel patch set which makes the tty line
> discipline handle the Great Runes correctly:
> https://github.com/kilobyte/linux/commits/runes
> 
> "stty olcuc" to enable.

That's very droll, Adam.  Thank you for that.

I'm really curious, though:  Is there a real 2017 use-case for 'output
lower case as upper case', of did you code this bit of brilliance just
for the lulz?  (I've learned the hard way that what looks like something
coded on a lark sometimes is serious.)


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Adam Borowski]

On Wed, Nov 15, 2017 at 06:12:03AM +0100, Alessandro Selli wrote:
>   AFAIR Dennis Ritchie lamented the spread of the capitalized form UNIX, he
> insisted it was never meant to be that way and that at AT/Bell Labs they
> always wrote Unix.  But, alas! all capital lettering was ubiquitous back
> then, at least in several systems/terminals, and the custom stuck.  IIRC
> only this year the US Navy gave up the requirement that its communications
> must always be trasmitted using all capitals.

Because of lack of Unicode, those terminals couldn't do it right.  But
that's no more: here's a kernel patch set which makes the tty line
discipline handle the Great Runes correctly:
https://github.com/kilobyte/linux/commits/runes

"stty olcuc" to enable.

-- 
⢀⣴⠾⠻⢶⣦⠀ 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.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Alessandro Selli]

On Wed, 15 Nov 2017 at 06:12:03 +0100
Alessandro Selli  wrote:

> On Tue, 14 Nov at 2017 15:35:08 -0800
> Rick Moen  wrote:
>
>> [1] The grammarian in me keeps insisting it shouldn't have been 'UNIX',
>> not being an acronym.  
>
>   AFAIR Dennis Ritchie lamented the spread of the capitalized form UNIX, he
> insisted it was never meant to be that way and that at AT/Bell Labs they
> always wrote Unix.  But, alas! all capital lettering was ubiquitous back
> then, at least in several systems/terminals, and the custom stuck.  IIRC
> only this year the US Navy gave up the requirement that its communications
> must always be trasmitted using all capitals.

  Now that I think of it, the spread of the Unix license plate must have
contributed to the spread of the bad habit:

http://www.unix.org/license-plate.html

At unix.com they seem to prefer the all capital form of the name.  :-/


Alessandro

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Alessandro Selli]

On Tue, 14 Nov at 2017 15:35:08 -0800
Rick Moen  wrote:

> [1] The grammarian in me keeps insisting it shouldn't have been 'UNIX',
> not being an acronym.

  AFAIR Dennis Ritchie lamented the spread of the capitalized form UNIX, he
insisted it was never meant to be that way and that at AT/Bell Labs they
always wrote Unix.  But, alas! all capital lettering was ubiquitous back
then, at least in several systems/terminals, and the custom stuck.  IIRC
only this year the US Navy gave up the requirement that its communications
must always be trasmitted using all capitals.


Alessandro
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Rick Moen]

Quoting Joerg Reisenweber (reisenwe...@web.de):

> On Mon 13 November 2017 15:46:30 John Hughes wrote:
> > systemd didn't exist in 1991 when USL decided that for SVR4.2 /bin, /lib 
> > and /sbin should just be symlinks to /usr.
> 
> And when did USL (whoever that is) decide that SVR4.2 doesn't care
> about being able to run on any ARM SoC? And how's that relevant for
> Linux?

John's dredging out ancient pre-Linux stuff, so presumably he's a
greybeard like yr. humble servant (or at least channeling one).

The funny thing was, back then in the 80s, we of the Unix[1] community
became accustomed to mostly ignoring what AT / Bell Labs / Unix System
Laboratories considered important even if we were running their code.
I was switching back and forth between BSD implementations and SYSV r.
3.x and 4.x implementations.  The latter included actual AT Unix SYSV
r. 3.21 and then (in the early '90s) briefly Novell Unixware 2.0.  The
AT product was one I picked up from a remainder merchandiser for US
$50 including a full bookshelf full of bound manuals, justifying my $50,
which is more than I can say for the OS, which was abysmal compared to
CSRG's BSD.

By the time I'd switched primarily to 386BSD 0.1 in '92 (just before
jumping to Linux), if you'd told me USL, pursuant to its rather
non-compelling attempt to merge SunOS and System V to produce SYSV4, was
now opining that /bin, /lib, and /sbin should just be symlinks to /usr
(on SVR4.2 or on anything else), I'd have just laughed.

But, and my apologies to the listadmins, none of this has much to do
with Devuan.


[1] The grammarian in me keeps insisting it shouldn't have been 'UNIX',
not being an acronym.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Steve Litt]

On Tue, 14 Nov 2017 15:05:35 -0500
Hendrik Boom  wrote:

> On Tue, Nov 14, 2017 at 03:07:09PM +0100, John Hughes wrote:
> > On 14/11/17 12:53, Rowland Penny wrote:  
> > >On Tue, 14 Nov 2017 12:40:02 +0100
> > >John Hughes  wrote:
> > >  
> > >>Why do you keep claiming the /usr problem is something to do with
> > >>systemd?  

[snip systemd apologism from the troll]

> 
> But we're talking about Linux here, where it wasn't a big problem.
> 
> -- hendrik

DON'TFEEDTHETROLL
 
SteveT

Steve Litt 
November 2017 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Alessandro Selli]

On Tue, 14 Nov 2017 at 13:35:13 +0100
Joerg Reisenweber  wrote:

> Obviously a systemd | usr_on_/ 
> system would not fit onto that tiny NAND, while a 'classical orthodox'
> system is supposed to work just fine *without* /usr/ at least in a
> singleuser mode which may well be all you want for your tiny embedded
> system like they are more and more popular and all but obsolete relics like
> you claimed.

  Did I hear IoT echoing somewhere?


Alessandro

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Hendrik Boom]

On Tue, Nov 14, 2017 at 03:07:09PM +0100, John Hughes wrote:
> On 14/11/17 12:53, Rowland Penny wrote:
> >On Tue, 14 Nov 2017 12:40:02 +0100
> >John Hughes  wrote:
> >
> >>Why do you keep claiming the /usr problem is something to do with
> >>systemd?
> >Probably because it does, it wasn't really a problem until systemd came
> >along and couldn't seem to fix it.
> >
> 
> systemd has no problem with /usr being on a different filesystem *if the
> filesystem is mounted before systemd starts*.
> 
> Making sure /usr was mounted before It was needed *was* really a problem
> before systemd was invented, which is why various UNIX systems started using
> a merged /usr in the 1990's.

But we're talking about Linux here, where it wasn't a big problem.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[John Hughes]

On 14/11/17 12:53, Rowland Penny wrote:

On Tue, 14 Nov 2017 12:40:02 +0100
John Hughes  wrote:


On 14/11/17 12:32, Joerg Reisenweber wrote:

On Tue 14 November 2017 10:42:48 John Hughes wrote:

Those who do not understand UNIX are condemned to reinvent it,
poorly

funny you quote that in this particular context. Seems to me the
whole mess introduced by systemd (incl the /usr/ disaster) is
exactly that: reinventing unix poorly

Why do you keep claiming the /usr problem is something to do with
systemd?

Probably because it does, it wasn't really a problem until systemd came
along and couldn't seem to fix it.



systemd has no problem with /usr being on a different filesystem *if the 
filesystem is mounted before systemd starts*.


Making sure /usr was mounted before It was needed *was* really a problem 
before systemd was invented, which is why various UNIX systems started 
using a merged /usr in the 1990's.



Do you know what the "sysv" in "sysvinit" refers to?

Yes, thank you.

Oh sorry, you want someone to tell you ;-)

'sys' == 'system'
'v' == Roman numeral four


For values of four that are very close to five.

sysvinit is the set of init scripts for UNIX System V, one of the last 
versions of which was SVR4.2

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Joerg Reisenweber]

On Tue 14 November 2017 10:42:48 John Hughes wrote:
> Of course SVR4.2 could be ported to an ARM SoC -- you'd just put /stand 
> on the internal NAND.  (/stand was the SVR4.2 name for what Linux called 
> /boot).

Let me put it straight for you:

/noot doesn't get you anywhere to bring up a system. Of course you know that, 
so lets assume you agree we need the whole stuff bin, sbin, lib, var, etc, etc, 
on your rootfs too.
Now with systemd and all that ensues, your claim is there must be /usr/* on 
rootfs as well. 
Thats where's the problem starts now: on some SoCs/platforms there might be 
only a few MB of NAND and no other storage (particularly none that is always 
available without additional mounting of filesystems and storage technologies 
needing drivers not monolithic in kernel). Obviously a systemd | usr_on_/ 
system would not fit onto that tiny NAND, while a 'classical orthodox' system 
is supposed to work just fine *without* /usr/ at least in a singleuser mode 
which may well be all you want for your tiny embedded system like they are 
more and more popular and all but obsolete relics like you claimed.

To put it utterly clear and unambiguous: systemd explicitly ignores the needs 
of tiny embedded systems, Poettering been very clear on that. And distros 
follow this path by introducing policies like mandatory /usr/ on rootfs and 
successively phasing out support for other init systems. Requiring embedded-
system-developers to sort out and "unmerge" the /usr/?bin vs /?bin and */lib/ 
stuff is backward in thinking. It's those who need stuff form /usr/* in early 
boot / init who are in charge to find better ways to solve their (pretty 
bizarre) problems than to just mandate all /usr/ being available after just 
rootfs got mounted. It's *not* about when and how to keep or mount /usr/, it's 
about init system and early boot (or a minimal system) is supposed to *not 
need /usr/* at all - at least in a first approximation, usecase specific minor 
modifications might apply.


/j
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Rowland Penny]

On Tue, 14 Nov 2017 12:40:02 +0100
John Hughes  wrote:

> On 14/11/17 12:32, Joerg Reisenweber wrote:
> > On Tue 14 November 2017 10:42:48 John Hughes wrote:
> >> Those who do not understand UNIX are condemned to reinvent it,
> >> poorly
> > funny you quote that in this particular context. Seems to me the
> > whole mess introduced by systemd (incl the /usr/ disaster) is
> > exactly that: reinventing unix poorly
> 
> Why do you keep claiming the /usr problem is something to do with 
> systemd?  

Probably because it does, it wasn't really a problem until systemd came
along and couldn't seem to fix it.

> Did systemd exist in 1991? 

No, thank your deity ;-)

> Do you know what the "sysv" in "sysvinit" refers to?

Yes, thank you.

Oh sorry, you want someone to tell you ;-)

'sys' == 'system'
'v' == Roman numeral four


Rowland
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[John Hughes]

On 14/11/17 12:32, Joerg Reisenweber wrote:

On Tue 14 November 2017 10:42:48 John Hughes wrote:

Those who do not understand UNIX are condemned to reinvent it, poorly

funny you quote that in this particular context. Seems to me the whole mess
introduced by systemd (incl the /usr/ disaster) is exactly that: reinventing
unix poorly


Why do you keep claiming the /usr problem is something to do with 
systemd?  Did systemd exist in 1991?  Do you know what the "sysv" in 
"sysvinit" refers to?


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Joerg Reisenweber]

On Tue 14 November 2017 10:42:48 John Hughes wrote:
> Those who do not understand UNIX are condemned to reinvent it, poorly

funny you quote that in this particular context. Seems to me the whole mess 
introduced by systemd (incl the /usr/ disaster) is exactly that: reinventing 
unix poorly
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[John Hughes]

On 14/11/17 08:30, Joerg Reisenweber wrote:

On Mon 13 November 2017 15:46:30 John Hughes wrote:

systemd didn't exist in 1991 when USL decided that for SVR4.2 /bin, /lib
and /sbin should just be symlinks to /usr.

And when did USL (whoever that is)


USL = UNIX System Laboratories, the successors to the more informal USG 
(Unix Systems Group) inside AT



decide that SVR4.2 doesn't care about being
able to run on any ARM SoC?


Of course SVR4.2 could be ported to an ARM SoC -- you'd just put /stand 
on the internal NAND.  (/stand was the SVR4.2 name for what Linux called 
/boot).



  And how's that relevant for Linux?


Those who do not understand UNIX are condemned to reinvent it, poorly.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Joerg Reisenweber]

On Mon 13 November 2017 15:46:30 John Hughes wrote:
> systemd didn't exist in 1991 when USL decided that for SVR4.2 /bin, /lib 
> and /sbin should just be symlinks to /usr.

And when did USL (whoever that is) decide that SVR4.2 doesn't care about being 
able to run on any ARM SoC? And how's that relevant for Linux?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Alessandro Selli]

On Mon, 13 Nov 2017 at 12:42:50 +0100
Adam Borowski  wrote:

> On Mon, Nov 13, 2017 at 01:14:43AM +0100, Alessandro Selli wrote:
>> On Sun, 12 Nov 2017 at 19:45:02 +0100
>> 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.  Every involved package, and every library recursively depended
>>> upon by one of those packages, would need to be moved
>>> to /{bin,sbin,lib}/.  
>>
>>   Looks trivial to me: /bin, /sbin executables have their dependencies and
>> libraries in /lib on the same filesystem, just like /usr/bin, /usr/sbin
>> and /usr/lib.  What's so complicated?  
>
> But _which_ executables and libraries?

  Any ELF one.

> Are you prepared to move for example Java to /bin|/lib?  It's an insane
> language, yet somehow loved by enterprisey stuff, and is needed to
> authenticate.  And its dependency chains are extensive.  This is not just
> Java, there are far, far more such weird (to us) setups.

  Are you jocking?  We were talking of the boot process on a machine
with /usr sitting on it's own partition.  Do you know of some Unix that needs
Java to boot or to mount it's filesystems?

> There's no sane way to move libraries at install time -- an universal
> distribution would have to put into /lib anything that even a single user
> needs.
>
> And then, imagine you're the maintainer of some random library.  You don't
> care about Java, yet someone wrote java bindings to your library.  Suddenly
> you'd need to move everything to /lib.  Would you get angry?
>
> At some point, you say "enough".

  Yes, I would say "enought", but I would say so to coders who take absurd
design decisions.

>>> 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?  
>>
>>   Last time I checked, Devuan does allow having /usr on a separate
>> filesystem from /.  
>
> Yes, but only if you use an initrd.

  I'm fine with it, I would need it just the same to unlock the cryptsetup'ed
root filesystem.

>  Some simple cases might work as such
> support was dropped only late during the Stretch development cycle, but in
> the future, you'd need to change several hundred packages.

  Just the same as with systemd, isn't it?


Alessandro
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[John Hughes]

On 13/11/17 13:09, Joerg Reisenweber wrote:

On Sun 12 November 2017 21:54:36 Steve Litt wrote:

One more thing: What did people do before maybe 2010,
when /sbin, /bin, /usr/sbin, and /user/bin were four separate
directories? Was life that hard back then? Were develpers smarter?

I'd bet all and my butt on the latter ;-) It's just too obvious.

Maybe intitially it was just systemd cabal who noticed that managing
dependencies in init process isn't exactly a nobrainer and thus (and because
of feature creep like needing d-bus and other high level crap in init) and not
willing to cope with the fallout that correctly beem described as dependency
hell in package/lib dependencies decided to rather cram /usr/ into /


systemd didn't exist in 1991 when USL decided that for SVR4.2 /bin, /lib 
and /sbin should just be symlinks to /usr.



john@sylvania ~ > ls -l / | grep -e '->'
lrwxrwxrwx    1 root sys   8 Apr 15  2005 bin -> /usr/bin
lrwxrwxrwx    1 root sys   8 Apr 15  2005 ccs -> /usr/ccs
lrwxrwxrwx    1 root sys   9 Apr 15  2005 lbin -> 
/usr/lbin

lrwxrwxrwx    1 root sys   8 Apr 15  2005 lib -> /usr/lib
lrwxrwxrwx    1 root sys  10 Apr 15  2005 share -> 
/usr/share
lrwxrwxrwx    1 root sys   8 Apr 15  2005 shlib -> 
/usr/lib
lrwxrwxrwx    1 root root 11 Apr  3  2017 unix -> 
/stand/unix


(I don't have any machines still running UnixWare 1.0, hence the rather 
recent create dates).


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Joerg Reisenweber]

On Sun 12 November 2017 21:54:36 Steve Litt wrote:
> One more thing: What did people do before maybe 2010,
> when /sbin, /bin, /usr/sbin, and /user/bin were four separate
> directories? Was life that hard back then? Were develpers smarter?

I'd bet all and my butt on the latter ;-) It's just too obvious.

Maybe intitially it was just systemd cabal who noticed that managing 
dependencies in init process isn't exactly a nobrainer and thus (and because 
of feature creep like needing d-bus and other high level crap in init) and not 
willing to cope with the fallout that correctly beem described as dependency 
hell in package/lib dependencies decided to rather cram /usr/ into / - after 
all it's just in line with the monolithic approach of systemd at large. Now 
probably more and more devels simply take it as granted that they don't need 
to learn about deoendencies anymore.
What a depressing thought :-/

/j
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Joerg Reisenweber]

On Mon 13 November 2017 00:18:15 Adam Borowski wrote:
> 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!

I can't see a single word of yours in your whole reply that is faintly related 
to the original topic which been "have /usr/ in a separate volume that gets 
mounted early in boot/init process, as opposed to keeping /usr/ on rootfs 
because some nitwits think they don't need to care about dependencies in their 
*EARLY BOOT* processes they develop/maintain"

No need to try and explain to me what's an intrd and how it works, rather it 
seems your expertise and understanding on the whole init process and volume 
mounting and 

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Adam Borowski]

On Sun, Nov 12, 2017 at 04:09:21PM -0600, Patrick Meade wrote:
> On 11/12/2017 12:45 PM, Adam Borowski wrote:
> > At least microcode is mandatory on any modern x86 CPUs, or you risk severe
> > data loss issues that differ by CPU sub-model.  You may think that just
> > because without microcode your machine boots, all is ok.  It's not.  Even
> > worse, the documentation for problems fixed by microcode updates is sparse
> > at best and non-existant in most cases.
> 
> Will you share a link to a source for this?

For example: https://lists.debian.org/debian-security/2016/03/msg00084.html
An unprivileged user in an unprivileged VM gets to execute arbitrary code in
the _host_'s kernel.

There's hundreds of such CPU errata per year.  They usually affect just a
few models, yet there's enough to give a fair share to every CPU you may
have.  And, as Intel and AMD really don't want this to be public, most
errata are fixed silently without an announcement.


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.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Adam Borowski]

On Mon, Nov 13, 2017 at 01:14:43AM +0100, Alessandro Selli wrote:
> On Sun, 12 Nov 2017 at 19:45:02 +0100
> 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.  Every
> > involved package, and every library recursively depended upon by one of
> > those packages, would need to be moved to /{bin,sbin,lib}/.
> 
>   Looks trivial to me: /bin, /sbin executables have their dependencies and
> libraries in /lib on the same filesystem, just like /usr/bin, /usr/sbin
> and /usr/lib.  What's so complicated?

But _which_ executables and libraries?

Are you prepared to move for example Java to /bin|/lib?  It's an insane
language, yet somehow loved by enterprisey stuff, and is needed to
authenticate.  And its dependency chains are extensive.  This is not just
Java, there are far, far more such weird (to us) setups.

There's no sane way to move libraries at install time -- an universal
distribution would have to put into /lib anything that even a single user
needs.

And then, imagine you're the maintainer of some random library.  You don't
care about Java, yet someone wrote java bindings to your library.  Suddenly
you'd need to move everything to /lib.  Would you get angry?

At some point, you say "enough".

> > 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?
> 
>   Last time I checked, Devuan does allow having /usr on a separate filesystem
> from /.

Yes, but only if you use an initrd.  Some simple cases might work as such
support was dropped only late during the Stretch development cycle, but in
the future, you'd need to change several hundred packages.


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.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Steve Litt]

On Sun, 12 Nov 2017 19:45:02 +0100
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 

There's a reason /sbin stood for STATIC bin.

> can be for complex setups?
> Try mounting a filesystem over wifi that requires a fancy
> authentication daemon.

OK fine, for sure for sure. For the 10% doing ultra-unusual stuff, boot
to a combined /bin. For the other 90%, the / partition can have
an /sbin directory with the necessary static programs to mount the root
partition. Once the root partition is mounted, /etc/fstab can be found
and run. And yeah, you'll need some sort of directly-on-/ drivers and
firmware too,for the common stuff.

I'll bet 3/4 of the people can boot no-initramfs to an /ext? root, and
mount /usr to do the rest of the mounts. The rest, which might be able
to be considered an edge case, can use initramfs and boot to a
joined /bin.

How hard would it be to put the drivers for ext? monolithically in the
kernel, along with necessary drivers for lvm and luks?

One more thing: What did people do before maybe 2010,
when /sbin, /bin, /usr/sbin, and /user/bin were four separate
directories? Was life that hard back then? Were develpers smarter?


SteveT

Steve Litt 
November 2017 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Adam Borowski]

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.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Alessandro Selli]

On Sun, 12 Nov 2017 at 19:45:02 +0100
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.  Every
> involved package, and every library recursively depended upon by one of
> those packages, would need to be moved to /{bin,sbin,lib}/.

  Looks trivial to me: /bin, /sbin executables have their dependencies and
libraries in /lib on the same filesystem, just like /usr/bin, /usr/sbin
and /usr/lib.  What's so complicated?

> 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?

  Last time I checked, Devuan does allow having /usr on a separate filesystem
from /.

Alessandro


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Joerg Reisenweber]

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 you want to mount a filesystem via WiFi (what a weird idea) 
*before* you mounted /usr/, 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
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.


> 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


stopping to read here...
> 
> 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? 


> or you risk severe
> data loss issues that differ by CPU sub-model.  You may think that just
> because without microcode your machine boots, all is ok.  It's not.  Even
> worse, the documentation for problems fixed by microcode updates is sparse
> at best and non-existant in most cases.
> 
> 
> Meow!

catfood
whatever
/j
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi folks,

I add the lvm source package to my debian unbreak repository[0][1]. Note
that there is also a debian-security repository[2] that fixes some
security problems introduced by debian (and refused upstream for
security reason).

Regards
   Klaus

[0] ftp://ftp.ethgen.ch/pub/debian/pool/unofficial/l/lvm2
[1] deb ftp://ftp.ethgen.ch/pub/debian ceres unofficial
[2] deb ftp://ftp.ethgen.ch/pub/debian-security ceres unofficial-secured
- -- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Comment: Charset: ISO-8859-1

iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAloIO8cACgkQpnwKsYAZ
9qyCvgwAwrgyMVA3WdCM0DCbSsCfstx/6ifyK1xnuo6Cd4dSYwPUs5EYChvpiLWP
0+P6av64/NGzkHiL/MNyklB3Giej/Q89k0cFk6LlMSjKAnV9eIiJLt80D+3nQBK+
N55FHVfo9sDpKdUjic+4Jc3cGdxGHu89hKbR+p7TUQx+IgRis1GY9BLgvsFGRqYK
5gQlBvxx4lQCMMRyA0NEbQs11OBLNi2rlUjOsclLTwBYN+20wmfm5sNGngzruVVo
OyQYEcTJwiqCIHvkypBv7P88IWQmaask/ov9k1z8Uphi+uKA4w+mmClhcxPcKgTe
oXR+I0dTsQes5eBlY63v47R8KwjZ1N0NpIhkKKw83VRM64XYtB7g0QJqVdhX675X
grdpNkaQxuoG8KRJxTsQZ1QXJ4VxEYNq4W4df06WsQ3Q3zmZmYjbYMvh1UX22hWy
YVQOMmjGG+cGEKNQnvmSLgTcT8BHAC00uxGK3ImYg8KH3mJKXnpptgf26ek/E4G5
NFBZAXrb
=1xuf
-END PGP SIGNATURE-
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Joerg Reisenweber]

On Sun 12 November 2017 09:19:22 John Hughes wrote:
> On 12/11/17 04:24, Joerg Reisenweber wrote:
> > On Tue 07 November 2017 17:50:27 John Hughes wrote:
> >> The separation of / and /usr is a relic of really, really tiny disk
> >> sizes.
> > 
> > Like, for example, ARMv7 systems with a 128MB NAND to boot from, keeping
> > /usr on a separate storage like SSD? Doesn't sound like an obsolete
> > ancient relic
> I have a N900, that is not news to me and has already been addressed by
> Adam Borowski:
> https://lists.dyne.org/lurker/message/20171108.052040.5cb5ca3d.en.html
> 
> > In the last case I'm aware of where someone tried a stock
> > system with a split, Maemo, 

Incorrect, they had a heritage of all stuff living on 240MB root-/ and thus not 
really "tried" since the migration would have required a complete reflash 
(instead of a apt-get install update)
A quote of well known infobot factoids:
>>>optification is a inventive duct tape workaround to reclaim space in fs 
root, done due to the fact the systeminit *and* partitioning is FUBAR,  
http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging,_Deploying_and_Distributing/Installing_under_opt_and_MyDocs,
 
or ""OMG - I wish they looked into FHS and moved /usr to eMMC"", 
http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE2 bullet1,2 and 
fhs-2.3.html#PURPOSE16 dot3"<<<

> >the /usr split was deemed inadequate 

yes, "inadequate" for an OTA upgrade of a deployed productive system to get 
done without loss of user data, by push of a GUI button

> >and they
> > instead decided to move most stuff to /opt while stuffing the usual
> > places
> > with symlinks -- adapting packages enough to have / capable of booting
> > would
> > require too much work.

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 

/j
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Rick Moen]

Quoting John Hughes (j...@atlantech.com):

> I have a N900, that is not news to me and has already been addressed
> by Adam Borowski:
> https://lists.dyne.org/lurker/message/20171108.052040.5cb5ca3d.en.html

Adam saying frequently 'There's no gain to put / and /usr on separate
filesystem[s]' doesn't make it actually, y'know, correct.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[John Hughes]

On 12/11/17 04:24, Joerg Reisenweber wrote:

On Tue 07 November 2017 17:50:27 John Hughes wrote:

The separation of / and /usr is a relic of really, really tiny disk sizes.

Like, for example, ARMv7 systems with a 128MB NAND to boot from, keeping /usr
on a separate storage like SSD? Doesn't sound like an obsolete ancient relic


I have a N900, that is not news to me and has already been addressed by 
Adam Borowski: 
https://lists.dyne.org/lurker/message/20171108.052040.5cb5ca3d.en.html



In the last case I'm aware of where someone tried a stock
system with a split, Maemo, the /usr split was deemed inadequate and they
instead decided to move most stuff to /opt while stuffing the usual 
places
with symlinks -- adapting packages enough to have / capable of booting 
would

require too much work.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Joerg Reisenweber]

On Tue 07 November 2017 17:50:27 John Hughes wrote:
> The separation of / and /usr is a relic of really, really tiny disk sizes.

Like, for example, ARMv7 systems with a 128MB NAND to boot from, keeping /usr 
on a separate storage like SSD? Doesn't sound like an obsolete ancient relic

/j
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[zap]

> John Hughes' sole function on DNG is to say, in many different ways,
> "systemd isn't so bad." Given that systemd being bad is the
> foundational belief that created the Devuan project thus the DNG list,
> he knows he's just making trouble. He's a troll. Don't feed the troll.
>
> I /dev/nulled Hughes years ago, yet still see his words of wisdom. (Note
> to Rick: Your method gets more appealing by the day, but still has
> downsides.)
>
> Let me ask you a couple questions:
>
> 1) If a tree falls in the woods but there's nobody to hear it, did it
> make a sound?
>
> 2) If a troll trolls but everybody's /dev/nulled him, is there really a
> troll?
>
> There have forever been "systemd's not so bad" trolls on DNG, and my
> recommendation remains the same: When you encounter one, killile and
> move on.
>  
> SteveT
That sounds hard to do... (not feeding trolls) given that some people
find certain types of trolls amusing.

That being said, systemd is absolutely awful.  The worst example is in
arch based distros where things already break easily...
>
> Steve Litt 
> October 2017 featured book: Rapid Learning for the 21st Century
> http://www.troubleshooters.com/rl21
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Evilham]

Am 08/11/2017 um 12:18 schrieb Alessandro Selli:
> The "my own PC has been like this so many years" reasoning is a very poor
> justification for a design decision that impacts users that run their
> systems in the most diverse scenarios and environments, just like the "this
> (bad) decision was made many years ago" one.

3 words: Universal Operating System
-- 
Evilham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Alessandro Selli]

On Tue, 7 Nov 2017 at 22:04:05 -0800
Rick Moen  wrote:

>> I don't get why you'd want to keep moving things around on the real
>> system if you can isolate it into initrd.  
>
> OK, I believe you, Adam.  You don't.

  This is a brush on poetry!  :-)


Alessandro
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Alessandro Selli]

On Tue, 7 Nov 2017 at 17:50:27 +0100
John Hughes  wrote:

> On 07/11/17 17:41, dev wrote:
>>
>> On 11/07/2017 10:29 AM, John Hughes wrote:  
>>> On 07/11/17 17:13, Klaus Ethgen wrote:  
 [ separate / and /usr ] is the best way to keep your /usr flexible to
 further lvm grows for example.  
>>> Personally I have a / on a lvm2 volume.  Works OK for me, I see no loss
>>> in flexibility.  
>> Until a user fills up their home directory with kitten gifs and you can
>> no longer login because syslog has no space to write to /var.  
>
> Neither /home not /var are on /, for obvious reasons.  / is for 
> mostly-static things that are owned by the OS or the admin.
>
> The separation of / and /usr is a relic of really, really tiny disk sizes.

  This is just a poor excuse, as there are other good reasons to have /usr on
a separate partition.  Reasons to have /usr on it's own partition include
having:

1) a different filesystems between / and /usr
2) different mount options (like ro)
3) / local and /usr on a shared NFS mount
4) sharing /usr between several installs of the same OS (e.g. to allow to
boot out of a USB stick/disk but having the internal /usr available)
5) / static, /usr on LVM or RAID

  The "my own PC has been like this so many years" reasoning is a very poor
justification for a design decision that impacts users that run their
systems in the most diverse scenarios and environments, just like the "this
(bad) decision was made many years ago" one.


Alessandro

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Dr. Nikolaus Klepp]

Am Mittwoch, 8. November 2017 schrieb Steve Litt:
> On Tue, 7 Nov 2017 21:30:02 +0100
> marc  wrote:
> 
> > Hello
> 
> Hi Marc,
> 
> ===
> Quote from John Hughes
> > > I come from a Unix background -- separate /usr was deprecated in
> > > the 1990's with SVR4.2, I'm kind of amazed it took Linux so long to
> > > catch up.  
> ===
> 
> > Clearly I must have been working in a parallel universe - the
> > commercial unix systems that I remember from the 90s did have
> > /usr and / (some also had /opt and /usr/local in various forms)
> 
> And what I can add as that when I was a Linux newbie around the turn of
> the century, my much more experienced LUGmates were recommending a
> separate /usr, separate /boot, and in fact a tiny, tiny / with all
> major directories mounted.
>

*BSD has a seperate /usr now and I do not think it's going to vanish anytime 
soon. And when doing things in embedded world, it's handy, too :-)

Nik




-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA, CIA ...
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Rick Moen]

Quoting John Hughes (j...@atlantech.com):

> Wave Without a Shore by C.J. Cherryh

Review by Randy Byers:  http://randy-byers.livejournal.com/600709.html
(This Cherryh short novel is most often found, these days, in omnibus
volume _Alternate Realities_, with two other short novels.)


Your implication that people using killfiles are risking solipsism or
insularity is pretty obviously incorrect.  Nobody has time and patience
for everything and everyone -- and thus, as a listadmin for many LUGs, I
have become a huge proponent of people employing either killfiles or
scoring systems (an alternative design supported by, e.g., Emacs GNUS)
to focus their attention on topics and contributors they find
interesting, and to downgrade or discard topics and contributors they
find annoying and/or wastes of time.  Encouraging each participant to do
_this_ is, among other advantages, a major aid to civility, and
facilitates letting each contributor enjoy the experience he/she wants,
without the need to impose top-down, centralised content control just to
fix interpersonal problems.

Or, as we say at Silicon Valley Linux User Group: 

  SVLUG's listadmins normally intervene only to ensure lists' technical
  operation, to halt spam (incontrovertible spam, not postings someone
  merely dislikes), and to halt major eruptions of offtopic spew.
  Enforcement if any should always be minimal and public.  (We don't do
  backroom politics, and our preferred means of social control is to help
  everyone apply his/her own well-tuned killfile.) 

http://www.svlug.org/policies/list-policy.php
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[John Hughes]

On 08/11/17 03:33, Steve Litt wrote:

1) If a tree falls in the woods but there's nobody to hear it, did it
make a sound?
Recommended reading for Steve Litt and others who use a kill-file (not 
that he'll see this):


Wave Without a Shore by C.J. Cherryh


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Rick Moen]

Quoting Adam Borowski (kilob...@angband.pl):

> Systemd is bad, but dropping the pretense that following the needs of _one_
> particular stone-age PDP install is sound design is not bad.

It would be illogical to assert that the only conceivable justification
for separate /usr was Thompson & Richie's 1971 need to spread a UNIX
system across a pair of 1.5MB KR05 disk packs.  I hope you're not
asserting that?

I would hope and expect that, 46 years further on, people would be
implementing that split to further their 2017 needs, not Thompson &
Richie's 1971 ones.

> Of course, as always our dear Lennart does it wrong (it'd be much better to
> follow Hurd instead and use /bin /sbin /lib), but it doesn't make split /usr
> without an initrd any better.

Watch the goalposts, folks:  There's about to be moved.  A moment ago,
Adam was asserting that a /usr split no longer makes sense.  He's about
to switch arguments on the fly, asserting instead that it doesn't make
sense as a _distro policy goal_.  Observe the switcheroo:

> Today, any system where you can realistically install a general-purpose
> distribution has multiple GB of disk space.  There's no gain to put / and
> /usr on separate filesystem

The second sentence doesn't really make sense, and is demonstrably untrue
in isolation (as I will illustrate below).  However, I'll bet if I
challenged it, Adam would fall back on the first sentence, and frame the
discussion as about 'install[ing] a general purpose distribution'.  Et
voila, goalpost relocation!


Distributions are often obliged to make one size fit all, one policy not
suck overmuch for all installing users.  I, on the other hand, am not.

I want my system's primary /bin and /sbin contents (specifically, the
utilities for fsck, partitioning, backup, restore, mkfs, and similar) to
be functional even if /usr for some reason cannot be mounted, or cannot
be relied upon, at bootup.  Where some of those utilites have been IMO
erroneously compiled to have dynamic dependencies on /usr by distro
packages, I create local $FOO-static packages to replace them.

A normally quiescent / partition (given that, on my servers, I mount
/usr, /var, and /home from other filesystems) is highly unlikely to
be exposed to filesystem damage, and there is significant value in 
knowing that it will be usable by the superuser to repair, remake,
backup, and restore the other filesystems.  And yes, if that were not
possible for some reason, I could doubtless PXE boot a maintenance ISO 
and use that instead -- but it's nonetheless worth some small amount of
care and work to me to ensure that / can be used that way under pretty
much all circumstances, and I consider that a normal expectation for 
a Unix system that I see no reason to cease expecting.

And I expect my server systems to be able to boot with simple boot
chains that includes kernels locally compiled by me appropriately to my
system's specific hardware and needs, eliminating the need for an
initramfs -- because I prefer that architectural simplicity.


Objections that my approach doesn't scale to general-purpose
distribution installers are unresponsive to my point.  What I state is
that I have what I consider a rational use-case for separate /usr
without an initramfs for my server systems, and it's irrelevant to my
point whether Devuan or any other distribution decides to facilitate
creation of that specific configuration out of the box.  I didn't _say_
this is something distro installers should do.  All I said is that
people claiming 'there's no gain' to such a configuration are grossly
mistaken.

(To reiterate what I said before:  I am in no way addressing matters of 
policy of this or any other distribution.)


> I don't get why you'd want to keep moving things around on the real
> system if you can isolate it into initrd.

OK, I believe you, Adam.  You don't.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Adam Borowski]

On Tue, Nov 07, 2017 at 09:33:30PM -0500, Steve Litt wrote:
> John Hughes' sole function on DNG is to say, in many different ways,
> "systemd isn't so bad." Given that systemd being bad is the
> foundational belief that created the Devuan project thus the DNG list,
> he knows he's just making trouble. He's a troll. Don't feed the troll.

Systemd is bad, but dropping the pretense that following the needs of _one_
particular stone-age PDP install is sound design is not bad.

Of course, as always our dear Lennart does it wrong (it'd be much better to
follow Hurd instead and use /bin /sbin /lib), but it doesn't make split /usr
without an initrd any better.

Today, any system where you can realistically install a general-purpose
distribution has multiple GB of disk space.  There's no gain to put / and
/usr on separate filesystem, all that you need is /boot (or an EFI
partition).  In the last case I'm aware of where someone tried a stock
system with a split, Maemo, the /usr split was deemed inadequate and they
instead decided to move most stuff to /opt while stuffing the usual places
with symlinks -- adapting packages enough to have / capable of booting would
require too much work.

There's too many obscure use cases, and too much complexity to bother using
the old way.  There are two cases:
* a regular simple system.  No fanciness like split /usr, encrypted LVM on
  RAID6+0+1 over iSCSI over wifi.  No initrd needed.
* complex.  Just plop anything you need into the initrd.

I don't get why you'd want to keep moving things around on the real system
if you can isolate it into initrd.


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.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Steve Litt]

On Tue, 7 Nov 2017 21:30:02 +0100
marc  wrote:

> Hello

Hi Marc,

===
Quote from John Hughes
> > I come from a Unix background -- separate /usr was deprecated in
> > the 1990's with SVR4.2, I'm kind of amazed it took Linux so long to
> > catch up.  
===

> Clearly I must have been working in a parallel universe - the
> commercial unix systems that I remember from the 90s did have
> /usr and / (some also had /opt and /usr/local in various forms)

And what I can add as that when I was a Linux newbie around the turn of
the century, my much more experienced LUGmates were recommending a
separate /usr, separate /boot, and in fact a tiny, tiny / with all
major directories mounted.


> But regardless of this, what you are doing here is called an
> "appeal to authority" and so of limited relevance.

Pre-cisely. The "Appeal to
Authority" (https://en.wikipedia.org/wiki/Argument_from_authority) is
one of several informal logical falicies. Hughes claims expertise from
his "Unix background", but we have no proof. He's saying "follow my
lead, I'm knowledgeable."  

But wait, there's more:

===
In another recent post, Hughes said, in relation to the inability to
run a mounted /usr without initramfs':

> What does this have to do with systemd?  
===

In the preceding, Hughes feigns ignorance, as if he doesn't know that
systemd's tenticles go right into initramfs, to the extent systemd
SHUTDOWN references initramfs. He pretends non-knowledge of the fact
that the same guys tying Gnome and systemd together, FreeDesktop.Org,
have been the driving force behind the great /bin, /sbin/, /usr/sbin
and /usr/bin merge, and he pretends his thorough 1980's Unix knowledge
doesn't include the fact that you need a separate /sbin with at least a
static mount and a few other commands in order to mount /usr as part of
the boot process.

John Hughes' sole function on DNG is to say, in many different ways,
"systemd isn't so bad." Given that systemd being bad is the
foundational belief that created the Devuan project thus the DNG list,
he knows he's just making trouble. He's a troll. Don't feed the troll.

I /dev/nulled Hughes years ago, yet still see his words of wisdom. (Note
to Rick: Your method gets more appealing by the day, but still has
downsides.)

Let me ask you a couple questions:

1) If a tree falls in the woods but there's nobody to hear it, did it
make a sound?

2) If a troll trolls but everybody's /dev/nulled him, is there really a
troll?

There have forever been "systemd's not so bad" trolls on DNG, and my
recommendation remains the same: When you encounter one, killile and
move on.
 
SteveT

Steve Litt 
October 2017 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Rick Moen]

Quoting John Hughes (j...@atlantech.com):

> The separation of / and /usr is a relic of really, really tiny disk sizes.

It _originated_ in everything not fitting on one disk on Ken Thompson
and Dennis Ritchie's PDP-11, at a point in 1971, originally as a place
for user home directories.  Rob Landley has a good version of the story:
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

However, there are other compelling use-cases for it.  (The
freedesktop.org kiddies claiming those use-cases don't exist or
shouldn't matter doesn't signify.)  As to 'just use an initramfs for
that', I'd personally prefer my servers not have them, towards the goal
of simplifying system architecture.

(Above is not an argument of any sort about distro policy.  Distros 
are welcome to set policies according to their criteria.  I will then
ignore and override those policies to run my systems as I prefer.)

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[marc]

Hello

> I come from a Unix background -- separate /usr was deprecated in the 1990's
> with SVR4.2, I'm kind of amazed it took Linux so long to catch up.

Clearly I must have been working in a parallel universe - the
commercial unix systems that I remember from the 90s did have
/usr and / (some also had /opt and /usr/local in various forms)

But regardless of this, what you are doing here is called an
"appeal to authority" and so of limited relevance.

Having a small safe userland to boot up the full system allows
one to recover from a number of mishaps and permits complex
startup routines. In the past this was separated out with /
and /usr, now most of the startup logic lives in an opaque
mess called initrd/initramfs which every distribution hacks
up in its own so special way. I don't regard this as progress.

A wiser decision would have been to merge the initramfs with
/, so that / could optionally live in RAM and linuxrc can be
normal init right off the bat - that would allow one to eliminate
the complicated and brittle mess that we know as mkinitrd.

Yes, /etc would need to be made persistent somehow. That would
still be simpler than the current mkinitrd. If done smartly it
would even allow one to have a "safe" /etc version permitting
rollbacks from config finger trouble.

regards

marc
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[KatolaZ]

On Tue, Nov 07, 2017 at 05:14:21PM +0100, Klaus Ethgen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> #157
> 
> Regards
>Klaus

Good things happen to those who can wait ;)

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[dev]

On 11/07/2017 10:50 AM, John Hughes wrote:
> Neither /home not /var are on /, for obvious reasons.  / is for
> mostly-static things that are owned by the OS or the admin.

Ah, I misunderstood. Apologies for the static.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[John Hughes]

On 07/11/17 17:50, John Hughes wrote:


The separation of / and /usr is a relic of really, really tiny disk 
sizes.


(The first machine I used had 8 megacharacter disks -- not megabyte, 
megacharacter.   Six bit characters.  Ok, it didn't run Unix.  :-)).


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[John Hughes]

On 07/11/17 17:41, dev wrote:


On 11/07/2017 10:29 AM, John Hughes wrote:

On 07/11/17 17:13, Klaus Ethgen wrote:

[ separate / and /usr ] is the best way to keep your /usr flexible to
further lvm grows for example.

Personally I have a / on a lvm2 volume.  Works OK for me, I see no loss
in flexibility.

Until a user fills up their home directory with kitten gifs and you can
no longer login because syslog has no space to write to /var.


Neither /home not /var are on /, for obvious reasons.  / is for 
mostly-static things that are owned by the OS or the admin.


The separation of / and /usr is a relic of really, really tiny disk sizes.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[dev]

On 11/07/2017 10:29 AM, John Hughes wrote:
> On 07/11/17 17:13, Klaus Ethgen wrote:
>> [ separate / and /usr ] is the best way to keep your /usr flexible to
>> further lvm grows for example.
> 
> Personally I have a / on a lvm2 volume.  Works OK for me, I see no loss
> in flexibility.

Until a user fills up their home directory with kitten gifs and you can
no longer login because syslog has no space to write to /var.

The "everything on slash" mentality is a short-sighted partitioning
workaround that never should have seen the light of day. Many commercial
packages do this as well and those systems give me endless grief when
applications running there either fill up /var or dump endless blobs in
/tmp.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[John Hughes]

On 07/11/17 17:13, Klaus Ethgen wrote:

[ separate / and /usr ] is the best way to keep your /usr flexible to
further lvm grows for example.


Personally I have a / on a lvm2 volume.  Works OK for me, I see no loss 
in flexibility.


Like I say, SVR4.2 deprecated separate /usr in the 1990's.  I haven't 
used a machine without the root filesystem being on a LVM type system 
(VXVM in fact) since around 1998.





___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

#157

Regards
   Klaus
- -- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Comment: Charset: ISO-8859-1

iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAloB290ACgkQpnwKsYAZ
9qy4qgv7Bl/ZLp7QXyJQYt7K5PKTQW84rupI5exwPmQOi2c4FyBLtB0rCQ+ZFjIy
O6KW7ZHqvJ2wpRs4jQMj9TppMPS7jbYME3UtWzsATnQSGqtEv2JXWTAwnSDkIq99
9gT0eFoPwh4timUmm4skP9qdXvPh7G5OZ33R5VFlWh64ejiybjw2l1Mp6sMa8xJy
J7VW4ZvGlGGrv1UP8rsY3kV2NyIJ1xqHb2Le+t5orDXqN/8r7S7rkWJmMnlixo0O
8Z3QC56r2jzpFyfsVSYpUOH0nDtTqcm1ymUPBOfHkMddjOmmZfv/ntS/YGGxoYjs
vyc964xerSNtyAAR+K7mA43rxTfdcWDW6V+bZl3a1R730nfiGcd+3aDMPjiIUEJx
5KoPpk4UwY0s0NAzZM5HyS5ABQkfRlBGpynfKjWUs6gRYTnellD3dJnaP2h16gxf
LdS9/EXjCS0pIm86WBIjmT6p3r3wt2fOqckDv8lRLus4U2lrR9MBNYj1QRALcMQ7
3mhnSFgo
=f//S
-END PGP SIGNATURE-
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Di den  7. Nov 2017 um 17:07 schrieb John Hughes:
> > Well, Debian deprecated a separate /usr as systemd is not working good
> > with a separate /usr.
> 
> They actually deprecated it as many things were not working with a separate
> /usr.  systemd has no more or less problems than anything else that uses
> things on /usr.
> 
> I come from a Unix background -- separate /usr was deprecated in the 1990's
> with SVR4.2, I'm kind of amazed it took Linux so long to catch up.

Well, it was never a problem until they brought systemd into debian. All
my systems have separate /usr and just a very small /.

That SVR4.2 deprecated that was just the fact that proprietary packages
often polite other path under / like /opt or even worse.

It is the best way to keep your /usr flexible to further lvm grows for
example.

> In this particular case it's a bit irritating, it could be fixed by moving
> liblz4 to /lib or by not linking the various lvm2 binaries against
> libsystemd.

Well, yes, the proper solution would be to not ling against libsystemd.

Regards
   Klaus
- -- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Comment: Charset: ISO-8859-1

iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAloB26gACgkQpnwKsYAZ
9qyCSgwAi2+q0b0OW1PTlUHHGwigFg3kZFisXV2M5v6SCXyF6Eww6zZeYsnzJy8t
FmE2WjCyxIECJLWiUBQfAMw5GpxVkHcVrKq2AKZfzdDvUV6rK6NE6CCQi+IqPx3O
hi4AvG1LC6YlauHsOwVmB48wdVx+7TQmLu4Mth+E0hIPO+32PTfUhHLZlKoTMm0x
MpUSBEr7LKnts2UjZnT0qcPzGtQV3g6w9ioqNsHytRgjgDSDIjZY7rf3A/J/89+Y
EIotJuGwHNuEcpwZHm68YYaRO0UasZt2zEhOQozdm2dD0Vyn7wQKZpFIauHteGus
RblSyPpdUtdKAfdEyjz8fi7UbvGn91tnWGr5VUmnOStqEwOJqJv9l46wzDZbqdyv
b/Umfq54A1HGF6CS3jzF3h5E5mx59dboGLE/vfWGEqkTX4UH7jIYQDE2duedSbES
uk4FCXE9AOV/KR1FwblAD6Ndqr1o7OCInSvCeRmgnW7t//MKG/F1X1RkbVZ3FOau
vGSqYkbf
=j9Jq
-END PGP SIGNATURE-
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[John Hughes]

On 07/11/17 16:50, Klaus Ethgen wrote:



If you have an seperate /usr (what is not supported by the ignorance of
systemd) and that /usr on lvm and a kernel with no initrd (what does not
exist in the ignorance of systemd), then you are doomed and your system
will not boot anymore.

What does this have to do with systemd?

Well, Debian deprecated a separate /usr as systemd is not working good
with a separate /usr.


They actually deprecated it as many things were not working with a 
separate /usr.  systemd has no more or less problems than anything else 
that uses things on /usr.


I come from a Unix background -- separate /usr was deprecated in the 
1990's with SVR4.2, I'm kind of amazed it took Linux so long to catch up.


In this particular case it's a bit irritating, it could be fixed by 
moving liblz4 to /lib or by not linking the various lvm2 binaries 
against libsystemd.


Presumably devuan and debian will have differing ideas of how and 
whether this should be fixed.  :-)


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Klaus Ethgen]

Am Di den  7. Nov 2017 um 17:00 schrieb Klaus Ethgen:
> > So, could you please also file a bug report in Devuan with a link to
> > Debian's bug report? Use bugs.devuan.org for that.
> 
> Done.

Hmm... Doesn't seem to work. I sent the attached mail but nothing
happened.

Regards
   Klaus
-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
--- Begin Message ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: lvm2
Version: 2.02.175-1
Severity: critical

Debian-Bug: #881057
- -- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Comment: Charset: ISO-8859-1

iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAloB17cACgkQpnwKsYAZ
9qxZzAwAlFcMHa0sFqAbZ9jpltQv/jGqfqEaVJBJVRg1330QdDslv/AUg1hmU18A
razNeKeUKjE7q4chuFT1B9YzRbDOGUKxUpL2jSD2K67TK1NgwPEK2XHZZw/NXv5X
azO12eHHtkc4tQ4RVMJN0zQM9fr0fu5VjyfxoEtJHUcLJShqhFqPWebzJj26+eYB
a5ruZ0cR2PDtfH6GD2l5Iq1aXaA6hYWbB+2e5j/g4aMkvglyCBnZ8hB7nTd2yxeY
kRJSFFLfGz8GzE3gvaPQi61O/9YmNbgDtVzjltjpKx3Gvb88guMwoQQZL3QF7P+I
1uL2F874CUPajIQ2OOxtvrzYdjj6JU3P6lZI/piqG573+xwtG4HOf5LGi3pscs4M
H+/O0uZw1/iM/Y27Kbj6YZuSbuJkEBQ44uFj2h4qF9AzG0E23HqWp3rEE/8gQLQM
vV/pfKyPUMUOfJD0gkvEBftgl3sJ2KXEetGFvWKj9LoDErQ0xf7A9XmgMOZ7IOX/
H86dcVHX
=d2Sf
-END PGP SIGNATURE-
--- End Message ---


signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Evilham]

Am 07/11/2017 um 17:00 schrieb Klaus Ethgen:
> The first broken version is 2.02.175-1, or other way, the last working
> version is 2.02.173-1.
> 
>> So, could you please also file a bug report in Devuan with a link to
>> Debian's bug report? Use bugs.devuan.org for that.
> Done.
> 
>> Change log and WHATS_NEW file don't contain mentions of a
>> similar-sounding issue. The only thing fixed regarding 2.02.175 is:
>> - Fix detection of moved PVs in vgsplit. (2.02.175)
>> Which doesn't sound like your problem.
>> It wouldn't hurt to try to chroot your way into the system and upgrade
>> the package though.
> Well, The problem is that I _did_ an upgrade and ended with a unbootable
> system. I had to boot with grml and installed version 2.02.173-1 what
> fixed the problem.
> 
> ldd do show the dependencies to /usr if you want to check yourself.

Thank you!

Actually, John's last email explains it all :) I didn't go that far in
the troubleshooting right now.

That bug report should help make sure we don't land that beyond our
unstable regardless of what Debian does with it.
-- 
Evilham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Di den  7. Nov 2017 um 16:50 schrieb John Hughes:
> So, it seems some things depend on lz4.  But nothing mentions it directly.
> 
> But, here's the problem -- lvm2 depends on
> /lib/x86_64-linux-gnu/libsystemd.so.0 and *that* depends on liblz4.
> 
> This is sad.

True. Especially as that dependency is absolutelly not needed.

It is the way they want to bring systemd dependencies into any package.

> To allow /usr-less booting either lvm2 should not depend on libsystemd, or
> liblz4 should be moved to /lib.

Well, nothing should depend on libsystemd. liblz4 is not needed by lvm.

Regards
   Klaus
- -- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Comment: Charset: ISO-8859-1

iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAloB2WIACgkQpnwKsYAZ
9qyk+gwAuSkjN9X804keuhoyq99jkgkJZeD3ki4fiu1duuV6wa3FsBrGo6bbEFP9
8mKXGkb6yMjfAyylRU+xP646YuDZ4PKMVj8bHEzs2zW02LzUa1K7r7e5A4fOeSJ/
yMnwsB+xJurSKFoWtzzicysV/E8F8+BmDCv3jMnFfjg/w2BN9vpSnJBomp0EOdvL
xR8DfvMXBLefmZYZHJ9M0r+ZH1nv5dK5759/3YhUa0QjUJXv2gdohFIe90drCWqY
IEnyj/o3KcZWfP+kIdPgz0s+CCX01SdGUJYxsTXcwNlly3IZaBy6mYKfUBmm1ELX
1ExeJDpnuFV4EEJkIpGMNEZZ28Ix9kmkuxJvwMMj6kQNkso6AjlFxOq0gk1n7cK+
+t5WmbzT5eYQoQ+m97CsalSc264wlFzaFJQkVmT5keGA4KVM8mW5XV2SVcTDP0Xw
W51WjS3b9S4tHHbhnsDurNBk7gyVoRaLEYXio/PtXYJ2mYb7zYhXbwqGaBbqz3cH
OevxqmCo
=byNB
-END PGP SIGNATURE-
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Di den  7. Nov 2017 um 16:22 schrieb Evilham:
[broken lvm2 in debian]
> This is quite serious.
> 
> If you found the issue only appears with 2.02.175-1, Devuan Jessie and
> Ascii would be safe, so no need to worry yet. We do have to keep track
> of how (and if) it gets fixed in Debian.

The first broken version is 2.02.175-1, or other way, the last working
version is 2.02.173-1.

> So, could you please also file a bug report in Devuan with a link to
> Debian's bug report? Use bugs.devuan.org for that.

Done.

> Change log and WHATS_NEW file don't contain mentions of a
> similar-sounding issue. The only thing fixed regarding 2.02.175 is:
> - Fix detection of moved PVs in vgsplit. (2.02.175)
> Which doesn't sound like your problem.
> It wouldn't hurt to try to chroot your way into the system and upgrade
> the package though.

Well, The problem is that I _did_ an upgrade and ended with a unbootable
system. I had to boot with grml and installed version 2.02.173-1 what
fixed the problem.

ldd do show the dependencies to /usr if you want to check yourself.

Gruß
   Klaus
- -- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Comment: Charset: ISO-8859-1

iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAloB2LIACgkQpnwKsYAZ
9qxQ9gv+PDN9A7ry3uc23PDrMjUgZ0SkDlYT37KcSBGLdx+NmmWedKaBuqVRVogU
+tt9gn9lbkEbs5d9xKHP+LnT5GIwa+vRjtkojh+zA8I8xsyBnAJoZdlcfNGBaqNs
1xfe8pQOPI6pP4vwPWVZcVRS1w0/2Unuos9QsP9A0Krs8nGMUEnx4ZJW1TIQsVLH
E+t2p8ixw9UhcHLVNg3rqCtdZms/p/98/y9oGtPSLj+P96kmOY7FLIpuwrnX8zH6
75vfegz7ILq2WhKV/ogtZ97gmEC1uGutD+4Wfr7PzG+2nnJ5Vm01YlNLp5fo3HzP
t8jAaPYnKqSgLx0G1MaHjACKCKvMJR6+SPp0LnH3l0IGPybNXHG1jqkhWaP2ywbc
NkYGpAxDzuBk0kTtmGosOEWIccauIFll85B2W05qSSrmo6lubtPShoGCVJtheb/7
+TnBnZRFbOIq8W11m4UWPHYqb5BDidnNVZemyhUKNVhJuInvVkcE0N6U2f6XELHB
zstCkphs
=ei4u
-END PGP SIGNATURE-
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Di den  7. Nov 2017 um 16:21 schrieb John Hughes:
> On 07/11/17 15:29, Klaus Ethgen wrote:
> 
> > today I suffered by a heavy bug in lvm2. With version 2.02.175-1 it
> > starts to depend on library in /usr.
> 
> Which binary? What library in /usr?

/sbin/lvm
Lib /usr/lib/x86_64-linux-gnu/liblz4.so.1

> > If you have an seperate /usr (what is not supported by the ignorance of
> > systemd) and that /usr on lvm and a kernel with no initrd (what does not
> > exist in the ignorance of systemd), then you are doomed and your system
> > will not boot anymore.
> 
> What does this have to do with systemd?

Well, Debian deprecated a separate /usr as systemd is not working good
with a separate /usr.

> If your system uses sysvinit instead of systemd does it manage to mount /usr
> if /usr is on lvm?  How?

Well, lvm as all important binaries never depend on any in /usr. So why
shouldn't that work? It was a common setup until systemd found the way
into debian.

Regards
   Klaus
- -- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Comment: Charset: ISO-8859-1

iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAloB1k8ACgkQpnwKsYAZ
9qy8AQv/e5BRGf5b6gzwESflesMkZVxS2eu3oDCarbjN+szC/sNN+mQHgEtsdQNt
0+uKYGq0a7lD90rJhjJdJG6MuR7UMtc0t3xFoqBwiXIyyM4brME3gwxWLPUrc6l3
ERY5zrDTirg+Z6dqiFyaMGVg04+C0lmSnTsvUWVxrF5QK6Dh+Vv8opjzvw+Iawlx
UqB3lY4v2dvKeFshGJ71XYCkDq/0ed7to73MBrR5kqZDsugSmtekN4XvIFLEWZOK
z2kA0V52FhFn9AIkz75J1cRSReg8lvD+BrzjyPu5NyGDkyGG3eKiuDX01V41xTO1
LGQYYwORi278Dt6uW9sAgP/fEJK1yaqJJqzApBBtkSs08OZELIt6/vMKt0bb+w6s
LtK0kSVK53lJC85FSnwkKkx67yJmrWInEp15ebzcAziDCCOJDDqqLtE7Z0TM9B+f
MbtNKCcYYnAlrdeHwbmgPdj+0ozOMKkglHuVi/Jhou0Q/MhUxksucj3FYI9xz7Hu
+X8ocGHq
=z6wT
-END PGP SIGNATURE-
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[John Hughes]

On 07/11/17 16:21, John Hughes wrote:

On 07/11/17 15:29, Klaus Ethgen wrote:


today I suffered by a heavy bug in lvm2. With version 2.02.175-1 it
starts to depend on library in /usr.


Which binary? What library in /usr?


So, it seems some things depend on lz4.  But nothing mentions it directly.

But, here's the problem -- lvm2 depends on 
/lib/x86_64-linux-gnu/libsystemd.so.0 and *that* depends on liblz4.


This is sad.

To allow /usr-less booting either lvm2 should not depend on libsystemd, 
or liblz4 should be moved to /lib.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Evilham]

Am 07/11/2017 um 16:22 schrieb Evilham:
> This is currently the last pushed commit (Release 2.02.178-1):
> https://gitlab.com/debian-lvm/lvm2/commit/90bc98f3828032a1ad24daf14e2e2f2f704f1bd6

I meant 2.02.175-1, of course.
-- 
Evilham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[Evilham]

Hallo Klaus,

Am 07/11/2017 um 15:29 schrieb Klaus Ethgen:
> today I suffered by a heavy bug in lvm2. With version 2.02.175-1 it
> starts to depend on library in /usr.
> 
> If you have an seperate /usr (what is not supported by the ignorance of
> systemd) and that /usr on lvm and a kernel with no initrd (what does not
> exist in the ignorance of systemd), then you are doomed and your system
> will not boot anymore.
> 
> How is that going in devuan? Will it be repaired? I already filled an
> bugreport in debian but I believe it will be closed as wontfix by

This is quite serious.

If you found the issue only appears with 2.02.175-1, Devuan Jessie and
Ascii would be safe, so no need to worry yet. We do have to keep track
of how (and if) it gets fixed in Debian.

So, could you please also file a bug report in Devuan with a link to
Debian's bug report? Use bugs.devuan.org for that.

Just mentioning that the current version in Debian Sid is 2.02.176 and I
can't find a git repository that includes those changes...
This is currently the last pushed commit (Release 2.02.178-1):
https://gitlab.com/debian-lvm/lvm2/commit/90bc98f3828032a1ad24daf14e2e2f2f704f1bd6

Change log and WHATS_NEW file don't contain mentions of a
similar-sounding issue. The only thing fixed regarding 2.02.175 is:
- Fix detection of moved PVs in vgsplit. (2.02.175)
Which doesn't sound like your problem.
It wouldn't hurt to try to chroot your way into the system and upgrade
the package though.
-- 
Evilham



signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[John Hughes]

On 07/11/17 15:29, Klaus Ethgen wrote:


today I suffered by a heavy bug in lvm2. With version 2.02.175-1 it
starts to depend on library in /usr.


Which binary? What library in /usr?


If you have an seperate /usr (what is not supported by the ignorance of
systemd) and that /usr on lvm and a kernel with no initrd (what does not
exist in the ignorance of systemd), then you are doomed and your system
will not boot anymore.


What does this have to do with systemd?

If your system uses sysvinit instead of systemd does it manage to mount 
/usr if /usr is on lvm?  How?

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng