Re: [DNG] Devuan Jessie + Huawei USB modems

[Miroslav Skoric]

On 11/28/18 2:53 PM, ael wrote:



I just dug out one of my old dongles and plugged it into a debian
testing laptop.

The mode switch seems to be automatic, which is what I remembered, and
someone else said had been true of recent kernels.

Here is an extract from dmesg:


Very good. Will test it next time I go to the club. Tnx!

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

Re: [DNG] Devuan Jessie + Huawei USB modems

[Miroslav Skoric]

On 11/28/18 11:41 AM, Rick Moen wrote:



I haven't read any of those in detail.  I just wanted to illustrate that
you can find _possibly_ promising coverage of Linux support for, e.g.,
the Huawei E3372 by Web-searching for 'Huawei E3372 Linux' (and then, of
course, favouring more-clueful sites among search hits, e.g., the Arch
Linux wiki, Stack Exchange, etc.



Sure, will search in days to come. I asked in this list after supposing 
that someone might have already tried some of those modems in Devuan.

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

Re: [DNG] Devuan Jessie + Huawei USB modems

[Miroslav Skoric]

On 11/27/18 8:08 PM, info at smallinnovations dot nl wrote:


__


It is a while ago that I struggled with a USB modem but your device
should be recognized by your system (supported since 2.6.18).

A old bug i found was that usbstorage is too fast for usbswitch. The
remedy would be to create a file /etc/modprobe.d/usb-storage.conf:

options usb-storage delay_use=3


or a higher number.



Ok, will try that next week. Tnx!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 29/11/18 at 18:19, Roger Leigh wrote:


> If you're a ZFS user


  Yeah, that's it.


-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




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

Re: [DNG] Participate to the first Devuan Conference in Amsterdam!

[Linux O'Beardly]

Just to clarify, I live in a state called Tennessee, and I have a southern
drawl as well, however, most folks on the Devuan team have spoken to me
over video chat and I'm apparently comprehensible.

Airfare from where I live, in the Knoxville, TN, USA area, to Europe is
usually between $1400-2300 USD.  However, due to the fact the VUA has given
us plenty of forewarning, I've found flights out of Atlanta, which is about
a 4 hour drive, for around $650, which for my current situation is
reasonable.

SteveT - I don't have 6 children, but I do have 3, 19 year old identical
twin daughters, and a 7 month old baby boy.  You may see him here:
https://www.instagram.com/linux.obeardly/

Thanks to everyone for all the great feedback.

*Linux O'Beardly*
linux.obear...@gmail.com
http://o.beard.ly


On Thu, Nov 29, 2018 at 4:59 PM Rick Moen  wrote:

> [/me nervously looks around for the listadmins before messing around
> being off-topic]
>
> Quoting Simon Hobson (li...@thehobsons.co.uk):
>
> > And if we find ourselves talking to a call centre in Glasgow - well
> > that's worse than the ones in India :D
>
> Glaswegian's delightful, though, even though there's a learning curve.
> Following amusing clip _slightly_ exaggerates it for comic effect:
>
> http://www.loopinsight.com/2012/02/02/apple-scotland-having-a-wee-bit-of-trouble/
>
> Circa 1978, I found myself on the Flying Scotsman (British Rail - R.I.P.)
> express train from King's Cross station, London, to Edinburgh, in a
> compartment with a teenager from Tryon, North Carolina and a thorougly
> drunk Scot.  FWIW, I found the soused Scot's brogue easier to parse
> than the displaced Southerner's drawl.
>
> ___
> 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] The Blackbird - An owner controlled, open source firmware system on the POWER ppc64/ppc64le arch - a less expensive mATX TALOS 2

[Hendrik Boom]

On Thu, Nov 29, 2018 at 04:26:23PM -0500, taii...@gmx.com wrote:
> This is a much less expensive mATX variant of the TALOS 2 from the same
> people.
> 
> It runs both little and big endian so both ppc64 and ppc64le and
> supports POWER-KVM/POWER-IOMMU/IOMMU-GFX for DMA protection and to
> attach PCI-e devices to VM's including PCI-e graphics devices[3]
> 
> https://www.phoronix.com/scan.php?page=news_item=Blackbird-POWER9-Pre-Orders
> https://raptorcs.com/content/BK1B01/intro.html
> https://wiki.raptorcs.com/wiki/Blackbird
> 
> The only binary blob is the onboard NIC firmware[1], otherwise it is
> fully open source, has a variety of end-user available documentation[4]
> and has no hardware code signing enforcement so it is entirely yours to
> own unlike modern x86 stuff which can't ever be free[2] and has the
> impossible to disable ME/PSP doing god knows what.
> 
> OpenPOWER9 CPU's are Made in USA and the board is Made in the USA from
> US and (probably) foreign components so it is much more trustworthy.
> 
> In terms of speed POWER9 is superior to the offerings from intel/amd or
> equivilant when compared without x86's spectre/meltdown protections
> enabled as intel most of the time disables them with their public CPU
> benchmarks.
> 
> [1]The Broadcom NIC was the best alternative to using an intel nic as
> there is a large amount of documentation available, people are working
> on freeing it and the first one to do so gets a free TALOS 2 workstation
> worth 5K. Intel is considered a competitor so buying their networking
> ASIC's supports them and thus further anti-feature development - there
> is also the possibility of undocumented dangerous ME style features in
> the silicon mask rom.
> 
> [2]New x86 hardware has none of the documentation published that is
> required to write firmware and it has a variety of black boxes like
> ME/PSP, boot guard etc designed to prevent you from owning and
> controlling your hardware.
> 
> [3]They recommend the using the Radeon Pro WX31xx/41xx/51xx/71xx
> graphics cards series as they work the best with POWER - nvidia hates
> linux and tries time and again to break IOMMU-GFX on geforce cards
> requiring work arounds.
> 
> [4]IBM provides to the public all the documents one would need to make
> their own POWER firmware and do various other things - more
> documentation is available for OpenPOWER members or by request.
> 
> It really blows my mind that IBM of all companies is the one to save
> computing freedom - POWER is now the only owner controlled high
> performance CPU arch.

Reminds me of the old days when you could reprogram an IBM 360 to do 
just about anything you wanted, and IBM would give you the information 
you needed.

People developig the MTS time-sharing system (the one that actually 
worked efficiently on the 360/67) even got IBM to implement custom 
instructions for OS efficiency.

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

Re: [DNG] /usr to merge or not to merge... that is the question

[Adam Borowski]

On Thu, Nov 29, 2018 at 04:40:52PM -0500, Hendrik Boom wrote:
> On Thu, Nov 29, 2018 at 01:30:53PM -0800, Rick Moen wrote:
> > 
> > Compiling a kernel locally to include inline essential hardware drivers
> > is so simple I _think_ I could teach even a Republican Party voter how
> > to do it.  ;->
> > 
> > ITYM 'will probably never support without sysadmin manual work to create
> > a bespoke kernel and eliminate local dependency on an initramfs', which,
> > sure, fair enough.  Personally, though, my fingers aren't broken.
> 
> Is there ... could there be with reasonable effort ... a tool that 
> investigates the hardware, figures out what drivers it needs, and 
> compiles a kernel accordingly?
> 
> Perhaps even looks at the file systems that are present?
> 
> Is there something arcane that makes this kind of thing diffcult?

make localyesconfig
make -j`nproc` bindeb-pkg
su -
dpkg -i linux-imagedeb


Perhaps even a Democrat Party voter could do it? ;)


Meow.
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Ivan was a wordly man: born in St. Petersburg, raised in
⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned
⠈⠳⣄ to the city of his birth to die.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Participate to the first Devuan Conference in Amsterdam!

[Rick Moen]

[/me nervously looks around for the listadmins before messing around
being off-topic]

Quoting Simon Hobson (li...@thehobsons.co.uk):

> And if we find ourselves talking to a call centre in Glasgow - well
> that's worse than the ones in India :D

Glaswegian's delightful, though, even though there's a learning curve.
Following amusing clip _slightly_ exaggerates it for comic effect:
http://www.loopinsight.com/2012/02/02/apple-scotland-having-a-wee-bit-of-trouble/

Circa 1978, I found myself on the Flying Scotsman (British Rail - R.I.P.)
express train from King's Cross station, London, to Edinburgh, in a
compartment with a teenager from Tryon, North Carolina and a thorougly
drunk Scot.  FWIW, I found the soused Scot's brogue easier to parse
than the displaced Southerner's drawl.

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

Re: [DNG] Participate to the first Devuan Conference in Amsterdam!

[Rick Moen]

Quoting Jamey Fletcher (ja...@beau.org):

> No, it's because I'm po' - they done repossessed my r and my other o.  To
> be fair, I'm not quite *that* poor - but $350+expenses for five days in
> Amsterdam ($75 a day, I expect?) is pretty much my discretionary spending
> for several months gone, and I've been trying to use that to pay down my
> various debts.  Just the flight alone is half my monthly rent.

Then, for your present situation, indeed that would be a very expensive
luxury.  I hope things improve for you and your household, Jamey.

-- 
Cheers,  "I am a member of a civilization (IAAMOAC).  Step back
Rick Moenfrom anger.  Study how awful our ancestors had it, yet
r...@linuxmafia.com  they struggled to get you here.  Repay them by appreciating
McQ! (4x80)  the civilization you inherited."   -- David Brin
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[Hendrik Boom]

On Thu, Nov 29, 2018 at 01:30:53PM -0800, Rick Moen wrote:
> 
> Compiling a kernel locally to include inline essential hardware drivers
> is so simple I _think_ I could teach even a Republican Party voter how
> to do it.  ;->
> 
> ITYM 'will probably never support without sysadmin manual work to create
> a bespoke kernel and eliminate local dependency on an initramfs', which,
> sure, fair enough.  Personally, though, my fingers aren't broken.

Is there ... could there be with reasonable effort ... a tool that 
investigates the hardware, figures out what drivers it needs, and 
compiles a kernel accordingly?

Perhaps even looks at the file systems that are present?

Is there something arcane that makes this kind of thing diffcult?

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

Re: [DNG] /usr to merge or not to merge... that is the question

[Rick Moen]

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

> On Do, Nov 29, 2018 at 01:22:05 -0500, Steve Litt wrote:
> >My understanding is that Devuan will ask in the fresh installer whether
> >the user wants to merge or not, with the default being no merge. This
> >is fine with me. Do you have a problem with it?
> 
> Nope, but even Devuan will probably never support a separate /usr
^^^
> without mounting it in early boot via initrd.

Compiling a kernel locally to include inline essential hardware drivers
is so simple I _think_ I could teach even a Republican Party voter how
to do it.  ;->

ITYM 'will probably never support without sysadmin manual work to create
a bespoke kernel and eliminate local dependency on an initramfs', which,
sure, fair enough.  Personally, though, my fingers aren't broken.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] The Blackbird - An owner controlled, open source firmware system on the POWER ppc64/ppc64le arch - a less expensive mATX TALOS 2

[taii...@gmx.com]

This is a much less expensive mATX variant of the TALOS 2 from the same
people.

It runs both little and big endian so both ppc64 and ppc64le and
supports POWER-KVM/POWER-IOMMU/IOMMU-GFX for DMA protection and to
attach PCI-e devices to VM's including PCI-e graphics devices[3]

https://www.phoronix.com/scan.php?page=news_item=Blackbird-POWER9-Pre-Orders
https://raptorcs.com/content/BK1B01/intro.html
https://wiki.raptorcs.com/wiki/Blackbird

The only binary blob is the onboard NIC firmware[1], otherwise it is
fully open source, has a variety of end-user available documentation[4]
and has no hardware code signing enforcement so it is entirely yours to
own unlike modern x86 stuff which can't ever be free[2] and has the
impossible to disable ME/PSP doing god knows what.

OpenPOWER9 CPU's are Made in USA and the board is Made in the USA from
US and (probably) foreign components so it is much more trustworthy.

In terms of speed POWER9 is superior to the offerings from intel/amd or
equivilant when compared without x86's spectre/meltdown protections
enabled as intel most of the time disables them with their public CPU
benchmarks.

[1]The Broadcom NIC was the best alternative to using an intel nic as
there is a large amount of documentation available, people are working
on freeing it and the first one to do so gets a free TALOS 2 workstation
worth 5K. Intel is considered a competitor so buying their networking
ASIC's supports them and thus further anti-feature development - there
is also the possibility of undocumented dangerous ME style features in
the silicon mask rom.

[2]New x86 hardware has none of the documentation published that is
required to write firmware and it has a variety of black boxes like
ME/PSP, boot guard etc designed to prevent you from owning and
controlling your hardware.

[3]They recommend the using the Radeon Pro WX31xx/41xx/51xx/71xx
graphics cards series as they work the best with POWER - nvidia hates
linux and tries time and again to break IOMMU-GFX on geforce cards
requiring work arounds.

[4]IBM provides to the public all the documents one would need to make
their own POWER firmware and do various other things - more
documentation is available for OpenPOWER members or by request.

It really blows my mind that IBM of all companies is the one to save
computing freedom - POWER is now the only owner controlled high
performance CPU arch.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request for comments - training room

[Rowland Penny]

On Thu, 29 Nov 2018 16:19:44 -0500
Steve Litt  wrote:

> On Sat, 24 Nov 2018 18:55:03 +
> g4sra  wrote:
> 
> 
> > How should this training room be best implemented for reliability
> > and ease of maintenance ?
> 
> Be sure to tape every cable to the carpet/floor so nobody trips over
> them. Ask the venue for which tape(s) are acceptable.
>  

Do not run cables across the floor (taped down or otherwise), this
would be a trip hazard.

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

Re: [DNG] Request for comments - training room

[Steve Litt]

On Sat, 24 Nov 2018 18:55:03 +
g4sra  wrote:


> How should this training room be best implemented for reliability and
> ease of maintenance ?

Be sure to tape every cable to the carpet/floor so nobody trips over
them. Ask the venue for which tape(s) are acceptable.
 
SteveT

Steve Litt
November 2018 featured book: Manager's Guide to Technical
Troubleshooting Brand new, second edition
http://www.troubleshooters.com/mgr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[Rick Moen]

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

> I do not expect an OS that does not even let you chose on what disk to
> perform the install will let you choose a filesystem layout that is not
> the recommended one, that is LVM across all the available devices.

Yeah, and in agreement with your implication, here, I share your
opinion about a good remedy:

> Solution to this: Boot from Knoppix (yes, seriously) and manually create
> the partitions with parted. Once this was done, rebooted from the RHEL
> image. On the "Installation Destination" submenu I selected "I will
> configure partitioning" and then clicked on the blue Done button.

Exactly like that, except my personal preference as a general 'boot to
this to do most maintenance work' live distro is Siduction (as I
mentioned recently).  They don't always hit their target of a quarterly 
ISO release, but are still (last I checked) releasing pretty frequently,
which means they have pretty cutting-edge hardware drivers, so its
hardware support is about as broad as you could wish for.

But I'd still maybe try the Ctrl-Alt-F2 and try /sbin/fdisk (or parted)
trick in many cases (because of laziness).


Perhaps you'll indulge a moment of my being a proud grandpa, though:
Back in 1999, I was a (minor) member of the group lead by my friend
Duncan MacKinnon at Linuxcare, Inc.  that designed and released the
Linuxcare Bootable Business Card (Linuxcare BBC) just in time for the
first LinuxWorld Conference and Expo in San Jose, at which that 85MB
compressed ISO burned to a business-card-sized CD disc was a hit.  Among
the people who noticed was Klaus Knopper, who intently studied how we
did the pivot_root trick from the initrd to change the root FS to a
RAMdisk.  At the time, this required some tweaks directly to libc.
Anyway, this was the key trick required for live CDs, so Knopper copied
our work to produce Knoppix.

(Some history at:
https://www.revolvy.com/page/Bootable-business-card)

So, basically all of us who invented the Linuxcare BBC feel that we're
in a sense the grandparents of Knoppix and great-grandparents of other 
live CDs that said 'Hey, let's do the Knoppix thing, too.'

(If I've already done that particular humblebrag on Dng, sorry.  You 
get old, you start repeating the same stories a lot.)

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

Re: [DNG] Request for comments - training room

[Carl]

On 11/24/18 1:55 PM, g4sra wrote:


I would appreciate advice on the following situation

I have several hosts of differing architectures or peripherals in a
training room (several training rooms actually but each are independent
of each other) which are supported by a server running the standard *NIX
network services DHCP, BIND etc. The server also has the training
application (which is single install license but multi-user) installed
on it .

How should this training room be best implemented for reliability and
ease of maintenance ?
That is a very general question. You'd have to ask more specific ones to 
get


useful answers. How many nodes? Do you get to spec the hardware or just the
software? Is the hosted application Windows-based? Web-based? Linux-based?
Are these rooms used only for training on that one application, or is the
app a Learning Management System that can launch several different courses?
Are you asking only about server implementation, or also client? Etc.
--
Carl Fink
c...@finknetwork.com

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

Re: [DNG] /usr to merge or not to merge... that is the question

[golinux]

On 2018-11-29 06:14, Hendrik Boom wrote:

On Thu, Nov 29, 2018 at 12:44:35AM -0600, goli...@dyne.org wrote:

On 2018-11-29 00:22, Steve Litt wrote:
>
> My understanding is that Devuan will ask in the fresh installer whether
> the user wants to merge or not, with the default being no merge. This
> is fine with me.
>

I installed a test beowulf mini.iso a few days ago and there was 
indeed an

option to merge.  The default is to keep them separate.

golinux


Great!  It has been tested.

Because that which is not tested is broken.

-- hendrik



Well, that option is clearly in the d-i.  But . . . there are other 
things that still need fixing on beowulf that make the mini.iso 
installation unusable for me.  So we're not out of the woods yet . . .

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

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 28/11/18 at 11:37, Didier Kryn wrote

:
> Le 28/11/2018 à 10:35, Rick Moen a écrit :
>> Quoting Didier Kryn (k...@in2p3.fr):


[...]

>     Hi Rick.
>
>     It seems to me you're fighting to get the last bit of performance
> out of mechanical hard drives, including by using different
> filesystems for different partitions, which makes a lot of sense for
> servers. I agree that filesystem play a major role in performance and
> safety. For the performance of the disks, and considering you speak of
> servers, you ommit to speak of the RAID configuration, which seems to
> me more important than the location of the partitions.

  Different mount options for different parts of the Unix filesystem 
apply also to RAID and LVM metadevices/device-mapper backed
filesystems, too.


>     For what concerns, laptops, I think we are in the era of ssd and,
> unfortunately, there is usually only one disk drive per laptop, except
> of older ones where the cdrom drive can be replaced by a disk.


  So what?  What's wrong in securing the filesystem and optimizing it's
performance even on SSDs, even on laptops, even when one has only one
storage device?
  Besides, an increasing number of people give up on the DVD unit to make room 
for a second HD/SSD installed with an adaptor.

>     Today, servers are probably still the domain of RAIDs based on
> mechanical hard drives, laptops, the domain of ssds, and desktops are
> the place where both live together - I have one desktop like this.


  Server's peculiarities do deserve to be taken into consideration by a 
soi-disant universal OS.  IIRC Debian is used a lot on servers.
  Why do you think ro, nodev, barrier, sync and other mount options do no make 
sense on a RAID/LVM filesystem?


-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




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

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 28/11/18 at 12:11, Didier Kryn wrote:
> Le 28/11/2018 à 11:25, Rick Moen a écrit :
>> Quoting Didier Kryn (k...@in2p3.fr):
>>
>>> Le 28/11/2018 à 08:11, Rick Moen a écrit :
 If I were relying on NFS during early boot, I'd file a bug against
 package
 nfs-common, and also, meanwhile, compile a local-package substitute
 with
 either static binaries or ones linked to libs in /lib (and provide
 those).
>>> Debian supports diskless hosts mounting an NFS filesystem on /.
>> Of course yes.  _But_, what I was commenting on was the dependency on
>> /usr for the NFS mounting utility in /sbin.  That means -- KatolaZ's
>> point -- that /sbin/mount.nfs will not function in the absence of /usr.
>> My answer to KatolaZ amounted to:  Yes, and that's a bug.  I would, if I
>> needed that during early boot (e.g., during maintenance operation, thus
>> needing to be functional even if /usr cannot be mounted), then I would
>> file a bug against mount.nfs and, while awaiting attention to the bug,
>> compile a local replacement.
>>
>>> When using initrd/initramfs, this kernel option is no longer
>>> necessary and I guess it is just simpler to rely on the modules
>>> provided by nfs-common. The motivation is the same as for device
>>> drivers and filesystems: boot a generic kernel, have all modules
>>> available during early boot to mount / (and /usr).
>> But notice that if /usr _is not_ (e.g., cannot be, for some reason)
>> mounted, then you are screwed:  /sbin/mount.nfs breaks.  KatolZ cited
>> that utility's dynamic library dependency on a lib in /usr/lib as a
>> reason why separate /usr is impractical (for systems needing NFS access
>> even if /usr is unavailable).  I replied that, IMO, no, that's a reason
>> why /sbin/mount.nf thus constructed, has a build error.  ;->
>>
>     IIUC, your argument boils down to "depending on /usr for early
> boot is a *bug*", while Roger told us why it has become a *feature* (~:


  Yes, I got it:

From: Roger Leigh 
Message-ID: <147710ba-7cd8-25e2-1d05-4b0f1589e...@codelibre.net>
Date: Fri, 23 Nov 2018 17:01:07 +To: dng@lists.dyne.org

"A separate /usr is no different.  It has a very real cost to support"


  That is, since software devs and packagers have been making a mess of
/ and /usr use, dumping everything together in the same bin makes the
whole system easier to deal with.


  To me it's like saying: "Since most people at home have been doing a
poor job at using different closets to store only their own stuff and
each different closet's drawer to put different kinds of clothing, let's
dump together whatever belongs to anyone in a big chest placed in the
middle of the room.  Let's cal this awful mess a feature and voilà! 
Problem solved!"


  Not.


-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE



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

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 28/11/18 at 12:45, KatolaZ wrote:


[...]


> Unfortunately, most of this thread has been just about "oh look how
> cool MY setup is, oh I went around that, oh I tried this and that, oh
> I want to have /var on a tmpfs, oh I mount /usr over NFS and you
> should try it as well..."  and so on and so forth.


  Yeah, there used to be a time when GNU/Linux allowed sysadmins to
easily customize the filesystem layout for whatever reason, it didn't
stand in the way because what someone chose not to follow the deafults,
or because someone had specific needs that were not taken into account
when the distribution was setup.

  Today this is no longer the case, sadly, Linux is following the path
of proprietary OSes that prevent user's choice in the name of ease of
upstream packagers.  "One size fits all, shut up and fit the mold".


  It's a shame to me that to regain that freedom of choice I hade to
"roll-up my sleeves", fork and maintain packages to undo decisions that
were ill-though of at the start.


> IMHO, this is mostly out of scope, and does not help Devuan improving
> by a single bit. I understand it's hard to appreciate for most of us,
> but putting together a distro is not about catering for the needs of
> just one user: there is an entire world of possibilities outside :)


  "just one user"?  Really?

  We're talking of not taking out choices and freedom to customize and
tinker, i.e. to cater to the needs of entire classes of users, that they
are already here or that they may develop in the future.  GNU/Linux is
just losing in adaptability, potability and customizability, which was
one of the reasons many people switched to it.


-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




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

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 28/11/18 at 12:36, Rick Moen wrote:
> Quoting Didier Kryn (k...@in2p3.fr):
>
>> IIUC, your argument boils down to "depending on /usr for early boot is
>> a *bug*", while Roger told us why it has become a *feature* (~:
> My view, which I expressed in detail prior to Roger joining the thread, 
> is that it's vital to the most vital function of the root filesystem's 
> maintenance software directories (/sbin, /bin, /lib, /lib64) that their 
> binaries function _even_ if /usr is not (or at the moment cannot be)
> mounted -- because the most vital function of those subtrees is backup,
> restore, repair, maintenance (functions that might be required to
> recover/fix /usr).


  I'd like to point out that even in the case /usr was mounted, and even
if it was on the same partition/filesystem as /, it's still very
positive that the system does not come down crashing and burning was
/usr damaged, allowing the superuser to login to see what happened and
attempt to recover the lost data when the system is still online.



-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




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

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 28/11/18 at 11:37, Didier Kryn wrote:
> Le 28/11/2018 à 10:35, Rick Moen a écrit :
>> Quoting Didier Kryn (k...@in2p3.fr):
>>

[...]


>>
>     Hi Rick.
>
>     It seems to me you're fighting to get the last bit of performance
> out of mechanical hard drives, including by using different
> filesystems for different partitions, which makes a lot of sense for
> servers. I agree that filesystem play a major role in performance and
> safety. For the performance of the disks, and considering you speak of
> servers, you ommit to speak of the RAID configuration, which seems to
> me more important than the location of the partitions.


  Different mount options for different parts of the Unix filesystem 
apply also for RAID and LVM metadevices/device-mapper backed
filesystems, too.


>     For what concerns, laptops, I think we are in the era of ssd and,
> unfortunately, there is usually only one disk drive per laptop, except
> of older ones where the cdrom drive can be replaced by a disk.


  So what?  What's wrong in securing the filesystem and optimizing it's
performance even on SSDs, even on laptops, even when one has only one
storage device?


>     Today, servers are probably still the domain of RAIDs based on
> mechanical hard drives, laptops, the domain of ssds, and desktops are
> the place where both live together - I have one desktop like this.


  Do you imply that Debian's decisions regarding filesystem layout do
not take into consideration servers?
  Why do you think ro, nodev, barrier, sync and other mount options do
make sense on a RAID/LVM filesystem?



-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




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

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 28/11/18 at 12:15, Alessandro Selli wrote:
>   Why do you think ro, nodev, barrier, sync and other mount options do
> make sense on a RAID/LVM filesystem?


"... do NOT make sense ..."



-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




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

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 28/11/18 at 11:13, Didier Kryn wrote:
> Le 28/11/2018 à 08:11, Rick Moen a écrit :
>> If I were relying on NFS during early boot, I'd file a bug against
>> package
>> nfs-common, and also, meanwhile, compile a local-package substitute with
>> either static binaries or ones linked to libs in /lib (and provide
>> those).
>
>     Debian supports diskless hosts mounting an NFS filesystem on /.


  This lies outside the case at hand, that was not centered on booting
out of a NFS /.


>     Until the invention of initrd/initramfs, one could use an option
> of the kernel, which allows to link all the NFS client logic
> statically in  the kernel and to pass the mount command arguments
> through the kernel command line.
>
>     When using initrd/initramfs, this kernel option is no longer
> necessary and I guess it is just simpler to rely on the modules
> provided by nfs-common. The motivation is the same as for device
> drivers and filesystems: boot a generic kernel, have all modules
> available during early boot to mount / (and /usr).
>
>         Didier


  This does not address the issue of an NFS binary exec in / that has
libraries in /usr on a system that mounts /usr over an NFS mount
regardless of what the local / is lying on (local disk or network
filesystem).



-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




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

Re: [DNG] merging /tmp

[Alessandro Selli]

On 28/11/18 at 10:02, Rick Moen wrote:
> Swap files were common in Linux systems of the early '90s, but then fell
> out of use because swap partitions has a perfomance advantage.  But
> then, someone found and fixed the performnce gap in the 2000s.  Most
> admins just don't remember the option exists.


  The performance gap was reduced, but not closed (the filesystem layer
still has a say every time the swap is accessed).

  And it adds one more way swapped-out data could be accessed by
(possibly malicious) processes, i.e. accessing the contents of the file
(that's the reason swapon checks the file's permissions and does warn
you if they allow anybody other that the owner to read it).



-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




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

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 28/11/18 at 08:11, Rick Moen wrote:
> Quoting KatolaZ (kato...@freaknet.org):
>
>> # ldd /sbin/mount.nfs | grep "/usr"
>> libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 
>> (0x7f82f53ac000)
>> libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 
>> (0x7f82f52cf000)
>> libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 
>> (0x7f82f529b000)
>> libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 
>> (0x7f82f4fd1000)
>  
> If I were relying on NFS during early boot, I'd file a bug against package
> nfs-common, and also, meanwhile, compile a local-package substitute with
> either static binaries or ones linked to libs in /lib (and provide those).


  I agree.  Everything that sits on / must have it's dynamical libraries
in / too.  Everything under /usr that uses the same libraries will work
correctly, the opposite is not necessarily true.


>> # ldd /sbin/lvscan | grep "/usr"
>> liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
>> (0x7fde00702000)
>>
>> # ldd /sbin/lvs | grep "/usr"
>  liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
> (0x7fd3b7fa1000)
>
> Ditto package lvm2.  (Which FWIW I've avaoided needing.)


  I don't use it for my personal systems, but I do acknowledge LVM is a
boon on servers where the disk/filesystem occupation is hard to predict
at install time or that might see their use change consistently over
time, such a NFS fileserver that at some point it's decided it's going
to double as a mail server too.


>> # ldd /sbin/sysctl | grep "/usr"
>> liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
>> (0x7f3ab7b18000)
> Um, I know of no reason why /sbin/sysctl would be urgently needed in a
> minimal system prior to availability of /usr for purposes of backup,
> restore, system repair, etc.


  I wonder, too.


>  I've never needed to futz with /proc/sys/*
> entries while running in maintenance mode, but, if one did need to do
> so, doing the task using 'echo' is more than sufficient.
>
>> # ldd /sbin/gdisk | grep "/usr"
>> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
>> (0x7f7ddf10f000)
> I haven't yet needed gdisk (& cgdisk, sgdisk, fixparts), having so far
> successfully avoided GPT.


  I always use GPT whenever I can, to take advantage of it's increased
resiliency to accidental damage (that's because it copies it's boot and
partitioning data at the end of the drive).


>  The obvious alternative to gdisk is GNU
> parted (package parted), and FWIW it suffers a similar build boo-boo,
> requiring library libtic.so.5 (terminfo) from inside /usr/lib.  
>
> Tsk-tsk.  ;->


  Agree. 


>> # ldd /bin/kill | grep "/usr"
>> liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
>> (0x7f9f6aa4a000)
>>
>> # ldd /bin/ps | grep "/usr"
>> liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
>> (0x7fd7f6ebc000)
> Yeah, those two are really annoying.  FWIW, my server system has older
> versions of those two utilities that do _not_ have that (IMO) build
> error.  Local packages will be an immediate resort, when/if I hit that.


Package: liblz4-1
Description: Fast LZ compression algorithm library - runtime


   Why on Earth do kill and ps need a "compression algorithm library"?  


>> # ldd /bin/efibootmgr | grep "/usr"
>> libefivar.so.1 => /usr/lib/x86_64-linux-gnu/libefivar.so.1 
>> (0x7f7ed22bd000)
>>  libefiboot.so.1 => /usr/lib/x86_64-linux-gnu/libefiboot.so.1 
>> (0x7f7ed20b)
> As with GPT, I've managed so far to step sideways and successfully evade
> the Second System Effect poster child that is EFI.


  EFI anyway is connected to boot, very early boot actually, and for
this reason it should reside on /.


> I'm also unconvinced that efibootmgr is essential to a 'recovery'
> minimal maintenance system, anyway.  My readings suggest that I would
> want to have a 'EFI stub kernel' configuration where you place an
> (unsigned) kernel binary image in the EFI System Partition and rely on 
> the EFI firmware to boot that kernel and mount the root fs directly
> without needing a bootloader.  Coverage at, among other places:
> https://wiki.gentoo.org/wiki/EFI_stub_kernel 
>
> (As usual, I'm saying this is an example of what would Work for Me[tm].
> What might suit others or some entire abstract group of people is a
> different discussion.)


  Anyway, as I already stated, this has to do with boot, and everything
connected with it should be in / (and /boot).


>> Most of the utilities you would need to debug a problem in mounting a
>> /usr over NFS, or a failing lvm volume, or a scrambled efi partition
>> (some of the use cases somebody mentioned before) need stuff in
>> /usr. 
> This has not been my experience for my own use case (granting your point
> about /bin/kill and /bin/ps as provided in packaged versions I am not
> yet running).  If I encounter that, I will consider that 

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 28/11/18 at 09:08, Rick Moen wrote:
> Quoting Alessandro Selli (alessandrose...@linux.com):
>
>>  Can you name me one distribution other than Red Hat (which in
>> fact is not a desktop-friendly distribution) that does not allow one to
>> "do their own partition setup"?
> I'm curious, Alessandro:  Is RHEL now completely hostile to custom
> filesystem setup?


 I haven't dealt with a RH installation for a looong time, however I did
witness to an incident that happened at a former employer of mine years
ago.  We let a classroom to RH Italy for them to held a course of
theirs.  Of course they had to install the latest RHEL on it's PCs (I
don't remember if it was a RHEL6 or one of the early 7s).  The PCs had a
storage controller that could be operated either in SATA/AHCI or in RAID
mode, the already present Windows installation was using the only HD
present as a plain SATA device.  We installed a second HD on each PC and
told the RH sysadmin who came to prepare the machines to install the
RHEL system only on the second HD, leaving the first one intact (the
Windows installation was needed other classes).  The RH sysadmin first
said "Of course, no problem" and got himself busy with the installation,
but after less than two minutes he went: "Oh shit!".  Before I knew what
had happened I understood at week end I was going to be busy
reinstalling Windows, applications and the courseware material on that
PC.  He then explained me what had happened.  He had never installed
RHEL on such a PC, with a RAID-capable controller with two HDs before,
and he expected the installation program, Anaconda, to ask him on what
disk to perform the install.  Instead Anaconda the very first thing it
did, before he was asked anything about the preferred HD/partitioning
layout, was to automatically put the two HDs in a RAID setup, and went
ahead on it's own setting up RAID metadata and superblocks on them. 
Before he could stop it the Windows disk was made unbootable and had to
be recovered (reinstalled, actually).

  I do not expect an OS that does not even let you chose on what disk to
perform the install will let you choose a filesystem layout that is not
the recommended one, that is LVM across all the available devices.

  However I haven't performed a RHEL installation since RHEL5, and then
my job was to hack the Kickstart files to customize the install process
to the customer's specifications.


>  A long time ago (like maybe RHEL3), Red Hat built
> into its Anaconda installer an ncurses-oriented 'guided' partitioning
> tool that was guilty of both concealing information (suppressed display
> of any extended partition, though logical partitions within it were
> displayed) and also unacceptably overrode the installing admin's
> judgement (e.g., rearranging following its own criteria the filesystems
> to be created).


  Looks like with RHEL7 things have not improved any:


https://www.claudiokuenzler.com/blog/691/custom-partitioning-rhel-red-hat-enterprise-linux-7-setup-installation

Custom partitioning on new Red Hat Enterprise Linux 7 setup


Thursday - Jan 26th 2017 - by Claudio Kuenzler
 - (0 comments)



Unbelieveable how annoying this RHEL 7 installation wizard is! Try to
setup manual partitioning with a mix of primary partitions and logical
volumes - and RHEL will not boot. Even worse: Although I created the
root partition first, somehow the wizard switched it with the swap
partition making swap on /dev/sda1 instead of /dev/sda2 (where I wanted
it to be).

Solution to this: Boot from Knoppix (yes, seriously) and manually create
the partitions with parted. Once this was done, rebooted from the RHEL
image. On the "Installation Destination" submenu I selected "I will
configure partitioning" and then clicked on the blue Done button.


>  First time I encountered the latter misbehaviour, I 
> exercised my vocubulary in several languages on the topics of theology
> and biology,


  LOL!


> further commented 'Sod _this_ for a lark', cancelled out of
> that subscreen, switched to Ctrl-Alt-F2, and used /sbin/fdisk instead.


  That *might* still work, but I wouldn't bet a dime on it.


> Just offhand, I'm betting that a similar approach may still be fruitful,
> though I've not needed to deal with the darned thing in quite a while.
>
> Years later, based partly on that lesson, I started leaning towards a 
> preference for using a best-of-breed live distro for partitioning and
> mkfs'ing all of my filesystems _before_ using the desired distro
> installer.  FWIW, I found the Siduction live CD ideal for this purpose.
> (Siduction is the surviving fork of an innovative distro, Sidux, that 
> was a quarterly CD ISO release based on Debian Sid + stabilisation
> packages.)  

Re: [DNG] Participate to the first Devuan Conference in Amsterdam!

[Simon Hobson]

Adam Borowski  wrote:

>> Walking around Glasgow, you might find
>> the brogue bewildering, but in Amsterdam?  Never.
> 
> There are worse cases.  There's a place called "London", where a sign says
> "Sloane Square" yet the station announcement (by a person paid to have clear
> diction) says "Ten Ske".
> 
> So people in, say, Stockholm, bother to learn English, people in London
> don't.

Ha, yes that is true !

I think it was Jasper Carrot (a brit comedian from Birmingham 
https://en.wikipedia.org/wiki/Jasper_Carrott) who did a gag some years ago 
about how foreigners go to great lengths to learn English - then they come here 
and find that we don't speak it. A significant element of his comedy was maming 
fun of the Birmingham accept (or "Brummy").

And if we find ourselves talking to a call centre in Glasgow - well that's 
worse than the ones in India :D

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

Re: [DNG] efibootmgr and gdisk

[Rick Moen]

[Redirecting back to Dng.  Hope you don't mind.]

Quoting Tom H (tomh0...@gmail.com):

> I've just read your post about /sbin
> 
> https://www.mail-archive.com/dng@lists.dyne.org/msg23646.html
> 
> gdisk: It's become unnecessary as long as fdisk is installed because
> the latter has been able to handle gpt disks for at least 5 years.
> 
> efibootmgr: It's definitely essential if you're running from efi firmware.

Thanks for taking the trouble to tell me that, Tom!  I've not needed to
get into the details of these things, so there are certainly areas
I'm not familiar with.

Also, even though I hold a traditionalist view that a system should
include usable executables in /sbin and /bin able to boot, restore,
recover, and/or repair the system in a 'maintenance' situation where
/usr might not be available (and in general 'single-user mode'
operations where only the root FS is mounted), I try not to be
doctrinaire about these things.  Specifically, I can easily imagine
situations where I might _prefer_ to PXEboot (or boot from flash drive)
a maintenance distro ISO to do repair, recovery, etc.  Because there are
some really nice maintenance distros, and sometimes specialisation wins.

Which is to say it's not a huge tragedy if some of the root FS utilities
don't work without /usr, if only because I might prefer to boot to a
different image for those functions anyway.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[Roger Leigh]

On 24/11/2018 15:08, k...@aspodata.se wrote:

Roger:
...

There's no clean separation between the "base" system and "everything else".

...

I think my urge to have a separate /usr is that I want such a
separation and there isn't a clear other place to have it.


Is there an underlying rationale for why you want this separation?


The other part of the scenario you mentioned here is "doesn't want to
use an initramfs".  Why?

...

I skip initrd to keep the boot setup simple.


I touched on this in another reply with regard to the relative number of 
people testing a separate /usr, but I wanted to come back to this point 
because there's a very important consequence to note here.


It's absolutely true that direct booting without an initrd is simple. 
You're cutting out a relatively large amount of complexity, and you're 
mounting the rootfs directly as a device from the kernel command-line. 
You can't get much simpler than that.


However, there is a cost to bear in mind.  Because this is a relatively 
uncommon usage scenario (most people do use the initramfs since it's the 
default), it's much, much less tested.  There are a lot of special-cases 
in many of the early boot scripts which are only run when direct 
booting, and they are not exercised by the vast majority of systems out 
there.  By choosing to use the least-tested uncommon option, you are 
bearing a certain risk.


The standard initrd generated by initramfs-tools is simply a busybox 
shell, and a few shell scripts.  It also copies in a few tools like udev 
and a fsck for your system if needed.  There is certainly some 
complexity here.  But it's not really all that complicated.  No moreso 
than the early init scripts.  You could read through the scripts in a 
few minutes.  And you can even step through them by hand with the break= 
option on the kernel command-line.



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

Re: [DNG] /usr to merge or not to merge... that is the question

[Roger Leigh]

On 29/11/2018 13:44, Olaf Meeuwissen wrote:

Q: Isn't there some filesystem type that supports settings at a more
  granular level than the device?  Like directory or per file?
A: Eh ... Don't know.  Haven't checked ...
Solution: Go fish!

# I haven't gone fishing yet but a vague recollection of Roger's post
# where he mentioned ZFS seemed promising ...


You could set them at the directory level if you wanted with ZFS, by  
creating a filesystem per directory.  But that might get a bit  
unmanageable, so doing it in a coarser-grained way is usually  
sufficient.  Let me show some examples.


Firstly, this is an example of a FreeBSD 11.2 ZFS NAS with a few  
terabytes of HDD storage.  There's a dedicated system pool, plus this  
data pool:


% zpool status red
  pool: red
 state: ONLINE
  scan: scrub repaired 0 in 4h12m with 0 errors on Wed Nov 28  
19:51:31 2018

config:

NAME STATE READ WRITE CKSUM
red  ONLINE   0 0 0
  mirror-0   ONLINE   0 0 0
gpt/zfs-b1-WCC4M0EYCTAZ  ONLINE   0 0 0
gpt/zfs-b2-WCC4M5PV83PY  ONLINE   0 0 0
  mirror-1   ONLINE   0 0 0
gpt/zfs-b3-WCC4N7FLJD34  ONLINE   0 0 0
gpt/zfs-b4-WCC4N4UDKN8F  ONLINE   0 0 0
logs
  mirror-2   ONLINE   0 0 0
gpt/zfs-a1-B492480446ONLINE   0 0 0
gpt/zfs-a2-B492480406ONLINE   0 0 0

errors: No known data errors

This is arranged as a pair of two mirrors, referenced by GPT labels.  
Each of the mirror "vdev"s is RAID1, and then writes are striped across  
them.  It's not /actually/ striping, it's more clever, and it biases the  
writes to balance throughput and free space across all the vdevs, but  
it's similar.  The last vdev is a "log" device made of a pair of  
mirrored SSDs.  This "ZIL" is basically a fast write cache.  I could  
also have an SSD added as an L2ARC read cache as well, but it's not  
necessary for this system's workload.  No errors have occurred on any of  
the devices in the pool.


All filesystems allocate storage from this pool.  Here's a few:

% zfs list -r red | head -n6
NAME USED  AVAIL  REFER  MOUNTPOINT
red 2.57T  1.82T   104K  /red
red/bhyve872K  1.82T88K  /red/bhyve
red/data 718G  1.82T   712G  /export/data
red/distfiles   11.9G  1.82T  11.8G  /red/distfiles
red/home 285G  1.82T96K  /export/home

There are actually 74 filesystems in this pool!  Because the storage is  
shared, there's no limit on how many you can have.  So unlike  
traditional partitioning, or even LVM (w/o thin pool) it's massively  
more flexible.  You can create, snapshot and destroy datasets on a whim,  
and even delegate administration of parts of the tree to different users  
and groups.  So users could create datasets under their home directory,  
snapshot them and send them to and from other systems.  You can organise  
your data into whatever filesystem structure makes sense.


Let's look at the pool used on the Linux system I'm writing this email on:

% zpool status rpool
  pool: rpool
 state: ONLINE
  scan: scrub repaired 0B in 0h5m with 0 errors on Mon Nov 26  
17:15:55 2018

config:

NAMESTATE READ WRITE CKSUM
rpool   ONLINE   0 0 0
  sda2  ONLINE   0 0 0

errors: No known data errors

This is a single SSD "root pool" for the operating system; with data in  
other pools not shown here.


% zfs list -r rpool
NAME USED  AVAIL  REFER  MOUNTPOINT
rpool   45.4G  62.2G96K  none
rpool/ROOT  14.7G  62.2G96K  none
rpool/ROOT/default  14.7G  62.2G  12.0G  /
rpool/home  3.18M  62.2G96K  none
rpool/home/root 3.08M  62.2G  3.08M  /root
rpool/swap  8.50G  63.2G  7.51G  -
rpool/var   5.72G  62.2G96K  none
rpool/var/cache 5.32G  62.2G  5.18G  /var/cache
rpool/var/log398M  62.2G   394M  /var/log
rpool/var/spool 8.14M  62.2G  8.02M  /var/spool
rpool/var/tmp312K  62.2G   152K  /var/tmp

These datasets comprise the entire operating system (I've omitted some  
third-party software package datasets from rpool/opt).


% zfs list -t snapshot -r rpool
NAME USED  AVAIL  REFER  MOUNTPOINT
rpool@cosmic-post  0B  -96K  -
rpool/ROOT@cosmic-post 0B  -96K  -
rpool/ROOT/default@cosmic-post  2.66G  -  12.3G  -
rpool/home@cosmic-post 0B  -96K  -
rpool/home/root@cosmic-post0B  

Re: [DNG] Participate to the first Devuan Conference in Amsterdam!

[Steve Litt]

On Thu, 29 Nov 2018 09:00:56 -0600
"Jamey Fletcher"  wrote:

> No, it's because I'm po' - they done repossessed my r and my other
> o.  To be fair, I'm not quite *that* poor - but $350+expenses for
> five days in Amsterdam ($75 a day, I expect?) is pretty much my
> discretionary spending for several months gone, and I've been trying
> to use that to pay down my various debts.  Just the flight alone is
> half my monthly rent.

I bet you don't have six children.
 
SteveT

Steve Litt
November 2018 featured book: Manager's Guide to Technical
Troubleshooting Brand new, second edition
http://www.troubleshooters.com/mgr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[Didier Kryn]

Le 28/11/2018 à 16:12, Hendrik Boom a écrit :

On Wed, Nov 28, 2018 at 12:11:25PM +0100, Didier Kryn wrote:


Instead, it
seems /lib has become a holly directory where only the libc and the 
dynamic

linker are allowed to live.

I do *not* mean this sarcastically; I am confused.
Is "holly" a new technical use of an existing English word?
Or is it berely a typo.



    Typo: I meant holy, in the sense other libraries thanthe dynamic 
libc aren't saint enough to stay in this directory. It was intended as a 
form mof humour.


        Didier




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

Re: [DNG] Participate to the first Devuan Conference in Amsterdam!

[Adam Borowski]

On Thu, Nov 29, 2018 at 04:00:03PM +0100, k...@aspodata.se wrote:
> Adam:
> > On Wed, Nov 28, 2018 at 03:03:57PM -0800, Rick Moen wrote:
> > > Also, don't sweat the language thing.  Especially in the
> > > Netherlands where everyone seems to speak English with breathtaking
> > > acuity, you'd have zero problem.  Walking around Glasgow, you might find
> > > the brogue bewildering, but in Amsterdam?  Never.
> > 
> > There are worse cases.  There's a place called "London", where a sign says
> > "Sloane Square" yet the station announcement (by a person paid to have clear
> > diction) says "Ten Ske".
> > 
> > So people in, say, Stockholm, bother to learn English, people in London
> > don't.
> 
> No, we don't learn english here, we learn a mixture of english and
> swedish called swinglish :)

But at least svangelska is understandable (at least to a person from an
European country).

It seems like the language can completely differ even by the next street. 
For example, in Charlottesville (US) people at the university spoke in a way
that's completely fine for me, yet a short way away I needed the fine
point technique to communicate.

But it can go worse.  When I was 18, I wore long hair yet had no beard.  22
years ago no man in the US had long hair -- unlike the Europe where it
wasn't widespread but at least not an oddity, I don't recall seeing _anyone_
at all with long hair.  So in Atlanta, in a public toilet, a guy insisted in
Ebonics that it's the toilet for men.  I didn't manage to explain...


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Ivan was a wordly man: born in St. Petersburg, raised in
⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned
⠈⠳⣄ to the city of his birth to die.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[Steve Litt]

On Thu, 29 Nov 2018 22:44:31 +0900
Olaf Meeuwissen  wrote:

 
> Stephan Seitz writes:
> 
> > Maintainers are encouraged to install everything in /usr because it
> > must be available in early boot.  
> 
> Call me dumb but I totally, completely and utterly fail to understand
> why "Maintainers are *encouraged* to install everything in /usr".

Follow   the   money.
 
SteveT

Steve Litt
November 2018 featured book: Manager's Guide to Technical
Troubleshooting Brand new, second edition
http://www.troubleshooters.com/mgr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[Steve Litt]

On Thu, 29 Nov 2018 13:24:01 +0100
Stephan Seitz  wrote:

> On Do, Nov 29, 2018 at 01:22:05 -0500, Steve Litt wrote:
> >My understanding is that Devuan will ask in the fresh installer
> >whether the user wants to merge or not, with the default being no
> >merge. This is fine with me. Do you have a problem with it?  
> 
> Nope, but even Devuan will probably never support a separate /usr
> without mounting it in early boot via initrd.

If you define "support" as "not prevent", then Devuan already does
support what you say in the preceding sentence. If you define "support"
as "install with the package manager", I don't care about support, and
a heck of a lot of DIY people have the same view I'm expressing.

SteveT

Steve Litt
November 2018 featured book: Manager's Guide to Technical
Troubleshooting Brand new, second edition
http://www.troubleshooters.com/mgr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[Didier Kryn]

Le 29/11/2018 à 14:44, Olaf Meeuwissen a écrit :

  restrictions (think ro/nodev/nosuid) or tune performance (think
  noatime).


    You can mount / with nodev. Except if you absolutely want static 
device files, /dev is now a mountpoint with device files managed either 
by udev/eudev/vdev/mdev, or by the kernel itself.


    Didier


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

Re: [DNG] Participate to the first Devuan Conference in Amsterdam!

[KatolaZ]

On Tue, Nov 27, 2018 at 11:57:21PM +0100, Veteran Unix Admins wrote:
> 
> Dear Init Freedom Lovers,
> 
> On the fourth anniversary of the birth of Devuan,
> once again the Veteran Unix Admins salute you!
> 
> # Participate to the first Devuan Conference in Amsterdam!
> 
> ## From Friday, April 5th through Sunday, April 7th 2019
> 
> # The power of choice
> 

I think I will be there, and I hope to see many D1rs there ;)

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

Re: [DNG] Participate to the first Devuan Conference in Amsterdam!

[Jamey Fletcher]

Quoting  Rick Moen :

> Quoting Jamey Fletcher (ja...@beau.org):

>> Quoting  Rick Moen :

>> I dunno about you, but I would certainly consider $340-500 a "very
>> expensive luxury".

> I suppose it's a matter of perspective.  I often encounter fellow
> Americans who assume it would be far cheaper to go on holiday for five
> days to a domestic city (e.g., San Francisco, NYC) than to five days in
> Amsterdam, because they never bothered to look up how much food and
> lodging costs in SF and NYC relative to Amsterdam.  (Answer: much more
> expensive.  See also:  Miami, Santa Barbara, Boston, Honolulu.)
  [...]
> (I suspect mostly, though, it's just a convoluted way of saying 'This is
> unfamiliar, and I'd rather stay home.  Which, fair enough.)

No, it's because I'm po' - they done repossessed my r and my other o.  To
be fair, I'm not quite *that* poor - but $350+expenses for five days in
Amsterdam ($75 a day, I expect?) is pretty much my discretionary spending
for several months gone, and I've been trying to use that to pay down my
various debts.  Just the flight alone is half my monthly rent.

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

Re: [DNG] Participate to the first Devuan Conference in Amsterdam!

[karl]

Adam:
> On Wed, Nov 28, 2018 at 03:03:57PM -0800, Rick Moen wrote:
> > Also, don't sweat the language thing.  Especially in the
> > Netherlands where everyone seems to speak English with breathtaking
> > acuity, you'd have zero problem.  Walking around Glasgow, you might find
> > the brogue bewildering, but in Amsterdam?  Never.
> 
> There are worse cases.  There's a place called "London", where a sign says
> "Sloane Square" yet the station announcement (by a person paid to have clear
> diction) says "Ten Ske".
> 
> So people in, say, Stockholm, bother to learn English, people in London
> don't.

No, we don't learn english here, we learn a mixture of english and
swedish called swinglish :)

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden


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

Re: [DNG] /usr to merge or not to merge... that is the question

[Roger Leigh]

On 29/11/2018 12:57, k...@aspodata.se wrote:

Roger:
...

Note that to return to the pre-merge policies would be an exercise in
futility.  It was already an exercise in futility back in 2011 because
the number of libraries which /could/ be moved to /lib is an unbounded
set.  There's always another tool which /might/ be required, which pulls
in yet more libraries, and their dependencies, and the dependencies of
their dependencies and so on.  It's a Sisyphean task.


It wouldn't be for a subset of booting setups. It is perfectly possible
for a certain set. If I make a make a kernel package, I can certainly
say that that this package supports direct boot to disk without initrd
and with a separate /usr, with the constraint that it don't support
e.g. lvm and other setups.

Why not agree on a certain set of programs/libs that should be in /bin,
/sbin, and /lib, just to not break my and others packages. That set
don't need to cover all booting possibilities.


This is what we used to (try) to do, but we failed at it.  Even when the 
policy was to not allow any library dependencies in /usr for binaries in 
/ there were many dozens that crept in unnoticed.  The fact that they 
crept in is also part of the problem; mounting /usr was sufficiently 
niche that it didn't get enough testing to pick up these problems and 
resolve them before they caused trouble.  That alone was a warning sign 
that this option wasn't well supported and was subject to breakage as a 
result, and is also a factor in its demise.


The problem is agreeing on what is essential for booting, and what is 
not.  There's so much variety in differing requirements that satisfying 
everyone is impossible.  For example, ext[234], md and lvm2 might be a 
common requirement, maybe xfs and btrfs-tools as well.  How about ZFS? 
Ceph? GlusterFS? Or proprietary third-party filesystems like IBM GPFS. 
LDAP.  Encryption.  Networking.  CA Certificates.  SSL/TLS.  There's 
always "just one more" requirement, which critically breaks someone's 
system if it's not specially catered for.  This is why the problem is 
unbounded and this situation was untenable.  It made a separate /usr 
completely unusable for a good number of perfectly legitimate setups, 
many of which were hard requirements for working in large corporate or 
academic IT environments, where it had to inter-operate well with the 
existing infrastructure.  The fact that Debian was hideously broken by 
default for all these use cases had been an embarrassment for a number 
of years which we needed to solve.


We could certainly pick an essential subset of tools and filesystems, 
and state that this combination is allowed for mounting /usr.  But this 
is basically drawing a line in the sand and saying that outside those 
essential packages, everything else is a second-class citizen which 
isn't properly supported.  One of the points which has been made 
multiple times is the need for freedom for the admin to configure their 
systems as they like.  It's obviously important.  But by drawing this 
line we are saying that you /can't/ have the freedom to use anything 
outside this essential set because it will break.  Forget about 
experimenting with new and interesting filesystems.  And forget about 
integrating with the infrastructure required by your company.


And lest anyone forget history, it was once impossible to use md or lvm 
(or btrfs etc.) for booting, before all that special-casing and 
bootloader support was in place.  I was one of the first people to try 
all that out and identify the problems when it was brand spanking new. 
The same restrictions apply to any new technologies which come along in 
the future.  We don't want to deliberately limit future possibilities.


Those factors had to be weighed against the need to mount a /usr without 
an initramfs.  The number of people doing this was a niche subset of a 
already very small subset.  We support booting without an initramfs.  We 
support booting with a separate /usr.  But not both together.  There are 
limits to what is possible and reasonable to support, and that use case 
was judged to be so tiny that the other use cases were of greater benefit.


No matter how you slice it, restrictions were going to be placed upon 
the use of a separate /usr for one subset of users or another.  The 
status quo was that it worked without an initramfs, but was broken for a 
large number of other scenarios.  We stopped it working without an 
initramfs but made it work for **all** of the other scenarios.  So in 
terms of allowing a separate /usr, we actually /increased/ its 
flexibility and utility at the expense of this one use case.  I tried my 
hardest to avoid any breakage at all, but I couldn't figure out a 
supportable way to do this.  If anyone can figure out a solution, then 
I'd be very happy.  However, given that the solution to the problem is 
to simply use an initramfs, that's the official solution here.  Keep a 
separate /usr, but use the 

Re: [DNG] How to unmerge /usr (was Re: /usr to merge or not to merge... that is the question)

[Arnt Karlsen]

On Thu, 29 Nov 2018 10:05:19 +0100, Arnt wrote in message 
<20181129100519.303dfc44@sda3>:

> On Wed, 28 Nov 2018 22:34:27 +0100 (CET), k...@aspodata.se wrote in
> message <20181128213427.2e51f862a...@turkos.aspodata.se>:
> 
> > Rich Moen:  
> > > Quoting KatolaZ (kato...@freaknet.org):
> > ...  
> > > > # ldd /bin/ps | grep "/usr"
> > > > liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1
> > > > (0x7fd7f6ebc000)
> > > 
> > > Yeah, those two are really annoying.  FWIW, my server system has
> > > older versions of those two utilities that do _not_ have that
> > > (IMO) build error.  Local packages will be an immediate resort,
> > > when/if I hit that.
> > ...
> > 
> > Attached is a program to find possible /-/usr link breakage.
> > It could possible be changed into an un-usrmerge-program if we
> > want.  
> 
> ..yup, and packaged too.  Put it in /sbin ?  A shell or busybox 
> or binary version might be handy to debug those boot-oopses.
> 
> > Example output on a smallish system:
> > # usr.pl
> > /bin/nano
> > /usr/lib64/libmagic.so.1
> > /bin/ping
> > /usr/lib64/libcrypto.so.1.0.0  
> 
> ..the output from my "life boat" install of
> devuan_ascii_2.0.0_amd64_desktop-live.iso
> is quite telling: 
> sda3:~# usr.pl
> /bin/efibootmgr
> /usr/lib/x86_64-linux-gnu/libefivar.so.1
> /usr/lib/x86_64-linux-gnu/libefiboot.so.1
> /bin/efibootdump
> /usr/lib/x86_64-linux-gnu/libefivar.so.1
> /usr/lib/x86_64-linux-gnu/libefiboot.so.1
> /bin/ping
> /usr/lib/x86_64-linux-gnu/libnettle.so.6
> /sbin/mount.nfs
> /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2
> /usr/lib/x86_64-linux-gnu/libkrb5.so.3
> /usr/lib/x86_64-linux-gnu/libk5crypto.so.3
> /usr/lib/x86_64-linux-gnu/libkrb5support.so.0
> /sbin/dhclient
> /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2
> /sbin/rpcbind
> /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2
> /usr/lib/x86_64-linux-gnu/libkrb5.so.3
> /usr/lib/x86_64-linux-gnu/libk5crypto.so.3
> /usr/lib/x86_64-linux-gnu/liblz4.so.1
> /usr/lib/x86_64-linux-gnu/libkrb5support.so.0
> /sbin/crda
> /usr/lib/x86_64-linux-gnu/libssl.so.1.1
> /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
> /sbin/tc
> /usr/lib/x86_64-linux-gnu/libelf.so.1
> /sbin/umount.udisks2
> /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> /usr/lib/x86_64-linux-gnu/libudisks2.so.0
> /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0
> /usr/lib/x86_64-linux-gnu/libffi.so.6
> /sbin/wpa_supplicant
> /usr/lib/x86_64-linux-gnu/libpcsclite.so.1
> /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
> /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2
> /sbin/rpc.statd
> /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2
> /usr/lib/x86_64-linux-gnu/libkrb5.so.3
> /usr/lib/x86_64-linux-gnu/libk5crypto.so.3
> /usr/lib/x86_64-linux-gnu/libkrb5support.so.0
> /sbin/regdbdump
> /usr/lib/x86_64-linux-gnu/libssl.so.1.1
> /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
> /sbin/discover
> /usr/lib/libdiscover.so.2
> /sbin/sgdisk
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> /sbin/gdisk
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> /sbin/cgdisk
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> /sbin/sm-notify
> /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2
> /usr/lib/x86_64-linux-gnu/libkrb5.so.3
> /usr/lib/x86_64-linux-gnu/libk5crypto.so.3
> /usr/lib/x86_64-linux-gnu/libkrb5support.so.0
> /sbin/fixparts
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> /sbin/showmount
> /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2
> /usr/lib/x86_64-linux-gnu/libkrb5.so.3
> /usr/lib/x86_64-linux-gnu/libk5crypto.so.3
> /usr/lib/x86_64-linux-gnu/libkrb5support.so.0
> /sbin/xtables-multi
> /usr/lib/x86_64-linux-gnu/libip4tc.so.0
> /usr/lib/x86_64-linux-gnu/libip6tc.so.0
> /usr/lib/x86_64-linux-gnu/libxtables.so.12
> sda3:~#
> 
> ..note that I did toss out Xfce for LXQt to ease my workload fixing
> vdev or eudev, both are too polite to help build me a bootable
> initrd. 
> 
> 

..chrooting into that sick box, I get:
root@sda3:/# usr.pl |grep ^/ |wc -l
36
root@sda3:/# dpkg -S $(usr.pl |grep ^/ ) |cut -d":" -f1 |sort \
|uniq |wc -l 
20
root@sda3:/# dpkg -S $(usr.pl |grep ^/ ) |cut -d":" -f1 |sort |uniq
audispd-plugins
auditd
crda
discover
drbd-utils
ecryptfs-utils
efibootmgr
gdisk
iproute2
iptables
iptables-nftables-compat
iputils-ping
isc-dhcp-client
libpam-ccreds
nfs-common
nfs-kernel-server
reiserfsprogs
rpcbind
udisks2
wpasupplicant
root@sda3:/# ll $(usr.pl |grep ^/ )
-rwxr-xr-x 1 root root   18960 Jan  6  2017 /bin/efibootdump
-rwxr-xr-x 1 root root   40744 Jan  6  2017 /bin/efibootmgr
-rwxr-xr-x 1 root root   61240 Nov 10  2016 /bin/ping
-rwxr-xr-x 1 root root   30792 Apr 12  

Re: [DNG] How to unmerge /usr (was Re: /usr to merge or not to merge... that is the question)

[Arnt Karlsen]

On Thu, 29 Nov 2018 13:34:24 +0100, KatolaZ wrote in message 
<20181129123424.ojmbaljuam77m...@katolaz.homeunix.net>:

> On Thu, Nov 29, 2018 at 09:18:38PM +0900, Olaf Meeuwissen wrote:
> > Hi Karl,
> > 
> > k...@aspodata.se writes:
> >   
> > > Rich Moen:  
> > >> Quoting KatolaZ (kato...@freaknet.org):  
> > > ...  
> > >> > # ldd /bin/ps | grep "/usr"
> > >> > liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1
> > >> > (0x7fd7f6ebc000)  
> > >>
> > >> Yeah, those two are really annoying.  FWIW, my server system has
> > >> older versions of those two utilities that do _not_ have that
> > >> (IMO) build error.  Local packages will be an immediate resort,
> > >> when/if I hit that.  
> > > ...
> > >
> > > Attached is a program to find possible /-/usr link breakage.
> > > It could possible be changed into an un-usrmerge-program if we
> > > want.  
> > 
> > Looks like your script is ignoring any symlinks in /bin and /sbin
> > that point to stuff in /usr ...
> > Or elsewhere not on the partition that holds / ...
> > :-/
> >   
> 
> Actually, that would amount to getting down a quite deep rabbit
> hole. Those links, even if they exist, might have been created by the
> postinst script of some package, or by the local sysadmin. In the
> former case, removing them blindly will probably cause at least a dpkg
> error at the next upgrade of the corresponding package.

..we can use those dpkg errors to help automate bug reports.

..and wherever we disagree with Debian's merge etc policy, 
a Devuan fork .deb can be as simple as having our postinst 
script flip a symlink around, or copying files into /sbin 
or /bin, rather than symlinking them there.

> In the latter
> case, removing them blindly might possibly cause breakage to some
> functionality put in place by the sysadmin and/or undesired
> side-effects.

..dpkg-divert is handy in such cases.

-- 
..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] /usr to merge or not to merge... that is the question

[Olaf Meeuwissen]

Hi Stephan,

# Disclaimer: / and /usr live on the same partition on my systems.
# Heads up: I just might change that ... back to what I used to do.

Stephan Seitz writes:

> Maintainers are encouraged to install everything in /usr because it must
> be available in early boot.

Call me dumb but I totally, completely and utterly fail to understand
why "Maintainers are *encouraged* to install everything in /usr".

# Emphasis added.

I just don't get what benefits

  for d in bin sbin lib; do
mv /$d /usr/$d
rmdir /$d
ln -s /usr/$d /$d   # to avoid major mayhem
  done

will bring *me*.  For maintainers, the only benefit I can think of is
removal of the need to think where something should go (and addressing
any fall-out of that should dependencies not be on the same partition).

For the record, /usr (whether on a *separate* partition or not) just
happens to be available in "early boot" because keeping it out was
deemed undoable, i.e. "requires more effort than the Debian maintainers
are willing to spend".

# I don't blame them for that, it's just that even though it might make
# economic sense, it is not a technologically or organizationally sound
# justification.  I've been trying to point out that putting the system
# critical and non-critical stuff in different "drawers" makes sense in
# terms of organization.  So has Didier.
# Insisting on putting these "drawers" in different "chests" (often for
# rather good reasons as Rick has tried to show) is actually why things
# get complicated.

> That’s why the usrmerge is only the logical next step. If you can’t live
> without /usr, you can put everything in it. Why should you waste your
> precious resources? There are enough other problems.

Fact: You can't live without /.
Hence, you can put everything in it.
Let's move /usr/{bin,sbin,lib} to /{bin,sbin,lib}, yeah!
Q: Why would you waste your precious resources moving stuff around?
A: Because needed stuff is on a different partition.
Solution: Disallow the different partition.
Objection: But the different partition makes it easy to impose
 restrictions (think ro/nodev/nosuid) or tune performance (think
 noatime).
Q: Isn't there some filesystem type that supports settings at a more
 granular level than the device?  Like directory or per file?
A: Eh ... Don't know.  Haven't checked ...
Solution: Go fish!

# I haven't gone fishing yet but a vague recollection of Roger's post
# where he mentioned ZFS seemed promising ...

> With the many features an application can have today you will have a
> hard time finding and moving all the stuff [from /usr to /].  And then
> people would complain that their / doesn’t have enough space…

Tell them to increase the size of the partition that holds '/'.
Tell them to nuke the partition that holds '/usr'.
Make a usr-merge package that actually merges the partition that holds
the '/usr' file system tree with the partition that holds '/'.

Okay, so the three suggestions immediately above are tongue-in-cheek.
My main "stumbling block" is really about the (near) orthogonality of
filesystem tree organization and how that is mapped onto partitions.

If / and /usr are on a single partition, what is the benefit of moving
the contents of /bin, /lib and /sbin to their /usr counterparts?  What
are the drawbacks?

If / and /usr are on different partions, what is the benefit of moving
the contents of /bin, /lib and /sbin to their /usr counterparts?  What
are the drawbacks?

@KatolaZ Thanks for making the usr-merge an option in the installer.
 Even more thanks for making the default *not* merged because
 system-critical and system-non-critical really should be kept
 in different "drawers", IMNSHO.

Hope this helps, but somewhat afraid it won't :-/
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[karl]

Roger:
...
> Note that to return to the pre-merge policies would be an exercise in 
> futility.  It was already an exercise in futility back in 2011 because 
> the number of libraries which /could/ be moved to /lib is an unbounded 
> set.  There's always another tool which /might/ be required, which pulls 
> in yet more libraries, and their dependencies, and the dependencies of 
> their dependencies and so on.  It's a Sisyphean task.

It wouldn't be for a subset of booting setups. It is perfectly possible
for a certain set. If I make a make a kernel package, I can certainly 
say that that this package supports direct boot to disk without initrd 
and with a separate /usr, with the constraint that it don't support
e.g. lvm and other setups.

Why not agree on a certain set of programs/libs that should be in /bin,
/sbin, and /lib, just to not break my and others packages. That set
don't need to cover all booting possibilities.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden


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

Re: [DNG] How to unmerge /usr

[karl]

Rich Moen:
...
> You might have different criteria in mind, so please feel free to
> clarify, if so.   My view is that executables in /sbin and /bin 
> _required for maintenance in /usr's absence_ must not depend on /usr
> being mounted.  Many executables somehow get installed there anyway; 
> probably they'd have been better written to /usr/sbin and /usr/bin, 
> but that's a separate issue.  As Filesystem Hierarchy Standard 2.3[1]
> puts it:
> 
>   /sbin contains binaries essential for booting, restoring, recovering,
>   and/or repairing the system in addition to the binaries in /bin.
> 
>   /bin contains commands that may be used by both the system
>   administrator and by users, but which are required when no other
>   filesystems are mounted (e.g. in single user mode).  It may also 
>   contain commands which are used indirectly by scripts
...

One can then compile a list of thoose binaries. It will obviously
depend on your system/s.

booting:
 grub, lilo, other boot loaders, init, sh
restoring, recovering, repair:
 tar, dump, cpio, *fdisk, mkfs.*, fsck.*

A possible list could be:

/bin
 attr, basename, cat, chgrp, chmod, chown, cp, cpio, cut, date, dd,
 df, diff, du, echo, find, free, grep, groups, head, hexdump, kill,
 less, ln, man, md5sum, mkdir, mv, ps, pwd, readlink, rm, rmdir, sed,
 sh, sha1sum?, sleep, sort, stat, stty, sync, tail, tar, tee,  time,
 touch, tty, uname, uniq, wc, which, xargs

/sbin
 badblocks, blkzone, blkid, blockdev, depmod, dump, e2*, findfs,
 fdisk, fsck*, fstrim, fsync, halt, hdparm,  hostname, init, insmod,
 ldconfig, loadkmap, lsmod, makedevs, mdadm, mkfs.*, mkswap, modinfo,
 modprobe, mkfifo, mknod, mount, poweroff, rdev, reboot, rmmod, swapon,
 umount, xfs* (if you use xfs)

Add your boodloader.

Possible additions:
 *acl, *attr, de/compression programs, network setup programs

Any more?

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden


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

Re: [DNG] How to unmerge /usr (was Re: /usr to merge or not to merge... that is the question)

[KatolaZ]

On Thu, Nov 29, 2018 at 09:18:38PM +0900, Olaf Meeuwissen wrote:
> Hi Karl,
> 
> k...@aspodata.se writes:
> 
> > Rich Moen:
> >> Quoting KatolaZ (kato...@freaknet.org):
> > ...
> >> > # ldd /bin/ps | grep "/usr"
> >> > liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
> >> > (0x7fd7f6ebc000)
> >>
> >> Yeah, those two are really annoying.  FWIW, my server system has older
> >> versions of those two utilities that do _not_ have that (IMO) build
> >> error.  Local packages will be an immediate resort, when/if I hit that.
> > ...
> >
> > Attached is a program to find possible /-/usr link breakage.
> > It could possible be changed into an un-usrmerge-program if we want.
> 
> Looks like your script is ignoring any symlinks in /bin and /sbin that
> point to stuff in /usr ...
> Or elsewhere not on the partition that holds / ...
> :-/
> 

Actually, that would amount to getting down a quite deep rabbit
hole. Those links, even if they exist, might have been created by the
postinst script of some package, or by the local sysadmin. In the
former case, removing them blindly will probably cause at least a dpkg
error at the next upgrade of the corresponding package. In the latter
case, removing them blindly might possibly cause breakage to some
functionality put in place by the sysadmin and/or undesired
side-effects.

My2Cents

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

Re: [DNG] /usr to merge or not to merge... that is the question

[Stephan Seitz]

On Do, Nov 29, 2018 at 01:22:05 -0500, Steve Litt wrote:

My understanding is that Devuan will ask in the fresh installer whether
the user wants to merge or not, with the default being no merge. This
is fine with me. Do you have a problem with it?


Nope, but even Devuan will probably never support a separate /usr without 
mounting it in early boot via initrd.


Shade and sweet water!

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] /usr to merge or not to merge... that is the question

[Roger Leigh]

On 29/11/2018 10:21, Arnt Karlsen wrote:> On Wed, 28 Nov 2018 15:26:59 
+, Roger wrote in message

<38625727-08b2-2816-85b0-8f57d6796...@codelibre.net>:


This isn't a bug, or even a feature.  It's a deliberate design
decision which affects the functioning of the system as a whole.  I
understand your concerns, and I even sympathise with them, but the
decision to do this was taken over six years ago after extensive
discussion,


..links to the important parts of those discussions would be nice
and very helpful.


I don't have the time to dig through all the separate mailing lists, IRC 
logs, bug ticket and all the rest.  It's scattered too widely and over 
too long a period of time.  However, I have dug up some public mailing 
list threads over the time period concerned which might be informative.


https://lists.debian.org/debian-devel/2011/12/threads.html
  Red Hat is moving from / to /usr/
  from / to /usr/: a summary

https://lists.debian.org/debian-devel/2011/12/thrd2.html
  #652011
  #652275

https://lists.debian.org/debian-devel/2012/01/threads.html
  from / to /usr/: a summary

https://lists.debian.org/debian-devel/2012/09/msg00010.html
  Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

https://lists.debian.org/debian-devel/2012/08/thrd2.html
  Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

https://lists.debian.org/debian-devel/2012/09/threads.html
  Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

https://lists.debian.org/debian-devel/2012/12/threads.html
  Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652459
  Contains most of the implementation discussion and iterative 
refinement of the patchset.



and it's been implemented and released six and four years ago,
respectively.


...appearantly with trumpian eptitude, running Karl's usr.pl on my
"life boat" install of devuan_ascii_2.0.0_amd64_desktop-live.iso,
I found 20 programs in /bin or /sbin in 12 packages that might need
a fix.


Interestingly, if you read some of these threads, you'll see people 
doing exactly this auditing back in 2011-12 because this was already 
causing breakage back then, even before the mounting of /usr in the 
initramfs.



..I put Karl's usr.pl in /sbin and ran it first bare, then counted
with: usr.pl |grep ^/ |wc -l
and: dpkg -S $(usr.pl |grep ^/ ) |cut -d":" -f1 |sort |uniq |wc -l

..fixing 2 or 3 packages a year, is very doable. ;o)

..now, do we return to the pre-merge policies 6 and 4 years ago?
Yes, as a first step, I believe we should[…]


Note that to return to the pre-merge policies would be an exercise in 
futility.  It was already an exercise in futility back in 2011 because 
the number of libraries which /could/ be moved to /lib is an unbounded 
set.  There's always another tool which /might/ be required, which pulls 
in yet more libraries, and their dependencies, and the dependencies of 
their dependencies and so on.  It's a Sisyphean task.


On 29/11/2018, 06:22 Steve Litt wrote:

> I see the fingerprints of Redhat, Poettering and Freedesktop all over
> such encouragement, and highly doubt it's for technical reasons.

If you read the threads above, you will see that RedHat were planning to 
merge /usr at this point.  It's no secret that there is some 
cross-pollination of ideas between distributions, and that there is also 
some degree of pressure for conformity to benefit interoperability. 
However, it's also /not/ a conspiracy in any way.  This was all 
discussed and implemented in public, not done in secret.  There were 
solid technical reasons for doing this, and it's likely this would have 
happened with or without any degree of influence from RedHat.  The fact 
that it was actually implemented by the sysvinit maintainers should be a 
big hint that we saw a good deal of value in it which would greatly 
improve the flexibility and maintainability of the initscripts for the 
benefit of our users.  And also, without it, there would have been /even 
more/ pressure to adopt systemd, since it removed the arguments about 
sysvinit/initscripts being unable to handle a number of scenarios which 
it previously couldn't cope with.



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

Re: [DNG] How to unmerge /usr (was Re: /usr to merge or not to merge... that is the question)

[Olaf Meeuwissen]

Hi Karl,

k...@aspodata.se writes:

> Rich Moen:
>> Quoting KatolaZ (kato...@freaknet.org):
> ...
>> > # ldd /bin/ps | grep "/usr"
>> > liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
>> > (0x7fd7f6ebc000)
>>
>> Yeah, those two are really annoying.  FWIW, my server system has older
>> versions of those two utilities that do _not_ have that (IMO) build
>> error.  Local packages will be an immediate resort, when/if I hit that.
> ...
>
> Attached is a program to find possible /-/usr link breakage.
> It could possible be changed into an un-usrmerge-program if we want.

Looks like your script is ignoring any symlinks in /bin and /sbin that
point to stuff in /usr ...
Or elsewhere not on the partition that holds / ...
:-/

Hope that helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[Hendrik Boom]

On Thu, Nov 29, 2018 at 12:44:35AM -0600, goli...@dyne.org wrote:
> On 2018-11-29 00:22, Steve Litt wrote:
> > 
> > My understanding is that Devuan will ask in the fresh installer whether
> > the user wants to merge or not, with the default being no merge. This
> > is fine with me.
> > 
> 
> I installed a test beowulf mini.iso a few days ago and there was indeed an
> option to merge.  The default is to keep them separate.
> 
> golinux

Great!  It has been tested.

Because that which is not tested is broken.

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

Re: [DNG] How to unmerge /usr (was Re: /usr to merge or not to merge... that is the question)

[Rick Moen]

Quoting Arnt Karlsen (a...@iaksess.no):

> ..the output from my "life boat" install of
> devuan_ascii_2.0.0_amd64_desktop-live.iso
> is quite telling: 

[snip]

My view:  It's not necessarily problematic that something in /sbin or
/bin depends on /usr to function -- and most of the tools you list IMO 
are not a problem on that account.

You might have different criteria in mind, so please feel free to
clarify, if so.   My view is that executables in /sbin and /bin 
_required for maintenance in /usr's absence_ must not depend on /usr
being mounted.  Many executables somehow get installed there anyway; 
probably they'd have been better written to /usr/sbin and /usr/bin, 
but that's a separate issue.  As Filesystem Hierarchy Standard 2.3[1]
puts it:

  /sbin contains binaries essential for booting, restoring, recovering,
  and/or repairing the system in addition to the binaries in /bin.

  /bin contains commands that may be used by both the system
  administrator and by users, but which are required when no other
  filesystems are mounted (e.g. in single user mode).  It may also 
  contain commands which are used indirectly by scripts

Many of the utilities you found using that script _aren't_ IMO required 
during the sort of maintenance operations contemplated here.


[1] Yes, FHS 3.0 also exists.  FWIW, I have reservations about its
general soundness under Linux Foundation's LSB Workgroup authorship
that made substantial revisions from Dan Quinlan, Rusty Russell, and the
late Chris Yeoh's universally admired FHS 2.x work.


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

Re: [DNG] /usr to merge or not to merge... that is the question

[Arnt Karlsen]

On Wed, 28 Nov 2018 15:26:59 +, Roger wrote in message 
<38625727-08b2-2816-85b0-8f57d6796...@codelibre.net>:

> On 28/11/2018 11:36, Rick Moen wrote:
> > Quoting Didier Kryn (k...@in2p3.fr):
> >   
> >> IIUC, your argument boils down to "depending on /usr for early
> >> boot is a *bug*", while Roger told us why it has become a
> >> *feature* (~:  
> > 
> > My view, which I expressed in detail prior to Roger joining the
> > thread, is that it's vital to the most vital function of the root
> > filesystem's maintenance software directories
> > (/sbin, /bin, /lib, /lib64) that their binaries function _even_
> > if /usr is not (or at the moment cannot be) mounted -- because the
> > most vital function of those subtrees is backup, restore, repair,
> > maintenance (functions that might be required to
> > recover/fix /usr).  
> 
> Prior to wheezy, this was considered vital and was explicitly
> required and enforced.  From wheezy onward, this requirement was
> deliberately and intentionally dropped.
> 
> If you want to backup, restore, or repair your system, you can still
> do so.  But you have to do so with /usr present either as part of the 
> rootfs or mounted as a separate filesystem.
> 
> This isn't a bug, or even a feature.  It's a deliberate design
> decision which affects the functioning of the system as a whole.  I
> understand your concerns, and I even sympathise with them, but the
> decision to do this was taken over six years ago after extensive
> discussion,

..links to the important parts of those discussions would be nice 
and very helpful.

> and it's been implemented and released six and four years ago,
> respectively.


...appearantly with trumpian eptitude, running Karl's usr.pl on my
"life boat" install of devuan_ascii_2.0.0_amd64_desktop-live.iso, 
I found 20 programs in /bin or /sbin in 12 packages that might need 
a fix.  

..I put Karl's usr.pl in /sbin and ran it first bare, then counted 
with: usr.pl |grep ^/ |wc -l 
and: dpkg -S $(usr.pl |grep ^/ ) |cut -d":" -f1 |sort |uniq |wc -l

..fixing 2 or 3 packages a year, is very doable. ;o)


..now, do we return to the pre-merge policies 6 and 4 years ago? 
Yes, as a first step, I believe we should, while we revisit boot 
policy history and sites like:
http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/etc.html
where I recommend scrolling down to gems like: "/etc/rcS.d
The scripts in this directory are executed once when booting the
system, even when booting directly into single user mode. 
The files are all symbolic links, the real files are located
in /etc/init.d/. For a more general discussion of this technique,
see /etc/init.d/README.", and then back up to: "/etc/init.d

Order of scripts run in /etc/rc?.d
==

0. Overview. " etc, which is quite different from Debian's version.


..me, I'd like to see /boot/initrd.img-recovery-$(uname -r) in the
grub menu recovery stanzas guarantee boot into runlevel S or 1, so
broken systems can be fixed, and lessons can be learned from those
fixes.

..to make those system maintenance lessons useful etc, my proposed 
/boot/initrd.img-recovery-$(uname -r) should carry at least the same
tools I expect to find in runlevel S or 1, or drop me home there, in 
runlevel S or 1.


-- 
..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] How to unmerge /usr (was Re: /usr to merge or not to merge... that is the question)

[Arnt Karlsen]

On Wed, 28 Nov 2018 22:34:27 +0100 (CET), k...@aspodata.se wrote in
message <20181128213427.2e51f862a...@turkos.aspodata.se>:

> Rich Moen:
> > Quoting KatolaZ (kato...@freaknet.org):  
> ...
> > > # ldd /bin/ps | grep "/usr"
> > > liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1
> > > (0x7fd7f6ebc000)  
> > 
> > Yeah, those two are really annoying.  FWIW, my server system has
> > older versions of those two utilities that do _not_ have that (IMO)
> > build error.  Local packages will be an immediate resort, when/if I
> > hit that.  
> ...
> 
> Attached is a program to find possible /-/usr link breakage.
> It could possible be changed into an un-usrmerge-program if we want.

..yup, and packaged too.  Put it in /sbin ?  A shell or busybox 
or binary version might be handy to debug those boot-oopses.

> Example output on a smallish system:
> # usr.pl
> /bin/nano
> /usr/lib64/libmagic.so.1
> /bin/ping
> /usr/lib64/libcrypto.so.1.0.0

..the output from my "life boat" install of
devuan_ascii_2.0.0_amd64_desktop-live.iso
is quite telling: 
sda3:~# usr.pl
/bin/efibootmgr
/usr/lib/x86_64-linux-gnu/libefivar.so.1
/usr/lib/x86_64-linux-gnu/libefiboot.so.1
/bin/efibootdump
/usr/lib/x86_64-linux-gnu/libefivar.so.1
/usr/lib/x86_64-linux-gnu/libefiboot.so.1
/bin/ping
/usr/lib/x86_64-linux-gnu/libnettle.so.6
/sbin/mount.nfs
/usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2
/usr/lib/x86_64-linux-gnu/libkrb5.so.3
/usr/lib/x86_64-linux-gnu/libk5crypto.so.3
/usr/lib/x86_64-linux-gnu/libkrb5support.so.0
/sbin/dhclient
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2
/sbin/rpcbind
/usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2
/usr/lib/x86_64-linux-gnu/libkrb5.so.3
/usr/lib/x86_64-linux-gnu/libk5crypto.so.3
/usr/lib/x86_64-linux-gnu/liblz4.so.1
/usr/lib/x86_64-linux-gnu/libkrb5support.so.0
/sbin/crda
/usr/lib/x86_64-linux-gnu/libssl.so.1.1
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
/sbin/tc
/usr/lib/x86_64-linux-gnu/libelf.so.1
/sbin/umount.udisks2
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
/usr/lib/x86_64-linux-gnu/libudisks2.so.0
/usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0
/usr/lib/x86_64-linux-gnu/libffi.so.6
/sbin/wpa_supplicant
/usr/lib/x86_64-linux-gnu/libpcsclite.so.1
/usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2
/sbin/rpc.statd
/usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2
/usr/lib/x86_64-linux-gnu/libkrb5.so.3
/usr/lib/x86_64-linux-gnu/libk5crypto.so.3
/usr/lib/x86_64-linux-gnu/libkrb5support.so.0
/sbin/regdbdump
/usr/lib/x86_64-linux-gnu/libssl.so.1.1
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
/sbin/discover
/usr/lib/libdiscover.so.2
/sbin/sgdisk
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
/sbin/gdisk
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
/sbin/cgdisk
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
/sbin/sm-notify
/usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2
/usr/lib/x86_64-linux-gnu/libkrb5.so.3
/usr/lib/x86_64-linux-gnu/libk5crypto.so.3
/usr/lib/x86_64-linux-gnu/libkrb5support.so.0
/sbin/fixparts
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
/sbin/showmount
/usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2
/usr/lib/x86_64-linux-gnu/libkrb5.so.3
/usr/lib/x86_64-linux-gnu/libk5crypto.so.3
/usr/lib/x86_64-linux-gnu/libkrb5support.so.0
/sbin/xtables-multi
/usr/lib/x86_64-linux-gnu/libip4tc.so.0
/usr/lib/x86_64-linux-gnu/libip6tc.so.0
/usr/lib/x86_64-linux-gnu/libxtables.so.12
sda3:~#

..note that I did toss out Xfce for LXQt to ease my workload fixing
vdev or eudev, both are too polite to help build me a bootable initrd. 


-- 
..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] Participate to the first Devuan Conference in Amsterdam!

[Adam Borowski]

On Wed, Nov 28, 2018 at 03:03:57PM -0800, Rick Moen wrote:
> Also, don't sweat the language thing.  Especially in the
> Netherlands where everyone seems to speak English with breathtaking
> acuity, you'd have zero problem.  Walking around Glasgow, you might find
> the brogue bewildering, but in Amsterdam?  Never.

There are worse cases.  There's a place called "London", where a sign says
"Sloane Square" yet the station announcement (by a person paid to have clear
diction) says "Ten Ske".

So people in, say, Stockholm, bother to learn English, people in London
don't.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Ivan was a wordly man: born in St. Petersburg, raised in
⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned
⠈⠳⣄ to the city of his birth to die.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[KatolaZ]

On Wed, Nov 28, 2018 at 09:12:33PM -0500, Steve Litt wrote:
> On Wed, 28 Nov 2018 12:11:25 +0100
> Didier Kryn  wrote:
> 
>  
> >      IIUC, your argument boils down to "depending on /usr for early
> > boot is a *bug*", while Roger told us why it has become a *feature*
> > (~:
> 
> I can think of very few cases where a disallowed usage is a feature.
> Private and local variables are two of the few. The pre-UEFI inability
> to brick your mobo was definitely another.
> 
> But I don't think foreclosing the opportunity to boot exclusively
> from the / partition, without an initramfs, is a "feature". Giving a
> choice is a feature, removing the alternative choice is not.
>  

Features, choices, alternatives, and freedom are not cheap, or
granted, or automatic.

Providing features costs energy, time, and work. Providing choice
costs energy, time, and work. Providing alternatives costs energy,
time, and work.

The required energy and time must come from somewhere, and the work
needs to be done by somebody. 

My2Cents

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