Re: [DNG] some ASCII issues

[Alessandro Selli]

On Wed, 5 Jul 2017 at 02:48:31 -0700
Rick Moen  wrote:

> Quoting Alessandro Selli (alessandrose...@linux.com):
>
>>> 'It cannot work if what you need to do is feeding the HD controller some
>>> proprietary firmware that cannot legally be embedded in the GPL driver.'
>>>
>>> Has nothing whatsover to do with distribution.  Obviously.
>> 
>>   It obviously does, because that is one of the reasons distributions
>> have to equip their kernels with initramfs: they are needed on machines
>> that would otherwise fail to boot due to the fact they will be unable to
>> mount / on boot.
>
> The post in question had nothing to do with any of that. 

  The whole thread does.
  More reality-denying will take you nowhere.

  Didn't you state: "Which reminds me, I have many better things to do"?  Time
to keep up with your (empty) promises.


-- 
Alessandro Selli http://alessandro.route-add.net
VOIP SIP: dhatarat...@ekiga.net
Chiavi PGP/GPG keys: B7FD89FD, 4A904FD9
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[Rick Moen]

Quoting Alessandro Selli (alessandrose...@linux.com):

> > 'It cannot work if what you need to do is feeding the HD controller some
> > proprietary firmware that cannot legally be embedded in the GPL driver.'
> >
> > Has nothing whatsover to do with distribution.  Obviously.
> 
>   It obviously does, because that is one of the reasons distributions have to
> equip their kernels with initramfs: they are needed on machines that would 
> otherwise
> fail to boot due to the fact they will be unable to mount / on boot.

The post in question had nothing to do with any of that. 

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

Re: [DNG] some ASCII issues

[Rick Moen]

Quoting Antony Stone (antony.st...@devuan.open.source.it):

> Not at all - I have that as a standard sig on all my list postings.  If you 
> had something similar I would have replied to you differently.

It's OK with me either way.  I was just amused by the contrast between
you going _out of your way_ to send others redundant offlist copies and
also requesting inside the very same message that nobody do the same to you.

It's OK with me either way because I use procmail to control what copies
I get and eliminate duplicates.  Glad to share the recipe if you want
it.  (Personally, I find that works better than trying to tell others how
to send mail.)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[Antony Stone]

On Wednesday 05 July 2017 at 10:57:07, Rick Moen wrote:

> Quoting Antony Stone:
> > Would you two please take your personal flame war offlist, and argue with
> > each other in private?
> 
> I've twice asked the other gentleman to please go away and argue with
> someone else.  I hope that helps.

It would probably help more if you simply stopped responding to his comments 
on this thread.  I believe that would bring his comments to an end also.

> As to the rest, the record should show that I have not been flaming the
> other gentleman, nor making personal comments of any kind.  Accordingly,
> I would appreciate it if you did not again so claim.  Thank you.

Okay, perhaps 'flame' was an inappropriate term, but it's certainly a tedious 
inter-personal disagreement which the rest of us don't need to share in.

On Wednesday 05 July 2017 at 10:59:51, Rick Moen wrote:

> Oh, by the way, Anthony, I notice you had:
> > From: Antony Stone
> > To: dng@lists.dyne.org, Rick Moen,  Alessandro Selli
> 
> but also:
> >   Please reply to the list;
> >   please *don't* CC me.
> 
> Sauce for the goose, but not for the gander?  ;->

Not at all - I have that as a standard sig on all my list postings.  If you 
had something similar I would have replied to you differently.


Regards,


Antony.

-- 
If you were ploughing a field, which would you rather use - two strong oxen or 
1024 chickens?

 - Seymour Cray, pioneer of supercomputing

   Please reply to the list;
 please *don't* CC me.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[Rick Moen]

Oh, by the way, Anthony, I notice you had:

> From: Antony Stone 
> To: dng@lists.dyne.org, Rick Moen ,
> Alessandro Selli 

but also:

>Please reply to the list;
>  please *don't* CC me.

Sauce for the goose, but not for the gander?  ;->

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

Re: [DNG] some ASCII issues

[Rick Moen]

Quoting Antony Stone (antony.st...@devuan.open.source.it):

> Would you two please take your personal flame war offlist, and argue with 
> each 
> other in private?

I've twice asked the other gentleman to please go away and argue with
someone else.  I hope that helps.

As to the rest, the record should show that I have not been flaming the
other gentleman, nor making personal comments of any kind.  Accordingly,
I would appreciate it if you did not again so claim.  Thank you.
 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[Antony Stone]

On Wednesday 05 July 2017 at 10:49:30, Rick Moen wrote:

> Quoting Alessandro Selli (alessandrose...@linux.com):
> >   I twice quoted the thread proving what I reported was just what was
> >   been
> > 
> > discussed.
> 
> 'It cannot work if what you need to do is feeding the HD controller some
> proprietary firmware that cannot legally be embedded in the GPL driver.'
> 
> Has nothing whatsover to do with distribution.  Obviously.
> 
> Have a nice day.  With someone else.

Would you two please take your personal flame war offlist, and argue with each 
other in private?

I think you have both made your points quite sufficiently for the list members 
to be aware of your opinions, and to decide for themselves how the GPL relates 
to initrds and distribution.


Thank you,


Antony Stone
-- 
"In fact I wanted to be John Cleese and it took me some time to realise that 
the job was already taken."

 - Douglas Adams

   Please reply to the list;
 please *don't* CC me.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[Rick Moen]

Quoting Alessandro Selli (alessandrose...@linux.com):

>   I twice quoted the thread proving what I reported was just what was been
> discussed. 

'It cannot work if what you need to do is feeding the HD controller some
proprietary firmware that cannot legally be embedded in the GPL driver.'

Has nothing whatsover to do with distribution.  Obviously.

Have a nice day.  With someone else.

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

Re: [DNG] some ASCII issues

[Alessandro Selli]

On Wed, 5 Jul 2017 at 01:16:46 -0700
Rick Moen  wrote:

> Quoting Alessandro Selli (alessandrose...@linux.com):
>
>> It was and it stayed centered there, no matter how much you insist in
>> stating the opposite.  I already provided proof of it.
>
> Your actual wording, which I quoted, says otherwise.  Have a great day.

  I twice quoted the thread proving what I reported was just what was been
discussed.  You could never counter those facts with other than your baseless
opinions.



-- 
Alessandro Selli http://alessandro.route-add.net
VOIP SIP: dhatarat...@ekiga.net
Chiavi PGP/GPG keys: B7FD89FD, 4A904FD9
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[Rick Moen]

Quoting Alessandro Selli (alessandrose...@linux.com):

> It was and it stayed centered there, no matter how much you insist in
> stating the opposite.  I already provided proof of it.

Your actual wording, which I quoted, says otherwise.  Have a great day.

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

Re: [DNG] some ASCII issues

[Alessandro Selli]

On Tue, 4 Jul 2017 at 23:55:30 -0700
Rick Moen  wrote:

> Quoting Alessandro Selli (alessandrose...@linux.com):
> 
> >  It is relevant in proving you cannot do that and *lawfully* distribute
> > the module, which is what I have kept saying.
> 
> Indeed, you do keep trying to change the topic to distribution.

  It was and it stayed centered there, no matter how much you insist in
stating the opposite.  I already provided proof of it.

>  But I already pointed that out.  ;->

  You always avoided to consider the relevant facts, you keep countering
reality with gratuitous opinions.

>>   I am not turning it into it, I am keeping it into it.
>
> That's simply not what you said upthread.

  Yes, it is, and I already provided twice proof of it, documenting the
evolution of the thread's discussion.  You could never counter those facts
with anything other than opinions, in fact you consistently ignored those
facts all along.  You always failed providing a pointer where the discussion
turned from the distribution to someone's (whom?) personal case, as well as
failing the focal point of providing a workable way to boot a system without
an initramfs in the case a proprietary firmware is needed to mount the root
filesystem.

>>   Your opinions were pretty clearly stated. 
>
> Again, I expressed _no_ view concerning distribution, as that was not the
> matter under discussion.

  I know, you wrote about your very specific, personal case, and that's the
problem: the discourse was about distributions, not someone's (your) unique
case.



-- 
Alessandro Selli http://alessandro.route-add.net
VOIP SIP: dhatarat...@ekiga.net
Chiavi PGP/GPG keys: B7FD89FD, 4A904FD9
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[Rick Moen]

Quoting Alessandro Selli (alessandrose...@linux.com):

>  It is relevant in proving you cannot do that and *lawfully* distribute the
> module, which is what I have kept saying.

Indeed, you do keep trying to change the topic to distribution.  But I
already pointed that out.  ;->

>   I am not turning it into it, I am keeping it into it.

That's simply not what you said upthread.

>   Your opinions were pretty clearly stated. 

Again, I expressed _no_ view concerning distribution, as that was not the
matter under discussion.

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

Re: [DNG] some ASCII issues

[Alessandro Selli]

On 05/07/2017 at 01:52, Rick Moen wrote:
> Quoting Alessandro Selli (alessandrose...@linux.com):
> 
> [b43 firmware BLOB]
> 
>>   It goes there *after* is was extracted out of the proprietary driver.
> 
> I'm of course aware of that -- but that's irrelevant to what I was
> saying, which is that it fails to qualify as an example of compiling a
> firmware BLOB into a GPLed driver.

 It is relevant in proving you cannot do that and *lawfully* distribute the
module, which is what I have kept saying.

> In any event, you seem to keep trying strenously to turn this into a
> discussion about distribution.

  I am not turning it into it, I am keeping it into it.

>  That's nice, but it simply wasn't what
> we were talking about.

  You might at most speak for yourself.  Go through the thread again (if you
ever did that, which at this point I doubt).

>  I'm guessing that you wish to attribute to me an
> opinion about that to argue with, but I didn't express or imply one in
> this thread.

  Your opinions were pretty clearly stated.  The issue is that you keep your
words floating in the realm of opinions, all the while avoiding to provide
the technical solution that would put everything to rest:

«  If you disagree, kindly point out what other method is available
that allows a kernel to lawfully feed a controller a
[proprietary] firmware before mounting the root FS.»
(edited)


Alessandro

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

Re: [DNG] some ASCII issues

[Didier Kryn]

Le 04/07/2017 à 13:08, Alessandro Selli a écrit :

   Right, which brings up the issue that you cannot produce a distibution
without an initramfs because, among the other problems, some of the drivers
it comes with, some of which are needed to mount the root filesystem, do need
a proprietary firmware.  What one can do on his own PC does not constitute a
solution for the distribution.


It brings the issue that you cannot produce a *universal* 
distribution without an initramfs etc...


I don't know of any distribution with a pretention to be universal 
without an initramfs. initramfs is what distros need to be as universal 
as possible.


Considering no distribution will provide you with the proprietary 
blob you need for your specific hardware, you will have to hack it a 
little bit and go beyond what the distro can give you. Either you hack 
the initramfs, or you hack the kernel, or you buy hardware which can be 
managed by free software. This leaves you with 3 options (at least). Not 
too bad :-)


Didier


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

Re: [DNG] some ASCII issues

[Rick Moen]

Quoting Alessandro Selli (alessandrose...@linux.com):

[b43 firmware BLOB]

>   It goes there *after* is was extracted out of the proprietary driver.

I'm of course aware of that -- but that's irrelevant to what I was
saying, which is that it fails to qualify as an example of compiling a
firmware BLOB into a GPLed driver.

In any event, you seem to keep trying strenously to turn this into a
discussion about distribution.  That's nice, but it simply wasn't what
we were talking about.  I'm guessing that you wish to attribute to me an
opinion about that to argue with, but I didn't express or imply one in
this thread.

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

Re: [DNG] some ASCII issues

[Alessandro Selli]

On Tue, 4 Jul 2017 at 15:33:57 -0700
Rick Moen <r...@linuxmafia.com> wrote:

> Quoting Alessandro Selli (alessandrose...@linux.com):
> 
>>   You are still failing the easiest way to demonstrate your point:  
>
> Non-sequitur argument noted in passing.

  You failed once more.  You must be enjoining it.

>>   It's not just *my* experience, it's a long established fact.  I also
>> provided with pointers to a relevant example...  
>
> Sorry, that goes into /lib/firmware like other similiar BLOBs, not into
> the related b43 driver.

  It goes there *after* is was extracted out of the proprietary driver.  Why
don't you read what otehr people documented before posting?

>> That is, I write for the... third? fourth? time, due to the fact that you
>> cannot (legally) distribute files that mix proprietary code with GPL'ed
>> code,  
>
> Which, as noted, is you changing the subject:  At the point where I
> pointed out your mistake, you were talking about compiling firmware into
> GPL drivers, not distribution.

  Here is, again, the full evolution of the current discussion:

Author: Gary Olzeke
Date: 2017-06-22 23:02 +200
To: dng
Subject: [DNG] some ASCII issues

Writes about issues upgrading ASCII from the Jessie CD install;

Author: Hendrik Boom
Date: 2017-06-23 02:44 +200
To: dng
Subject: Re: [DNG] some ASCII issues

Wonders if that could be "a side effect of debian/systemd's fusion of /usr
with /?"

Author: Jaromil
Date: 2017-06-23 16:01 +200
To: Hendrik Boom
CC: dng
Subject: Re: [DNG] some ASCII issues

Wrote:
"?!?!?! did they ?!?!?!

how is this madness done, via mount -o bind ????"

Author: Antony Stone
Date: 2017-06-23 16:41 +200
To: dng
Subject: Re: [DNG] some ASCII issues

Replied with:

"https://wiki.debian.org/UsrMerge

[...]

https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ if
you want to start feeling annoyed as well as surprised."


Author: John Morris
Date: 2017-06-24 01:55 +200
To: dng
Subject: Re: [DNG] some ASCII issues

Commented:

"Dunno, that one actually makes a lot of sense. Applying the logic of
Chesterton's Fence here seems sound."

Author: Steve Litt
Date: 2017-06-24 03:08 +200
To: dng
Subject: Re: [DNG] some ASCII issues

"I'd love to boot without initramfs, which is a
black box that's hard to look around in."

Author: Didier Kryn
Date: 2017-06-24 11:08 +200
To: Steve Litt, dng
Subject: Re: [DNG] some ASCII issues

"Anyway I think there's a simple method to live without the 
initramfs. Everything which is done from initramfs could be done the 
same way from a disk partition, which might make it easier to debug:"


Author: Rick Moen
Date: 2017-06-28 07:57 +200
To: dng
Subject: Re: [DNG] some ASCII issues

"Step 1.  Compile a kernel that includes inline all key drivers including
 those needed to find the root filesystem."


Author: Alessandro Selli
Date: 2017-07-03 00:19 +200
To: dng
Subject: Re: [DNG] some ASCII issues

"It cannot work if what you need to do is feeding the HD controller some
proprietary firmware that cannot legally be embedded in the GPL driver."

  I can, of course, print it and mail it to you, was it necessary.


  Bye,


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

Re: [DNG] some ASCII issues

[Alessandro Selli]

On Tue, 4 Jul 2017 at 14:41:28 -0700
Rick Moen  wrote:

> Quoting Alessandro Selli (alessandrose...@linux.com):
>
>> On Mon, 3 Jul 2017 at 13:06:41 -0700
>> Rick Moen  wrote:
>>   
>> > Your upthread hypothetical didn't mention Devuan at all.  
>> 
>> Of course it did.  
>
> What you said, verbatim and without any qualifications, was 'It cannot
> work if what you need to do is feeding the HD controller some
> proprietary firmware that cannot legally be embedded in the GPL driver.'
> My sole point was that is factually incorrect

  You are still failing the easiest way to demonstrate your point:

«  If you disagree, kindly point out what other method is available
that allows a kernel to lawfully feed a controller a
[proprietary] firmware before mounting the root FS.»
(edited)

> -- leaving aside the fact
> that your assumption of proprietary firmware getting embedded into
> drivers is also untrue in my experience.

  It's not just *my* experience, it's a long established fact.  I also
provided with pointers to a relevant example, that of course you pretended
was not there before your eyes.  I'll try again to get it through that thick
skull of yours:

[alessandro@wkstn04 ~]$ apt-cache show b43-fwcutter
Package: b43-fwcutter
Priority: optional
Section: utils
Installed-Size: 93
Maintainer: Ubuntu Developers 
Original-Maintainer: Daniel Echeverry 
Architecture: amd64
Version: 1:019-3
Depends: libc6 (>= 2.4), debconf (>= 0.5) | debconf-2.0
Filename: pool/main/b/b43-fwcutter/b43-fwcutter_019-3_amd64.deb
Size: 25714
MD5sum: bba7a66c17a3c6c1926f5592fed63fc8
SHA1: c98130c0c0d8acbf6c3ecc96c3b7108b3c28de60
SHA256: 1545d709c25b32c0f385d192215ab628a6cf803d9ff52a90a39a44ca7f971105
Description-en: utility for extracting Broadcom 43xx firmware
 This package provides a tool for extracting BCM43xx wireless chip
 firmware from Broadcom's proprietary driver files.
 .
 It is used by the firmware-b43(legacy)-installer packages as part of
 the automated process of downloading and installing firmware.
Description-md5: 19713b4b3c64e57d9fe7a1aec56c25e1
Homepage: http://wireless.kernel.org/en/users/Drivers/b43
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu
Supported: 9m

[alessandro@wkstn04 ~]$

  Proprietary Nvidia Linux drivers too do stuff everything together inside a
gargantuan module.

>  (In my experience, separate
> kernel loaders load firmware BLOBs from image files kept under
> /lib/firmware .)

  That is, I write for the... third? fourth? time, due to the fact that you
cannot (legally) distribute files that mix proprietary code with GPL'ed code,
such as Linux mainstream kernel modules are.
My dog has learned that by now.

>> Next time, before replying, please read at least the thread's object
>> line.  
>
> Unfortunately for this rhetorical ploy, you were, of course, like other
> participants, disregarding the Subject header, topic drift having
> occurred.

  I fully documented how the topic has progressed.  Shall I do that again?

> But you already know that, everyone else already knows that, and you're
> now just wasting everyone's time.  Which reminds me, I have many better
> things to do.

  Yes, I know, to you anything is better than confronting reality.

  Be gone.

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

Re: [DNG] some ASCII issues

[Rick Moen]

Quoting Alessandro Selli (alessandrose...@linux.com):

> On Mon, 3 Jul 2017 at 13:06:41 -0700
> Rick Moen  wrote:
> 
> > Your upthread hypothetical didn't mention Devuan at all.
> 
> Of course it did.

What you said, verbatim and without any qualifications, was 'It cannot
work if what you need to do is feeding the HD controller some
proprietary firmware that cannot legally be embedded in the GPL driver.'
My sole point was that is factually incorrect -- leaving aside the fact
that your assumption of proprietary firmware getting embedded into
drivers is also untrue in my experience.  (In my experience, separate
kernel loaders load firmware BLOBs from image files kept under
/lib/firmware .)

> Next time, before replying, please read at least the thread's object
> line.

Unfortunately for this rhetorical ploy, you were, of course, like other
participants, disregarding the Subject header, topic drift having
occurred.

But you already know that, everyone else already knows that, and you're
now just wasting everyone's time.  Which reminds me, I have many better
things to do.


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

Re: [DNG] some ASCII issues

[Alessandro Selli]

On Tue, 4 Jul 2017 at 14:12:09 +0200
Alessandro Selli  wrote:

[...]

> They are advanced, mostly SAS and FC controllers, maybe some iSCSI
> device too.  Mostly Enterprise hardware, not consumer-PC.

  I did a quick search, all (or at least most) devices on the first page were
hardware RAID controllers.



-- 
Alessandro Selli http://alessandro.route-add.net
VOIP SIP: dhatarat...@ekiga.net
Chiavi PGP/GPG keys: B7FD89FD, 4A904FD9
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[Alessandro Selli]

On Tue, 4 Jul 2017 at 12:44:34 +0100
KatolaZ  wrote:

> On Tue, Jul 04, 2017 at 01:08:24PM +0200, Alessandro Selli wrote:
> 
> [cut]
>
>>
>>   Right, which brings up the issue that you cannot produce a distibution
>> without an initramfs because, among the other problems, some of the
>> drivers it comes with, some of which are needed to mount the root
>> filesystem, do need a proprietary firmware.  What one can do on his own
>> PC does not constitute a solution for the distribution.
>>
>
> Uh? Which are those proprietary drivers needed to mount the root
> filesystem?

  Filesystems that reside on units handled by a controller that needs to be
fed a proprietary firmware in order for the driver to be able to send it
commands.  They are advanced, mostly SAS and FC controllers, maybe some iSCSI
device too.  Mostly Enterprise hardware, not consumer-PC.

>  AFAICT, Linux-libre is able to mount almost any
> filesystem, from almost any existing storage device,

  *Almost*, you're right.

> The only problem here is supporting some wifi devices and some video
> cards.

  This too is a problem if you're performing a network boot over such a WiFi
device.

> The only non-free binary blob I have installed is iwlwifi,
> which is not at all needed at boot.

  I know, but, again, when you're designing an OS you must keep in mind more
things than those that so far have happened to you.  I do run Devuan on a
pretty customized setup:

[alessandro@draco ~]$ lsb_release -d
Description:Devuan GNU/Linux 1.0 (jessie)
[alessandro@draco ~]$ uname -r
4.9.35.draco0
[alessandro@graco ~]$ 

  But I'm not saying any of the solutions I adopted is the way to solve
problems distyribution-wise, like those that were addressed in this thread
(/ and /usr merge, initramfs).


  Greetings,


-- 
Alessandro Selli http://alessandro.route-add.net
VOIP SIP: dhatarat...@ekiga.net
Chiavi PGP/GPG keys: B7FD89FD, 4A904FD9
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[Stephan Seitz]

On Di, Jul 04, 2017 at 12:44:34 +0100, KatolaZ wrote:

Uh? Which are those proprietary drivers needed to mount the root
filesystem?  AFAICT, Linux-libre is able to mount almost any
filesystem, from almost any existing storage device, without requiring
any proprietary binary blob at all.


There are professional network cards which require a non-free firmware, 
e.g. Broadcom.

So if your rootfs is an iSCSI volume you would need the firmware.

Besides that I don’t know any „normal” SATA/SAS controller requiring 
firmware.


Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[KatolaZ]

On Tue, Jul 04, 2017 at 01:08:24PM +0200, Alessandro Selli wrote:

[cut]

> 
>   Right, which brings up the issue that you cannot produce a distibution
> without an initramfs because, among the other problems, some of the drivers
> it comes with, some of which are needed to mount the root filesystem, do need
> a proprietary firmware.  What one can do on his own PC does not constitute a
> solution for the distribution.
>

Uh? Which are those proprietary drivers needed to mount the root
filesystem?  AFAICT, Linux-libre is able to mount almost any
filesystem, from almost any existing storage device, without requiring
any proprietary binary blob at all.

The only problem here is supporting some wifi devices and some video
cards. The only non-free binary blob I have installed is iwlwifi,
which is not at all needed at boot.

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- 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] some ASCII issues

[Alessandro Selli]

On Tue, 4 Jul 2017 at 11:41:05 +0100
KatolaZ  wrote:

> On Tue, Jul 04, 2017 at 12:18:19PM +0200, Alessandro Selli wrote:
> 
> [cut]
> 
> > > didn't involve a right
> > > reserved under copyright in the first place,
> > 
> >   Let me remind you GPL is a licence, and that it prohibits linking
> > proprietary code with free code in the same binary file.
> > 
> 
> Sorry, but this is totally wrong, and quite misleading. By freedom 0,
> you can *use* a GNU GPL software for whatever task you like, and even
> link it with other proprietary software of your choice, without
> limitations. Any single or company can take GNU GPL software out there
> and *use* it as they want, even together with other proprietary
> software.

  I know, I don't dispute this.

> What you *cannot* do is *distributing* a software covered by the GNU
> GPL, or a modification thereof, inside of or in combination with a
> software that has a license more restrictive than the GNU GPL itself,
> or that is incompatible with the GNU GPL.

  Right, which brings up the issue that you cannot produce a distibution
without an initramfs because, among the other problems, some of the drivers
it comes with, some of which are needed to mount the root filesystem, do need
a proprietary firmware.  What one can do on his own PC does not constitute a
solution for the distribution.

  The thread was about Devuan and other distribution's filesystem layout
(the / and /usr merge) and their use and need of an initramfs, not about how
someone could tweak his/her own PC to customize it in such a way an initramfs
can be done away with.



-- 
Alessandro Selli http://alessandro.route-add.net
VOIP SIP: dhatarat...@ekiga.net
Chiavi PGP/GPG keys: B7FD89FD, 4A904FD9
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[KatolaZ]

On Tue, Jul 04, 2017 at 12:18:19PM +0200, Alessandro Selli wrote:

[cut]

> > didn't involve a right
> > reserved under copyright in the first place,
> 
>   Let me remind you GPL is a licence, and that it prohibits linking
> proprietary code with free code in the same binary file.
> 

Sorry, but this is totally wrong, and quite misleading. By freedom 0,
you can *use* a GNU GPL software for whatever task you like, and even
link it with other proprietary software of your choice, without
limitations. Any single or company can take GNU GPL software out there
and *use* it as they want, even together with other proprietary
software.

What you *cannot* do is *distributing* a software covered by the GNU
GPL, or a modification thereof, inside of or in combination with a
software that has a license more restrictive than the GNU GPL itself,
or that is incompatible with the GNU GPL.

Again, the GNU GPL *does* *not* prohibit linking GNU GPL software with
proprietary software and *using* the combination as you like. It
prohibits *distributing* GNU GPL software under a non-GPL license, or
together or in combination with other software released under GNU
GPL-incompatible licenses.

I know I have repeated the same two concepts twice above, but
unfortunately the inhability to spot the simple difference between
*use* and *distribution* has attracted a lot of undue hatred on the
GNU GPL. And the usage of the legalese *convey* to indicete
*distribute* in the GNU GPL 3 didn't help at all to clarify this
point.

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- 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] some ASCII issues

[Arnt Karlsen]

On Mon, 3 Jul 2017 02:00:22 +0200, Alessandro wrote in message 
<20170703020022.7ede7fb3@ayu>:

> On Mon, 3 Jul at 2017 01:03:13 +0200
> Arnt Karlsen  wrote:
> 
> > On Mon, 3 Jul 2017 00:42:52 +0200, Alessandro wrote in message 
> > <20170703004252.748a9c7f@ayu>:
> > 
> >> Il giorno Wed, 28 Jun 2017 19:38:11 +0200
> >> Didier Kryn  ha scritto:
> >>
> >>> Le 28/06/2017 à 15:40, Stephan Seitz a écrit :  
> >>> > And today you should always encrypt your discs. 
> >>>
> >>>  I don't see any reason to encrypt /usr. You might like to
> >>> encrypt /etc because it contains user names and (already
> >>> encrypted) passwords. But definitely there is no reason to
> >>> encrypt everything.  
> >> 
> >>   Valid reasons to encrypt /usr include:
> >> 
> >> 1) /usr resides on the same partition as / and/or /home (trivial
> >> case); 2) protecting its files from being tampered with when the
> >> device is offline;
> >> 3) making harder to someone who can access your
> >> offline HD understand which partition is /, or /usr or /home, so
> >> that the attacker will have to try to decrypt them all;
> >> 4) you put stuff in /usr/local that might contain
> >> keys/passwords/sensitive information that would better be kept
> >> protected.  
> >
> > ..if you wanna protect /usr/local, chop that off /usr and 
> > encrypt, mount etc them all as you damned please.
> 
>   /usr/local was standardized for a reason.  You might do as you like
> on your personal PC, maybe you're not as free to do the same on your
> company's server/workstation.

..a corner case might be company centralized maintenance on hardware
where you mount your handy encrypted /usr/local, /opt, /home/arnt etc
while keeping the company un-encrypted hardware accessible for e.g.
airport etc 'Securitate.'

>  You might have /opt bind-mounted
> on /usr/local, and have lots of stuff there you don't want to peruse
> to see if any of it would better be kept away from prying eyes (like
> VM images). What specific reasons do you have *not* to encrypt /usr
> in a machine that has / and /home encrypted?  What do you gain by
> that? 

..not much, all valid reasons to encrypt.
On Mon, 3 Jul 2017 02:20:22 +0200, Alessandro wrote in message 
<20170703022022.2e7ff012@ayu>:
>   I forgot to mention: leaking your collection of installed software
> is sometimes itself leaking personal and possibly sensitive
> information about yourself and your business, for the same reasons
> TCP/IP traffic metadata is important in it's own right.

..precisely, can easily be done by e.g. airport etc 'Securitate' or 
by your own network traffic.

> Plus, if you travel extensively, you might not know if the place
> you're traveling into has enacted some restrictions on the kind of
> software you are allowed to own and run.

..precisely, is why you research upfront and plan ahead, even 
for tin foil kinda stuff ... oh wait, who's #45? ;oD

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[Alessandro Selli]

On Sun, 2 Jul 2017 at 17:51:48 -0700
Rick Moen  wrote:

> Quoting Alessandro Selli (alessandrose...@linux.com):
>
>> It cannot work if what you need to do is feeding the HD controller some
>> proprietary firmware that cannot legally be embedded in the GPL driver.
>
> ITYM that the resulting derivative work cannot be lawfully
> redistributed.  But compiling the driver does not redistribute it.

  Devuan in a public, general-purpose distribution, not an OS tailored to the
specific environment of a single individual's HW/layout.

> (I'm not necessarily endorsing your view about proprietary firmware.

  It's not *my* view, it's the law, it's the real world out there.

> I'm just pointing out that your conclusion doesn't follow from the
> premise.)

  They are not *my* conclusions, they are real-world issues.  The fact they
never impacted your operations does not make them neither inexistant nor
irrelevant.

  If you disagree, kindly point out what other method is available that
allows a kernel to lawfully feed a controlelr a firmware before mounting the
root FS.


-- 
Alessandro Selli http://alessandro.route-add.net
VOIP SIP: dhatarat...@ekiga.net
Chiavi PGP/GPG keys: B7FD89FD, 4A904FD9
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[Rick Moen]

Quoting Alessandro Selli (alessandrose...@linux.com):

> It cannot work if what you need to do is feeding the HD controller some
> proprietary firmware that cannot legally be embedded in the GPL driver.

ITYM that the resulting derivative work cannot be lawfully
redistributed.  But compiling the driver does not redistribute it.

(I'm not necessarily endorsing your view about proprietary firmware.
I'm just pointing out that your conclusion doesn't follow from the
premise.)

If you disagree, kindly point out what reserved right of a copyright
owner is involved in said compilation.  Thanks.

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

Re: [DNG] some ASCII issues

[Alessandro Selli]

On Mon, 3 Jul 2017 at 01:03:13 +0200
Arnt Karlsen  wrote:

> On Mon, 3 Jul 2017 00:42:52 +0200, Alessandro wrote in message 
> <20170703004252.748a9c7f@ayu>:
> 
>> Il giorno Wed, 28 Jun 2017 19:38:11 +0200
>> Didier Kryn  ha scritto:
>>   
>>> Le 28/06/2017 à 15:40, Stephan Seitz a écrit :  
 And today you should always encrypt your discs. 
>>>
>>>  I don't see any reason to encrypt /usr. You might like to
>>> encrypt /etc because it contains user names and (already encrypted)
>>> passwords. But definitely there is no reason to encrypt everything.  
>> 
>>   Valid reasons to encrypt /usr include:
>> 
>> 1) /usr resides on the same partition as / and/or /home (trivial
>> case); 2) protecting its files from being tampered with when the
>> device is offline;
>> 3) making harder to someone who can access your
>> offline HD understand which partition is /, or /usr or /home, so that
>> the attacker will have to try to decrypt them all;
>> 4) you put stuff in /usr/local that might contain
>> keys/passwords/sensitive information that would better be kept
>> protected.  
> 
> ..if you wanna protect /usr/local, chop that off /usr and 
> encrypt, mount etc them all as you damned please.

  I forgot to mention: leaking your collection of installed software is
sometimes itself leaking personal and possibly sensitive information about
yourself and your business, for the same reasons TCP/IP traffic metadata is
important in it's own right.  Plus, if you travel extensively, you might not
know if the place you're traveling into has enacted some restrictions on the
kind of software you are allowed to own and run.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[Alessandro Selli]

On Mon, 3 Jul at 2017 01:03:13 +0200
Arnt Karlsen  wrote:

> On Mon, 3 Jul 2017 00:42:52 +0200, Alessandro wrote in message 
> <20170703004252.748a9c7f@ayu>:
> 
>> Il giorno Wed, 28 Jun 2017 19:38:11 +0200
>> Didier Kryn  ha scritto:
>>
>>> Le 28/06/2017 à 15:40, Stephan Seitz a écrit :  
>>> > And today you should always encrypt your discs. 
>>>
>>>  I don't see any reason to encrypt /usr. You might like to
>>> encrypt /etc because it contains user names and (already encrypted)
>>> passwords. But definitely there is no reason to encrypt everything.  
>> 
>>   Valid reasons to encrypt /usr include:
>> 
>> 1) /usr resides on the same partition as / and/or /home (trivial
>> case); 2) protecting its files from being tampered with when the
>> device is offline;
>> 3) making harder to someone who can access your
>> offline HD understand which partition is /, or /usr or /home, so that
>> the attacker will have to try to decrypt them all;
>> 4) you put stuff in /usr/local that might contain
>> keys/passwords/sensitive information that would better be kept
>> protected.  
>
> ..if you wanna protect /usr/local, chop that off /usr and 
> encrypt, mount etc them all as you damned please.

  /usr/local was standardized for a reason.  You might do as you like on your
personal PC, maybe you're not as free to do the same on your company's
server/workstation.  You might have /opt bind-mounted on /usr/local, and have
lots of stuff there you don't want to peruse to see if any of it would better
be kept away from prying eyes (like VM images).
  What specific reasons do you have *not* to encrypt /usr in a
machine that has / and /home encrypted?  What do you gain by that?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[Arnt Karlsen]

On Mon, 3 Jul 2017 00:42:52 +0200, Alessandro wrote in message 
<20170703004252.748a9c7f@ayu>:

> Il giorno Wed, 28 Jun 2017 19:38:11 +0200
> Didier Kryn  ha scritto:
> 
> > Le 28/06/2017 à 15:40, Stephan Seitz a écrit :
> > > And today you should always encrypt your discs.   
> >
> >  I don't see any reason to encrypt /usr. You might like to
> > encrypt /etc because it contains user names and (already encrypted)
> > passwords. But definitely there is no reason to encrypt everything.
> 
>   Valid reasons to encrypt /usr include:
> 
> 1) /usr resides on the same partition as / and/or /home (trivial
> case); 2) protecting its files from being tampered with when the
> device is offline;
> 3) making harder to someone who can access your
> offline HD understand which partition is /, or /usr or /home, so that
> the attacker will have to try to decrypt them all;
> 4) you put stuff in /usr/local that might contain
> keys/passwords/sensitive information that would better be kept
> protected.

..if you wanna protect /usr/local, chop that off /usr and 
encrypt, mount etc them all as you damned please.

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[Alessandro Selli]

Il giorno Wed, 28 Jun 2017 19:38:11 +0200
Didier Kryn  ha scritto:

> Le 28/06/2017 à 15:40, Stephan Seitz a écrit :
> > And today you should always encrypt your discs.   
>
>  I don't see any reason to encrypt /usr. You might like to encrypt 
> /etc because it contains user names and (already encrypted) passwords. 
> But definitely there is no reason to encrypt everything.

  Valid reasons to encrypt /usr include:

1) /usr resides on the same partition as / and/or /home (trivial case);
2) protecting its files from being tampered with when the device is offline;
3) making harder to someone who can access your offline HD understand which
partition is /, or /usr or /home, so that the attacker will have to try to
decrypt them all;
4) you put stuff in /usr/local that might contain keys/passwords/sensitive
information that would better be kept protected.

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

Re: [DNG] some ASCII issues

[Alessandro Selli]

On Wed, 28 Jun 2017 at 08:09:21 -0700
Rick Moen  wrote:

> Quoting Stephan Seitz (stse+dev...@fsing.rootsland.net):
> 
> > That the kernel can’t find the root filesystem if it is encrypted?
> > And the kernel lacks the capability to ask you for the password.  
>
> If you're correct that a kernal cannot find an encrypted rootfs, then by
> the same token it cannot find an encrypted initrd, either.  So, what
> have you really gained?

  The initramfs does not need to be encrypted, because it does not have the
key to decrypt the HD.  It has the routine that prompts for the decryption
key and uses it to decrypt the root partition.

> In any event, I think you are incorrect.  Here's a runthrough that Pavel
> Kogan wrote, and nothing he describes requires an initrd.  He _does_ 
> use a RAMdisk to store the keyfile after booting, but that's a different
> matter.  http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/

  Here are the relevant lines:

I tried various methods to get GRUB to load the keyfile into memory
and pass it to the kernel, without success. Then, I realised that the
initrd image is itself something GRUB loads into memory, and
mkinitcpio.conf has a very convenient FILES option…

FILES=/crypto_keyfile.bin

Run mkinitcpio again, and when you reboot, you’ll only need to enter
your password once.


>> >Anyway, I don't want to encrypt all discs on my Linux server for  
>> 
>> Well, server may be a special case.  
>
> It's funny how all the new Linux kiddies keep wanting to dismiss what
> I've been doing since 1993 on Linux (and since the 1980s on other
> *nixes) as a 'special case'.

  Servers are indeed a different matter.  They are usually not kept home,
rather in a secure, dedicated and protected environment.  Thus they are less
susceptible to be:

1) stolen in a house burglary;
2) impounded during a police raid into your home.

  And you usually do not travel with your server inside your case, as
opposed to what you do with your laptop.


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

Re: [DNG] some ASCII issues

[Alessandro Selli]

On Tue, 27 Jun 2017 at 22:57:16 -0700
Rick Moen  wrote:

> Quoting John Morris (jmor...@beau.org):
>
>> Nope, that negates one of the principle reasons to use an initramfs in
>> the first place.  You assume the stock kernel can see the drive where
>> you intend to put this new partition; one of the big drivers of initrd
>> in the first place was exotic hardware, etc. so GRUB uses BIOS
>> (including extension ROMs on controller cards) to load both the kernel
>> and the initrd so it can take whatever steps are needed, i.e load the
>> right modules, start lvm, setup encrypted filesystem magic, etc. to make
>> the main drive/partitions/etc. visible.  Your idea could deal with most
>> everything that didn't need a kernel module but totally fails at that
>> task.  
> 
> Step 1.  Compile a kernel that includes inline all key drivers including
>  those needed to find the root filesystem.
> Step 2.  Profit!
> 
> That's the old-school method.

  It cannot work if what you need to do is feeding the HD controller some
proprietary firmware that cannot legally be embedded in the GPL driver.


Alessandro

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

Re: [DNG] some ASCII issues

[Didier Kryn]

Le 29/06/2017 à 01:08, Harald Arnesen a écrit :

Didier Kryn [2017-06-28 19:38]:


  I don't see any reason to encrypt /usr. You might like to encrypt
/etc because it contains user names and (already encrypted) passwords.
But definitely there is no reason to encrypt everything.

But if you encrypt anything at all, isn't it easier to encrypt everything?


AFAIU this subthread started with the chicken-and-egg problem of 
the decrypting software being encrypted, which is exactly what happens 
if one encrypts everything :-)



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

Re: [DNG] some ASCII issues

[Harald Arnesen]

Rick Moen [2017-06-28 20:33]:

> Temporary files in /tmp are sometimes a little sensitive and sometimes
> greatly so.  (It's usually a tmpfs on my systems.)  Operational paranoia
> suggests keeping it at least cleaned up frequently, if you're going to
> bother to have /home as a dmcrypt filesystem.  That's where tmpfs is
> actually helpful in the sense that erasure means a file from there is
> truly gone.

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

Re: [DNG] some ASCII issues

[Harald Arnesen]

Didier Kryn [2017-06-28 19:38]:

>  I don't see any reason to encrypt /usr. You might like to encrypt 
> /etc because it contains user names and (already encrypted) passwords. 
> But definitely there is no reason to encrypt everything.

But if you encrypt anything at all, isn't it easier to encrypt everything?
-- 
Hilsen Harald
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[Didier Kryn]

Le 28/06/2017 à 20:33, Rick Moen a écrit :

Quoting Didier Kryn (k...@in2p3.fr):


 I don't see any reason to encrypt /usr. You might like to
encrypt /etc because it contains user names and (already encrypted)
passwords. But definitely there is no reason to encrypt everything.

/home would be where I keep anything that's sensitive.  I'm unclear on
why usernames in /etc are deemed sensitive, but I'm sure needs differ.

Temporary files in /tmp are sometimes a little sensitive and sometimes
greatly so.  (It's usually a tmpfs on my systems.)  Operational paranoia
suggests keeping it at least cleaned up frequently, if you're going to
bother to have /home as a dmcrypt filesystem.  That's where tmpfs is
actually helpful in the sense that erasure means a file from there is
truly gone.


Sure /home is the first place one thinks of encrypting and /tmp is 
the second, together with possible other fancy dirs. Encrypting passwd 
and the like would just add a little of security-through-obscurity by 
even hiding the usernames; this is why I considered /etc as a third 
(non-obvious) thing to encrypt; /etc also contains every local 
configuration, and it might make sense to hide it all.


To simplify, all of /home and /tmp aren't really part of the OS. 
The OS can boot without them. All the rest is the OS and is the same as 
any other install of the same OS; and there isn't any reason to encrypt 
something which is published and widespread.


Didier

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

Re: [DNG] some ASCII issues

[Rick Moen]

Quoting Didier Kryn (k...@in2p3.fr):

> I don't see any reason to encrypt /usr. You might like to
> encrypt /etc because it contains user names and (already encrypted)
> passwords. But definitely there is no reason to encrypt everything.

/home would be where I keep anything that's sensitive.  I'm unclear on
why usernames in /etc are deemed sensitive, but I'm sure needs differ.

Temporary files in /tmp are sometimes a little sensitive and sometimes
greatly so.  (It's usually a tmpfs on my systems.)  Operational paranoia
suggests keeping it at least cleaned up frequently, if you're going to
bother to have /home as a dmcrypt filesystem.  That's where tmpfs is
actually helpful in the sense that erasure means a file from there is
truly gone.

Stephan's assertion that dmcrypt rootfs is impossible without an initrd
certainly _might_ be correct.  In casual reading, I found that one
obstacle is that the code for the 'cryptdevice' and 'cryptkey' keywords
in GRUB work only with initrd.  There are similar keywords for syslinux,
but I couldn't tell in a quick survey whether they are initrd-specific.

Anyway, my broader point is that, if I wanted to mount my rootfs as
dmcrypt, I'd try a few things and see if it could be done my preferred
simplified-architecture way with a locally compiled kernel without an
initrd.  Are there further obstacles beyond bootloader keyword
limitations?  That's what trying would determine.  If nothing seemed to
work, I'd probably just punt and build a minimal initrd just for the
things seemingly inaccessible any other way.  (There's no point in being
a fanatic about it.)

Since I don't happen to want to try that today, that's an exploration
for another time (in my view).

And my even broader point is that nowhere is it written that a
technology must be absolutely universally loved by, and useful to,
everyone before anyone is allowed to like and use it.  Calling how I've
maintained my computing home on Linux a 'niche' since 1993 seems like a
little much.  Your niche, my normality.  This isn't Microsoft; one size
isn't required to fit all.

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

Re: [DNG] some ASCII issues

[Didier Kryn]

Le 28/06/2017 à 15:40, Stephan Seitz a écrit :
And today you should always encrypt your discs. 


I don't see any reason to encrypt /usr. You might like to encrypt 
/etc because it contains user names and (already encrypted) passwords. 
But definitely there is no reason to encrypt everything.


Didier


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

Re: [DNG] some ASCII issues

[Rick Moen]

Quoting Stephan Seitz (stse+dev...@fsing.rootsland.net):

> That the kernel can’t find the root filesystem if it is encrypted?
> And the kernel lacks the capability to ask you for the password.

If you're correct that a kernal cannot find an encrypted rootfs, then by
the same token it cannot find an encrypted initrd, either.  So, what
have you really gained?

In any event, I think you are incorrect.  Here's a runthrough that Pavel
Kogan wrote, and nothing he describes requires an initrd.  He _does_ 
use a RAMdisk to store the keyfile after booting, but that's a different
matter.  http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/

> >Anyway, I don't want to encrypt all discs on my Linux server for
> 
> Well, server may be a special case.

It's funny how all the new Linux kiddies keep wanting to dismiss what
I've been doing since 1993 on Linux (and since the 1980s on other
*nixes) as a 'special case'.  Both funny-haha and funny-peculiar.

> Well, I want it.

Happily, I'm not standing in your way.


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

Re: [DNG] some ASCII issues

[Stephan Seitz]

On Mi, Jun 28, 2017 at 06:55:37 -0700, Rick Moen wrote:

Yes, and this will not work with new-school methods like disc
encryption because something needs to ask you for the password.

What exactly about LUKS is incompatible with use of a kernel compiled to
include all key drivers including those to find the root filesystem
(thus eliminating a dependency on initrds)?  Nothing in


That the kernel can’t find the root filesystem if it is encrypted? And 
the kernel lacks the capability to ask you for the password.



Anyway, I don't want to encrypt all discs on my Linux server for


Well, server may be a special case.


numerous compelling reasons, and I'd rather not have a LUKS root
filesystem on my Linux laptops, either.


Well, I want it. First, you can have keys in /etc for VPN for example.  
Second I don’t want to think about which partions are „safe”.


Besides if your disc controler dies you can’t easily delete the data. If 
everything is encrypted you can simply through away the disc.


Many greetings,

Stephan

--
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[Rick Moen]

Quoting Stephan Seitz (stse+dev...@fsing.rootsland.net):

> On Di, Jun 27, 2017 at 10:57:16 -0700, Rick Moen wrote:
> >Step 1.  Compile a kernel that includes inline all key drivers including
> >those needed to find the root filesystem.
> >Step 2.  Profit!
> >That's the old-school method.
> 
> Yes, and this will not work with new-school methods like disc
> encryption because something needs to ask you for the password.
> 
> And today you should always encrypt your discs.

What exactly about LUKS is incompatible with use of a kernel compiled to 
include all key drivers including those to find the root filesystem
(thus eliminating a dependency on initrds)?  Nothing in
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system
appears to absolutely require an initrd, for key storage or anything
else.

Anyway, I don't want to encrypt all discs on my Linux server for
numerous compelling reasons, and I'd rather not have a LUKS root
filesystem on my Linux laptops, either.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[Stephan Seitz]

On Di, Jun 27, 2017 at 10:57:16 -0700, Rick Moen wrote:

Step 1.  Compile a kernel that includes inline all key drivers including
those needed to find the root filesystem.
Step 2.  Profit!
That's the old-school method.


Yes, and this will not work with new-school methods like disc encryption 
because something needs to ask you for the password.


And today you should always encrypt your discs.

Many greetings,

Stephan

--
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[Rick Moen]

Quoting k...@aspodata.se (k...@aspodata.se):

> And that works when the root filesystem is on a device with fixed major/
> minor number, e.g. /dev/sda2 /dev/hda1, and even /dev/md1 for md 
> devices with the old (0.90) format superblock if they are auto-assebled.
> It doesn't work for devices with dynamic device numbers.

Yeah, I don't use Linux systems where that is an issue.  I.e., USB mass
storage gets used only for ancillary removable storage that doesn't have
or need fixed mountpoints.  (But if I did want my removable 2TB backup
drive in /etc/fstab, it could be referenced in /etc/fstab by disk label
or UUID.  I merely prefer to avoid those ugly solutions, but they do
exist.  Currently, it might be /dev/sdd1 or /dev/sde1 depending on
runtime events, but that's not an actual problem:  I look in dmesg |
tail, see what it got recognised as, and mount / umount that.)

> Just be shure that e.g. /dev/sda2 points to the right disk if you have
> more than one, and ohh, don't compile in usb-storage and accidentally
> leave an usb-stick connected while rebooting, it could show up as
> /dev/sda.

The latter never, literally never, happens on any system of my
experience where the main storage is SAS or SATA (or PATA or old SCSI,
or ESDI or RLL or MFM...).  I keep hearing people warn about that, but
it doesn't appear to happen.  USB-attached mass storage gets assigned 
device nodes later in the alphabet.  

If I ever see it happen, I'll deal with that then, but it's been decades
now since people like Greg Kroah-Hartman (udev guy) and countless others
kept claiming this would be a problem, and I have yet to see it happen
at all, let alone on any system I admin.


> My impression is that the kernel is going in the direction where the
> old-school method is harder to do simply because the kernel devs
> doesn't care about it, but you can counter that by keeping things
> simple, if you wish.

As it happens, I do so wish.

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

Re: [DNG] some ASCII issues

[Adam Sampson]

k...@aspodata.se writes:

> And that works when the root filesystem is on a device with fixed
> major/ minor number [...] It doesn't work for devices with dynamic
> device numbers.

That used to be true, but it's improved quite a bit in recent
years. Since 2.6.37 (2011), the kernel lets you specify a partition in a
GPT partition table by UUID:

  root=PARTUUID=39a734b6-4068-4ee7-8f6f-b6248588af37

And since 3.8 (2013) you can specify a partition in a regular MS-DOS
partition table by disk ID and partition number:

  root=PARTUUID=e50b843a-01

This is really handy when you're using dynamically-numbered devices and
don't otherwise need an initramfs (e.g. root on a USB stick, in
combination with rootwait).

See name_to_dev_t in init/do_mounts.c for the full details:
http://elixir.free-electrons.com/linux/v4.11.7/source/init/do_mounts.c#L182

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

Re: [DNG] some ASCII issues

[karl]

Rick Moen:
> Quoting John Morris (jmor...@beau.org):
> 
> > Nope, that negates one of the principle reasons to use an initramfs in
> > the first place.  You assume the stock kernel can see the drive where
> > you intend to put this new partition; one of the big drivers of initrd
> > in the first place was exotic hardware, etc. so GRUB uses BIOS
> > (including extension ROMs on controller cards) to load both the kernel
> > and the initrd so it can take whatever steps are needed, i.e load the
> > right modules, start lvm, setup encrypted filesystem magic, etc. to make
> > the main drive/partitions/etc. visible.  Your idea could deal with most
> > everything that didn't need a kernel module but totally fails at that
> > task.
> 
> Step 1.  Compile a kernel that includes inline all key drivers including
>  those needed to find the root filesystem.
> Step 2.  Profit!
> 
> That's the old-school method.

And that works when the root filesystem is on a device with fixed major/
minor number, e.g. /dev/sda2 /dev/hda1, and even /dev/md1 for md 
devices with the old (0.90) format superblock if they are auto-assebled.
It doesn't work for devices with dynamic device numbers.

Just be shure that e.g. /dev/sda2 points to the right disk if you have
more than one, and ohh, don't compile in usb-storage and accidentally
leave an usb-stick connected while rebooting, it could show up as
/dev/sda.

My impression is that the kernel is going in the direction where the
old-school method is harder to do simply because the kernel devs
doesn't care about it, but you can counter that by keeping things
simple, if you wish.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57


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

Re: [DNG] some ASCII issues

[Didier Kryn]

Le 28/06/2017 à 07:47, John Morris a écrit :

On Sat, 2017-06-24 at 11:08 +0200, Didier Kryn wrote:


  Anyway I think there's a simple method to live without the
initramfs. Everything which is done from initramfs could be done the
same way from a disk partition, which might make it easier to debug:
have a /os directory containing all the necessary subdirs, /os/proc,
/os/sys, /os/dev, /os/run /os/usr, /os/lib, /os/var, /os/home... , mount
the first five, create the few necessary files and symlinks and
switch_root() to /os. This is exactly what your initramfs does.

Nope, that negates one of the principle reasons to use an initramfs in
the first place.  You assume the stock kernel can see the drive where
you intend to put this new partition; one of the big drivers of initrd
in the first place was exotic hardware, etc. so GRUB uses BIOS
(including extension ROMs on controller cards) to load both the kernel
and the initrd so it can take whatever steps are needed, i.e load the
right modules, start lvm, setup encrypted filesystem magic, etc. to make
the main drive/partitions/etc. visible.  Your idea could deal with most
everything that didn't need a kernel module but totally fails at that
task.


Now you've found another corner case:

"Grub doesn't know your hardware" AND " You refuse to use a 
proposed workaround"


Everyone has to live with one's own contradictions :-) . And this 
case has no relation with the /usr merge.


Didier


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

Re: [DNG] some ASCII issues

[Rick Moen]

Quoting John Morris (jmor...@beau.org):

> Nope, that negates one of the principle reasons to use an initramfs in
> the first place.  You assume the stock kernel can see the drive where
> you intend to put this new partition; one of the big drivers of initrd
> in the first place was exotic hardware, etc. so GRUB uses BIOS
> (including extension ROMs on controller cards) to load both the kernel
> and the initrd so it can take whatever steps are needed, i.e load the
> right modules, start lvm, setup encrypted filesystem magic, etc. to make
> the main drive/partitions/etc. visible.  Your idea could deal with most
> everything that didn't need a kernel module but totally fails at that
> task.

Step 1.  Compile a kernel that includes inline all key drivers including
 those needed to find the root filesystem.
Step 2.  Profit!

That's the old-school method.

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

Re: [DNG] some ASCII issues

[John Morris]

On Sat, 2017-06-24 at 11:08 +0200, Didier Kryn wrote:

>  Anyway I think there's a simple method to live without the 
> initramfs. Everything which is done from initramfs could be done the 
> same way from a disk partition, which might make it easier to debug: 
> have a /os directory containing all the necessary subdirs, /os/proc, 
> /os/sys, /os/dev, /os/run /os/usr, /os/lib, /os/var, /os/home... , mount 
> the first five, create the few necessary files and symlinks and 
> switch_root() to /os. This is exactly what your initramfs does.

Nope, that negates one of the principle reasons to use an initramfs in
the first place.  You assume the stock kernel can see the drive where
you intend to put this new partition; one of the big drivers of initrd
in the first place was exotic hardware, etc. so GRUB uses BIOS
(including extension ROMs on controller cards) to load both the kernel
and the initrd so it can take whatever steps are needed, i.e load the
right modules, start lvm, setup encrypted filesystem magic, etc. to make
the main drive/partitions/etc. visible.  Your idea could deal with most
everything that didn't need a kernel module but totally fails at that
task.


signature.asc
Description: This is a digitally signed message part
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[John Morris]

On Sat, 2017-06-24 at 11:04 -0500, Don Wright wrote:

> Just teleport into the datacenter on the other side of the planet, or the
> office building where your after-hours key card doesn't work because all
> cards were cancelled following the alleged burglary last week*, or do some
> other Herculean task, and insert that healing potion.

One acronym.  IPMI.  When it is truly important, use real server
hardware designed to be remotely managed.  In a worst case scenario like
you describe you might need a Windows PC on your end to use the full
featured vendor supplied IPMI client tools that let you remote mount a
USB stick or CD to a machine but it can do it.  Of course now they are
pushing the almost entirely closed Intel AMT stuff.  Bleh.


signature.asc
Description: This is a digitally signed message part
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[Didier Kryn]

Le 24/06/2017 à 03:08, Steve Litt a écrit :

Think initramfs systems are cheap and easy? Making a working one
manually is tough: I've done it. And even using tools like dracut and
initramfs-tools is difficult and error prone.


Never used any tool for that. I crafted some initramfs and did it 
"manually" by building a static Busybox and recompiling the kernel with 
the proper options and the initramfs.conf file method. It is 
time-consuming if you're not skilled in scripting, which is my case, but 
you can insert the possibility of an interactive session in the 
initramfs, which eases debugging. Done like this, initramfs isn't a 
black box anymore. I wouldn't try to hack the initramfs of the distro; 
either use it as it is or craft my own.


We are really talking of a corner case: one side of the corner is 
that you don't want initramfs; the other side is that you want to mount 
/usr separately. What's the reason for the last?


As soon as you have /bin, /sbin and /lib, mounting /usr on a 
different partition for the purpose of sharing or snapshotting the OS 
doesn' work, because it would be only a part of the OS, which doesn't 
seem wise. What other reason? Size and access time of the filesystem 
seem both historical. Any other?


Anyway I think there's a simple method to live without the 
initramfs. Everything which is done from initramfs could be done the 
same way from a disk partition, which might make it easier to debug: 
have a /os directory containing all the necessary subdirs, /os/proc, 
/os/sys, /os/dev, /os/run /os/usr, /os/lib, /os/var, /os/home... , mount 
the first five, create the few necessary files and symlinks and 
switch_root() to /os. This is exactly what your initramfs does.


Didier


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

Re: [DNG] some ASCII issues

[Steve Litt]

On Fri, 23 Jun 2017 18:55:57 -0500
John Morris  wrote:

> On Fri, 2017-06-23 at 16:41 +0200, Antony Stone wrote:
> 
> > https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
> > if you want to start feeling annoyed as well as surprised.  
> 
> Dunno, that one actually makes a lot of sense.  Applying the logic of
> Chesterton's Fence here seems sound.  They did their homework in
> researching the original reason for the tradition, carefully examined
> the question of whether those reasons still apply and the consequences
> of the change.

And then they ignored the original reasons, and spewed talking points.


> 
> The original reason no longer applies, we should all agree on that
> point, right?  

Not in the slightest. I'd love to boot without initramfs, which is a
black box that's hard to look around in. If I want to mount /usr on a
non root partition, and not use an initramfs, I'd need to actually
prepopulate /sbin and /bin, which would later get mounted over.

Think initramfs systems are cheap and easy? Making a working one
manually is tough: I've done it. And even using tools like dracut and
initramfs-tools is difficult and error prone.

You haven't lived until your boot fails in initramfs. Good luck trying
to get a voltmeter probe anywhere to measure. You're lucky to have a
virtual terminal to work with, and most of your Linux tools aren't
available.

> We don't NEED to install on a small volume and then
> mount the large stuff on a different media, even when we install /usr
> on a different filesystem it is almost always a partition on the same
> physical device.  

I haven't seen statistics on this.

> So then we only have the question of whether it is
> best to put everything down /usr or eliminate it.  The arguments they
> advance for snapshotting, using a read-only mount or network share of
> pretty much the entire non-host specific portion of the OS is a pretty
> good reason to pick putting everything down /usr.  Counterarguments
> are few.
> 
> If you don't want to use an initrd, just avoid making /usr a
> mountpoint. 

If you say so.

> As for rescue, in the before time when the /usr split
> occurred, cheap live CD/USB stick rescue media was not an option.  It
> is now.

In
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/,
take a look at myth 10: Split without initramfs hasn't worked for some
time. The supply a link at
https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/,
which lists the software that hasn't worked with split and sans
initramfs for a long time. It reads like a who's-who of
freedesktop/systemd/redhat software. Of course it hasn't worked: They
broke it.

Note myth 9. In "debunking" that myth, they state that Fedora's root
partition is bloated. Well of course it is: It's fedora.

Look carefully at myth 5 and its rebuttal. They make the point that
although the split might make life harder on  distributions and
upstreams, once the majority of distributions and upstreams have
adopted it, maintaining the merge will be less difficult than not
maintaining the merge in a world of merged systems. Read it very
carefully: What they really say in that paragraph is "we've sabotaged
everyone."

I've got bigger fish to fry, but don't ever think Freedesktop.Org did
us a favor with the merge, or that they didn't do it out of a
redhat-centric agenda.

SteveT

Steve Litt 
June 2017 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[Rick Moen]

Quoting John Morris (jmor...@beau.org):

> Dunno, that one actually makes a lot of sense.

At minimum, it's definitely not something to get religious over, so
nobody should be hyperventilating over it.


> The original reason no longer applies, we should all agree on that
> point, right?

Sure.  Rob Landley's historical recounting should be sufficient
refutation of any claim that the /usr split was originally for
well-thought-out and persistently important reasons.
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html


> We don't NEED to install on a small volume and then mount
> the large stuff on a different media, even when we install /usr on a
> different filesystem it is almost always a partition on the same
> physical device. 

Nope, we don't _need_ to.  

However, even in case of the rootfs and a separate /usr filesystem being
on the same physical device, that doesn't mean there cannot be reasons
for separate /usr that the local admin considers compelling.


> The arguments they advance for snapshotting, using a read-only mount
> or network share of pretty much the entire non-host specific portion
> of the OS is a pretty good reason to pick putting everything down
> /usr.

Those goofballs talk about 'sharing the operating system over the
network' and 'a read-only export of the vendor supplied OS to the
network, which will contain almost the entire operating system
resources' because they have absolutely no clue about security -- one of
the several individually compelling reasons to be suspicious of their
advice.  And there's nothing about separate /usr that prevents use of
lvcreate or similar snapshotting if you wish to use that:  Their 
allegation to the contrary seems... unexplained.  I might be missing
something, so, if you know what they're referring to, I'd appreciate
hearing what.


> If you don't want to use an initrd, just avoid making /usr a mountpoint.

Can certainly be done, but suppose you want the functional advantages of
separate /usr?  ;->  (Oh, you assumed there aren't any.  Well, there's
your problem, then.)

Separate /usr is one of several measures I take to help guard against a
variety of mishap.  For one thing, it then becomes possible to give /usr
custom mount options, including the one that makes it normally
read-only.[1]  (I have hooks to apt/dpkg to automatically remount as
required for apt operations.  See this Anthony Towns post for details:
https://lists.debian.org/debian-devel/2001/11/msg00212.html )

The aims of my partitioning strategy include getting everything feasible
off the root filesystem to keep it small and fairly static.  This in
general terms keeps it far less likely to suffer mishap that includes
but is not limited to hitting 100% full or getting filesystem damage in
various ways.  The rootfs having this passive protection against most
forms of damage means that crucial tools needed for recovery or restore
operations _or_ filesytem repair of other filesystems are highly likely
to be available without needing to resort to CD/DVD images, USB key
drives, or PXE-booting a recovery image.  That's not everything, but
it's certainly a great deal more than nothing.

As a point of possible tangential interest, I use custom mount options
on several filesystems as a belt-and-suspenders security assist in some
cases, and to gain small performance advantages in others:

/usr  nodev,ro
/var/lib  nodev
/var  noatime,nodev,nosuid
/var/www  nodev,nosuid

What I mean by 'belt-and-suspenders security assist' is:  Suppose some
process is somehow caused to run that attempts to do system harm.
Almost all such attack tools are automated and tend to be a bit brittle, 
and it's conceivable that disallowing special files ('nodev') in a file
tree where they should never be present might cause the attack script to 
fail.  Likewise nosuid in trees where there should never legitimately be
an executable with the SUID property.

The 'noatime' on /var is of course for performance.  (As always, one
must make sure nothing in that filesystem is going to need atime
time-stamping.

Anyway, I have no problem with the Freedesktop.org kiddies deciding that
my sysadmin use-case doesn't exist or should be ignored, because I can
work around their opinions and set my own local policy and practices.
So, we both get to be happy.


[1] This helps prevent accidental sysadmin-caused damage to the sytem
trees.  It's proverbial that the biggest threat to the typical Unix
system is the root user.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[John Morris]

On Fri, 2017-06-23 at 16:41 +0200, Antony Stone wrote:

> https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ if 
> you want to start feeling annoyed as well as surprised.

Dunno, that one actually makes a lot of sense.  Applying the logic of
Chesterton's Fence here seems sound.  They did their homework in
researching the original reason for the tradition, carefully examined
the question of whether those reasons still apply and the consequences
of the change.

The original reason no longer applies, we should all agree on that
point, right?  We don't NEED to install on a small volume and then mount
the large stuff on a different media, even when we install /usr on a
different filesystem it is almost always a partition on the same
physical device.  So then we only have the question of whether it is
best to put everything down /usr or eliminate it.  The arguments they
advance for snapshotting, using a read-only mount or network share of
pretty much the entire non-host specific portion of the OS is a pretty
good reason to pick putting everything down /usr.  Counterarguments are
few.

If you don't want to use an initrd, just avoid making /usr a mountpoint.
As for rescue, in the before time when the /usr split occurred, cheap
live CD/USB stick rescue media was not an option.  It is now.


signature.asc
Description: This is a digitally signed message part
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[Rick Moen]

Quoting k...@aspodata.se (k...@aspodata.se):

> I usually don't use initrd/initramfs so I don't like that merge.
> Also I want to have the ability to unmounting /usr if I would whish.
> 
> If it is to make all binaries to be accessible as /usr/bin/whatever,
> one could make links from /usr/bin/ to /bin for binaries in /bin
> instead of moving the binary itself and then linking.

Consider statically compiling any recovery / backup / maintenance
utilities required to work in /bin and /sbin even if /usr isn't mounted.  
You might otherwise be unpleasantly surprised by items that fail to work
because of dynamic dependencies to libs inside /usr.

I've been pondering this matter for a while ever since the UsrMerge
notion and the Freedesktop.org kiddies'  ritualised talking points (like
'Most distributions rely on initrds anyway...', 'Booting without /usr
is broken', and 'PulseAudio, NetworkManager, and udisks2 would break').
As someone who prefers to be able to maintain a simple small-rootfs
server system without initrd-dependency if he wishes to, I find that the
correct solution is to ensure that tools that _need_ to be in /bin and
/sbin (because they need to work without /usr) truly _do_ work without
/usr.  And IMO the best way to ensure that is just compile them as
statically linked binaries.

(Want them packaged?  Cool, create a mountutils-static package, etc.)

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

Re: [DNG] some ASCII issues

[karl]

Didier:
> Le 23/06/2017 à 16:41, Antony Stone a écrit :
> > On Friday 23 June 2017 at 16:06:52, Jaromil wrote:
> >> On Thu, 22 Jun 2017, Hendrik Boom wrote:
> >>> Could that be a side effect of debian/systemd's fusion of /usr with /?
> >> ?!?!?! did they ?!?!?!
> >> how is this madness done, via mount -o bind 
> > https://wiki.debian.org/UsrMerge
> >> Nevermind if its old news already, I am blown away by this news...
> > https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ if
> > you want to start feeling annoyed as well as surprised.
>  There are many advantages in this merge, but there is also a 
> drawback, which,I think, is the only one: it becomes tricky to boot with 
> /usr being a mountpoint AND without an initrd/initramfs. This is a 
> corner case, which doesn't mean it is negigible.

I usually don't use initrd/initramfs so I don't like that merge.
Also I want to have the ability to unmounting /usr if I would whish.

If it is to make all binaries to be accessible as /usr/bin/whatever,
one could make links from /usr/bin/ to /bin for binaries in /bin
instead of moving the binary itself and then linking.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57


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

Re: [DNG] some ASCII issues

[Didier Kryn]

Le 23/06/2017 à 16:41, Antony Stone a écrit :

On Friday 23 June 2017 at 16:06:52, Jaromil wrote:


On Thu, 22 Jun 2017, Hendrik Boom wrote:

Could that be a side effect of debian/systemd's fusion of /usr with /?

?!?!?! did they ?!?!?!

how is this madness done, via mount -o bind 

https://wiki.debian.org/UsrMerge


Nevermind if its old news already, I am blown away by this news...

https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ if
you want to start feeling annoyed as well as surprised.



There are many advantages in this merge, but there is also a 
drawback, which,I think, is the only one: it becomes tricky to boot with 
/usr being a mountpoint AND without an initrd/initramfs. This is a 
corner case, which doesn't mean it is negigible.


Didier

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

Re: [DNG] some ASCII issues

[Antony Stone]

On Friday 23 June 2017 at 16:06:52, Jaromil wrote:

> On Thu, 22 Jun 2017, Hendrik Boom wrote:
> > 
> > Could that be a side effect of debian/systemd's fusion of /usr with /?
> 
> ?!?!?! did they ?!?!?!
> 
> how is this madness done, via mount -o bind 

https://wiki.debian.org/UsrMerge

> Nevermind if its old news already, I am blown away by this news...

https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ if 
you want to start feeling annoyed as well as surprised.


Antony.

-- 
RTFM may be the appropriate reply, but please specify exactly which FM to R.

   Please reply to the list;
 please *don't* CC me.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues, dng 33/49/#2,#3

[Gary Olzeke]

bash/nano all seems to be working fine now
didn't make any changes - afaik
these are my $PATHs:(all stock install)
olzeke51@devASCII:~/Desktop$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
root@devASCII:~# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
'
Thanx - gz
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[Jaromil]

On Thu, 22 Jun 2017, Hendrik Boom wrote:

> On Thu, Jun 22, 2017 at 05:02:54PM -0400, Gary Olzeke wrote:
> > bash couldn't find 'nano' (I wanted to copy the 'sandbox' message)
> > bash was looking in /usr/bin/nano - it was at /bin/nano [per 'which'
> > command]
> 
> Could that be a side effect of debian/systemd's fusion of /usr with /?


?!?!?! did they ?!?!?!

how is this madness done, via mount -o bind 

Nevermind if its old news already, I am blown away by this news...

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

Re: [DNG] some ASCII issues

[fsmithred]

On 06/22/2017 08:44 PM, Hendrik Boom wrote:
> On Thu, Jun 22, 2017 at 05:02:54PM -0400, Gary Olzeke wrote:
>> bash couldn't find 'nano' (I wanted to copy the 'sandbox' message)
>> bash was looking in /usr/bin/nano - it was at /bin/nano [per 'which'
>> command]
> 
> Could that be a side effect of debian/systemd's fusion of /usr with /?
> 

I believe it is. I ran into that when I was playing with sid over a year
ago and had to change a couple of my scripts to work with it. Maybe we
should just put all files in / so they'd be easier to find.  ;)

Oh, it gets even better. I've got /bin/nano in an upgrade to ascii, and
I've got both /bin/nano and /usr/bin/nano in an ascii live iso I just made
with live-sdk. No symlinks. Actual files. Same version in all cases (2.7.4).

Gary, do you not have /bin in your path?
echo $PATH

-fsr




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

Re: [DNG] some ASCII issues

[Hendrik Boom]

On Thu, Jun 22, 2017 at 05:02:54PM -0400, Gary Olzeke wrote:
> bash couldn't find 'nano' (I wanted to copy the 'sandbox' message)
> bash was looking in /usr/bin/nano - it was at /bin/nano [per 'which'
> command]

Could that be a side effect of debian/systemd's fusion of /usr with /?

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

Re: [DNG] some ASCII issues

[Jaromil]

dear Gary

On Thu, 22 Jun 2017, Gary Olzeke wrote:

>recently did an ASCII upgrade from the CD install Jessie 1.0-0 64 bit
>(see my ASCII-install_notes on [1]dev1galaxy.org forum)

hearing from multi/media issues just makes me think dyne:bolic will be
totally fine with good old jack1 and qjackctl...

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