Re: [gentoo-user] Re: USE flag 'split-usr' is now global

[Kai Peter]

On 2019-08-04 20:01, Dale wrote:


It was discussed on -dev in at least a couple threads I think.  I sort


Thanks for that good hint. I did browse through the archives.

--
Sent with eQmail-1.10.3 beta - a fork of djb's famous qmail

Re: [gentoo-user] Re: acct-group packages ??

[Neil Bothwick]

On Sun, 4 Aug 2019 09:59:06 -0700, Ian Zimmerman wrote:

> I see, I got caught (again) by the favorite gentoo sleight of hand of
> updating a package and not bumping its version.  In my case, eudev.

I've not checked lately, but policy was that if an ebuild change did not
result in differences in the installed files, there was no need for a
version bump. This avoids needless recompiling of packages.


-- 
Neil Bothwick

Don't put all your hypes in one home page.


pgpVEfnq_n_yz.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] HACK: Boot without an initramfs / initrd while maintaining a separate /usr file system.

[Grant Taylor]

On 8/5/19 5:45 AM, Mick wrote:

Interesting concept, thanks for sharing.


You're welcome.

Unless I misunderstand how this will work, it will create duplication 
of the fs for /bin and /sbin, which will both use extra space and 
require managing.


Yes, it will create some duplication.  Though I don't think that /all/ 
of the contents of /bin and /sbin would need to be duplicated.  Think 
about the minimum viable binaries that are needed.


Perhaps something like busybox would even suffice.


Will you mount -bind the underlying fs in fstab?


You could.  I have done so in some VMs that I've tested various things.

My use case on my VPS is for an encrypted data partition.  So I have 
things like the following:


/home -> /var/LUKS/home
/etc/mail -> /var/LUKS/etc/mail
/etc/bind -> /var/LUKS/etc/bind

/var/LUKS/home/gtaylor does have an absolute minimum directory structure 
so that I can ssh in with my key and run a script to unlock / open and 
mount the LUKS volume and start some services (mostly email and DNS 
related).


How will you make sure installations of the same binaries are 
installed/copied in both underlying and mounted /usr/* fs and kept 
in sync?  By changing all affected ebuilds?


I don't have an answer to this qustion.  I've not needed an answer to 
this question.


I think I would likely create a script that would copy specific files 
from the /usr path to the underlying /(usr) path as needed.


I doubt there would be many files.

I don't see any need to alter an untold number of ebuilds for a system 
architecture / file system decision.


It is a hack alright, to restore the previous default /usr 
functionality, so a useful option to consider.


That's why I shared it.

It's also an example of an idea that works for my use case that you are 
free to take and modify for your use case.  I don't need to know about 
your use case, much less have an answer for it, when I'm sharing my use 
case.  (Harking back to the different types of communities in the 
previous email.)


If I were to be asked my preference would be to revert the systemd 
inspired changes which caused this loss of functionality.  ;-)


Fair enough.

Though I would question just how much and what is broken by having a 
separate /usr file system without systemd.  }:-)  Specifically, is it 
truly broken?  Or does it need some minor tweaks?




--
Grant. . . .
unix || die

Re: [gentoo-user] Re: USE flag 'split-usr' is now global

[Grant Taylor]

On 8/5/19 4:49 AM, Mick wrote:

It is being /assertively/ promoted persistently by the same devs.


Okay.

Just because it's the same developers promoting both does not mean that 
any logic / evidence they might provide in support of /usr merge is 
inherently wrong.  We should judge the merits of their logic / evidence 
on it's own, independent of what we think of their other work.  (Read: 
Don't turn this technical conversation into a character discussion.)



Sure, but for how much longer?


/me looks around for something that he must have missed.

I didn't see anything about combining bin and sbin.

Let's focus on the /usr merger discussion /first/.  Then we can address 
bin vs sbin.


You need to check the direction of travel here and how long before a 
particular dev priesthood which imposes initrd, systemd and a single 
partition image, or whatever suits their mass market use cases agenda, 
foists their choice upon *all* users.


Again, focus on technical, this is not a character discussion.

I also don't think they will be successful in foisting their ideas on 
*all* users.  I'm quite confident that there will always be some random 
distro that does not subscribe to them.  Maybe the usable percentage 
will be quite small.  But any distro that doesn't tow the line means 
that not /all/ distros follow the agenda.  (Yes, I'm saying distro 
instead of user, but I think you understand either way.)


I personally don't like the idea of /{,s}bin being a sym-link to 
/usr/\1.  I like the idea that / (root) and /usr are (or can be) 
separate file systems.  That being said, I've not actually /needed/ them 
to be separate file systems in quite a while.  I may have /wanted/ them 
to be separate so that I could utilize different file system types for / 
(root) and /usr.


Looking back at all the systems that I've administered for the last ~20 
years, almost all of them did use a single file system for / (root) and 
/usr.  Sure, they likely had other file systems as well; /var, /tmp, and 
/home most likely.


Given how Unix / Linux is changing—evolving—where and how it's being 
used, I can see how there is no longer any need for the separate file 
systems.  I think this lack of need combined with the additional 
complexity is evolving into a desire for a single file system for / 
(root) and /usr.  Since I can't point to any specific use case—in about 
90 seconds—that a single file system would break, I'm pausing and thinking.


So, since we're discussing it, I invite you, and anyone else, to list 
pros and / or cons for either methodology.  I'm quite interested in 
learning what others think.


I will warn you that I'll likely respond with counter points and / or 
workarounds.  I will also expect that you will respond in kind to my 
response.


10 point
20 counterpoint
30 counter counterpoint
40 goto 10


I think following the lib directories merge, the discussion is now about
merging:

  /bin -> /usr/bin
  /sbin -> /usr/bin
  /usr/sbin -> /usr/bin


Let's fully qualify those directories.  ;-)

I've not seen /any/ discussion about merging bin and sbin.  Perhaps I've 
just missed it.  I'm going to ignore the merging of bin and sbin for the 
time being.



Since you asked this is my understanding, which may need correction by more
learned contributors, because some of this has happened well before I sat in
front of a keyboard.  Back in late 60s, early 70s, disks became larger as UNIX
was getting bigger.


ACK

This initially led to /bin and /sbin split across different physical 
devices and soon the same happened for /home, et al.


That's different than the history that I've heard.

Originally, everything was on one single disk.

Then a second disk was added and /usr was created.  User home 
directories were moved to /usr (hence it's name), and many of the same 
directory structures were replicated from / (root) to /usr.  (Likewise 
with /usr/local on other Unixes / Linuxes later.)


Then a third disk was added and /home was created.  User home 
directories were moved to /home.


So the /bin vs /sbin split that you're referring to doesn't jive with 
the history that I've seen / read / heard time and time again.


My understanding is that /sbin was originally intended for binaries 
needed to bring the system up.  (I view the "s" in "sbin" as meaning 
"system (binaries)".)


Similarly, my understanding is that /bin was originally intended for 
general use binaries that were used by more people.


Note:  The same understanding applies to the directories wherever they 
are located, / (root), /usr, and /usr/local.


But, I am ~> we are, ignoring bin vs sbin for much of this message and 
focusing on /usr merge.  ;-)



This historical fact of UNIX evolution to use multiple and subsequently larger
storage devices is being conflated with the purpose of these directories, what
they were created for back then and what their use should be today.


That sounds good.  But please put some details behind it.  What do you 

Re: [gentoo-user] Re: USE flag 'split-usr' is now global

[Mick]

On Monday, 5 August 2019 02:26:11 BST Grant Taylor wrote:
> On 8/4/19 12:03 PM, Mick wrote:
> > I don't know more about this, but it seems we are being dragged towards
> > a systemd inspired future, whether the majority of the gentoo community
> > of users want it or not.
> 
> How is the /usr merger /directly/ related to systemd?

It is being /assertively/ promoted persistently by the same devs.


> > In my view system binaries should not be thrown in the same pot as user
> > binaries and keeping the two separate makes good sense for those of us
> > who do not spin up 200 cloned VMs a second on a RHL corporate farm.
> 
> What are you using to differentiate system binaries and user binaries?
> Are you using the /usr directory?  Or the bin vs sbin directories?
> 
> Please elaborate on your working understanding.  I ask because I want
> correctly understand you and speak to what you're talking about.
> Especially considering that there will still be the bin vs sbin directories.

Sure, but for how much longer?  You need to check the direction of travel here 
and how long before a particular dev priesthood which imposes initrd, systemd 
and a single partition image, or whatever suits their mass market use cases 
agenda, foists their choice upon *all* users.

I think following the lib directories merge, the discussion is now about 
merging:

 /bin -> usr/bin
 /sbin -> usr/bin
 /usr/sbin -> bin 


Since you asked this is my understanding, which may need correction by more 
learned contributors, because some of this has happened well before I sat in 
front of a keyboard.  Back in late 60s, early 70s, disks became larger as UNIX 
was getting bigger.  This initially led to /bin and /sbin split across 
different physical devices and soon the same happened for /home, et al.

This historical fact of UNIX evolution to use multiple and subsequently larger 
storage devices is being conflated with the purpose of these directories, what 
they were created for back then and what their use should be today.  The 
passage of time has introduced shared libs, which necessitate certain 
directories being on the same fs.  Back then everything was statically linked 
so fs could be more independent.

Whether the *initial* directory split across different fs was introduced 
because UNIX had put on weight and disks became larger is of secondary 
importance IMHO.  As a user I tend to focus on the current usefulness of 
different *choices* and understand it is preferable to retain them 
architecturally as choices to also suit other users' preferences and use 
cases.  I'm talking about an acceptance of Linux and Gentoo in particular as a 
meta-distribution being created for the benefit of a community of users which 
is wider than my single interests and needs, but also wider than individual 
developers agendas and preferences.  That said devs are of course free to 
develop what they like, want and prefer, but if they cannot/will not serve the 
wider needs of the project and its community, then it may suit them to look 
for a new project.

As the world moved on and Linux was created, the split fs concept grew legs 
and different distros made their own choices how different directories/fs were 
created and their permanence between reboots, e.g. /tmp, /var/tmp, /usr/tmp 
etc.  This created the known Linux fs architecture variability which could 
well suited the particular distro communities who introduced it, but I 
understand why it would not suit cookie-cutter thin provisioned VM images.

This brings my understanding to today's purpose of having different /bin, /
sbin, /usr/bin and /usr/sbin directories as per FHS:

/bin should contain binaries that need to be available in single user mode for 
all users, like ls, cp, cat.

/sbin is for system binaries, like fsck, route, init, halt.

/usr/bin is for non-essential binaries for all users, your everyday desktop 
applications.

/usr/sbin is for non-essential system binaries like daemons, network 
utilities, some fs utilities.

The above FHS logic questions why you would need /usr to be mounted in order 
to boot the OS, or why using an initrd to achieve it is what we should be 
doing in gentoo a meta-distribution, just because all binary distros do so.


> > I'm not arguing against systemd, or merging all directories under an
> > equivalent of a $WINDOWS/ path, but it seems to me a gentoo system
> > architecture should retain the freedom of choice and flexibility it
> > has been famous for.
> 
> I agree that the user choice is *EXTREMELY* *IMPORTANT*!

Yes, this is what *community* projects are constitutionally put together for.  
Otherwise we all have our own pet projects, but (I hope) we don't try to foist 
them on our friends and neighbors.


> > Retrograde steps like being forced to use an initramfs just for
> > retaining a separate /usr partition, should not be the way gentoo
> > evolves.
> 
> Agreed.
> 
> I am curious why /you/ want (the ability to have) a separate /usr file
> system.  I 

Re: [gentoo-user] Re: acct-group packages ??

[Michael Orlitzky]

On 8/5/19 3:21 AM, Neil Bothwick wrote:
> On Sun, 4 Aug 2019 09:59:06 -0700, Ian Zimmerman wrote:
> 
>> I see, I got caught (again) by the favorite gentoo sleight of hand of
>> updating a package and not bumping its version.  In my case, eudev.
> 
> I've not checked lately, but policy was that if an ebuild change did not
> result in differences in the installed files, there was no need for a
> version bump. This avoids needless recompiling of packages.
> 

Realistically, almost all ebuild changes should incur a new revision. I
would much rather recompile 100 packages *and have it work* than compile
10 packages and have it crash three times requiring manual intervention
because the tree is so screwed up.

We have better guidelines these days:

https://devmanual.gentoo.org/general-concepts/ebuild-revisions

but they still give developers too much freedom to be lazy and commit
important changes without a revision. The "straight to stable" advice
contradicts our existing stabilization policy, and the USE flag advice
says that you can rely on a non-default, portage-only feature to prevent
breakage.

Re: [gentoo-user] Re: emerge --sync: problem refreshing keys

[Stefano Crocco]

On domenica 21 luglio 2019 13:22:55 CEST Stefano Crocco wrote:
> On domenica 21 luglio 2019 12:44:14 CEST Mick wrote:
> > On Sunday, 21 July 2019 11:17:30 BST Stefano Crocco wrote:
> > > On venerdì 19 luglio 2019 21:02:40 CEST Stefano Crocco wrote:
> > > > On venerdì 19 luglio 2019 18:21:46 CEST Ian Zimmerman wrote:
> > > > > On 2019-07-18 19:42, Stefano Crocco wrote:
> > > > > > Hello to everyone,
> > > > > > since yesterday emerge --sync fails because it can't refresh keys.
> > > > > > The
> > > > > > messages I get are:
> > > > > > 
> > > > > > Syncing repository 'gentoo' into '/usr/portage'...
> > > > > > 
> > > > > >  * Using keys from /usr/share/openpgp-keys/gentoo-release.asc
> > > > > >  * Refreshing keys via WKD ... [ !! ]
> > > > > >  * Refreshing keys from keyserver hkps://keys.gentoo.org
> > > > > >  ...OpenPGP
> > > > > >  keyring
> > > > > > 
> > > > > > refresh failed:
> > > > > > gpg: refreshing 4 keys from hkps://keys.gentoo.org
> > > > > > gpg: keyserver refresh failed: No keyserver available
> > > > > > 
> > > > > > OpenPGP keyring refresh failed:
> > > > > > gpg: refreshing 4 keys from hkps://keys.gentoo.org
> > > > > > gpg: keyserver refresh failed: No keyserver available
> > > > > 
> > > > > Perhaps something to do with this?
> > > > > 
> > > > > https://www.bleepingcomputer.com/news/security/public-certificate-po
> > > > > is
> > > > > on
> > > > > in
> > > > > g->
> > > > 
> > > > can-break-some-openpgp-implementations/
> > > > 
> > > > > Aside:
> > > > > I have already switched my personal gpg configuration to use the new
> > > > > isolated keyserver.
> > > > 
> > > > Thanks for the answer. I'd heard of this attack and read this [1]
> > > > article
> > > > on gentoo.org. From what I understand, it said that in theory there
> > > > shouldn't be problems when syncing because "The gemato tool used to
> > > > verify the Gentoo ebuild repository uses WKD by default. During normal
> > > > operation it should not be affected by this vulnerability". Reading
> > > > the
> > > > article again, I now see it also says that "In the worst case; Gentoo
> > > > repository syncs will be slow or hang" which, as you suggest, could
> > > > very
> > > > well be what's happened on my system. Unfortunately, the article
> > > > doesn't
> > > > say what to do if this happens.
> > > > 
> > > > Tomorrow I'll try investigating more.
> > > > 
> > > > Stefano
> > > > 
> > > > [1] https://www.gentoo.org/news/2019/07/03/sks-key-poisoning.html
> > > 
> > > It seems I found out how to fix the issue. I tried comparing my
> > > /usr/share/portage/config/repos.conf with the one which comes with a
> > > current stage3 and found out mine had the line
> > > 
> > > sync-openpgp-keyserver = hkps://keys.gentoo.org
> > > 
> > > which was missing in the file from stage3. Removing it (both here and in
> > > /etc/portage/repos.conf/gentoo.conf) allowed me to sync correctly. I
> > > hope
> > > this is the correct fix. I don't remember ever writing this line, so I
> > > suppose it came with the original stage3 I built my system from or was
> > > changed by another update (an update of what, however? According to
> > > `equery
> > > b`, this file doesn't belong to any package).
> > > 
> > > I hope thing will keep working.
> > > 
> > > Stefano
> > 
> > I grepped two older installations I had immediate access to and there is
> > no
> > directive containing "openpgp" anywhere within /etc/portage/.
> > 
> > In a new-ish installation there were a number of entries in /etc/portage/
> > 
> > repos.conf/gentoo.conf, but no keyserver URI:
> >  $ grep openpgp -r /etc/portage/repos.conf/gentoo.conf
> > 
> > sync-openpgp-key-path = /usr/share/openpgp-keys/gentoo-release.asc
> > sync-openpgp-key-refresh-retry-count = 40
> > sync-openpgp-key-refresh-retry-overall-timeout = 1200
> > sync-openpgp-key-refresh-retry-delay-exp-base = 2
> > sync-openpgp-key-refresh-retry-delay-max = 60
> > sync-openpgp-key-refresh-retry-delay-mult = 4
> > 
> > Perhaps you had added a keyserver as a fall back when you were configuring
> > your system to use WKD?  I haven't implemented WKD because there was no
> > news item advising us to do so.
> 
> Maybe. I really know nothing about these issues, so I'm sure I wouldn't have
> added that line by myself. Maybe I read about them somewhere and I forgot
> about it.
> 
> Stefano

If anyone is interested, I've found out a bit more about this issue. The 
mysterious line

sync-openpgp-key-path = /usr/share/openpgp-keys/gentoo-release.asc

is the default in portage since version 2.3.69 (~arch). This means that the 
problem suddenly reappeared the first time portage got updated. By chance, I'd 
just bought a new laptop and had finished installing Gentoo on it the day 
before. I tried syncing from it... and it worked. I was getting angry: on my 
desktop and my old laptop emerge --sync didn't work; on my new laptop it did. 
Of course, the three machines were configured almost in the same way, so I 
couldn't understand what could 

Re: [gentoo-user] HACK: Boot without an initramfs / initrd while maintaining a separate /usr file system.

[Mick]

On Monday, 5 August 2019 02:36:31 BST Grant Taylor wrote:
> On 8/4/19 7:26 PM, Grant Taylor wrote:
> > I am also using a bit of a hack that I think could be (re)used to allow
> > /usr being a separate file system without /requiring/ an initramfs /
> > initrd.  (I'll reply in another email with details to avoid polluting
> > this thread.)
> 
> I think that a variation of a technique I'm using for LUKS encrypted
> /home on a VPS could be used to allow booting without an initramfs /
> initrd while maintaining a separate /usr file system.
> 
> The problem is that /bin & /sbin would be symbolic links to /usr/bin &
> /usr/sbin.  So, any commands that would be needed to mount the /usr file
> system would need to be directly accessible in /bin & /sbin paths, or
> indirectly accessible in /usr/bin & /usr/sbin.
> 
> IMHO this is a whopper of a hack.
> 
> Create the bin and sbin directories inside of the /usr directory that is
> the mount point so that they are on the underlying file system that /usr
> is mounted over top of.  Then copy the needed binaries to the /usr/bin &
> /usr/sbin directories on the underlying file system.  That way,
> /sbin/fsck -> /usr/sbin/fsck still exists even before the real /usr is
> mounted.
> 
> I did say this is a whopper of a hack.
> 
> It's trivial to access these directories even when the normal / full
> /usr is mounted.
> 
> 1)  mkdir /mnt/root-underlay
> 2)  mount -o bind / /mnt/root-underlay
> 3)  ls /mnt/root-underlay/bin /mnt/root-underlay/sbin
> 
> This "technique" / "trick" / "hack" works because the /bin & /sbin
> ""directories are sym-links to the /usr/bin & /usr/sbin directories.
> There is nothing that means that the contents of (/usr)/(s)bin can't
> change from one command invocation to another.  The /(s)bin sym-links
> just need to point to a valid directory.  They can easily be on the
> root-underlay file system that /usr gets mounted on top of.

Interesting concept, thanks for sharing.

Unless I misunderstand how this will work, it will create duplication of the 
fs for /bin and /sbin, which will both use extra space and require managing.

Will you mount -bind the underlying fs in fstab?

How will you make sure installations of the same binaries are installed/copied 
in both underlying and mounted /usr/* fs and kept in sync?  By changing all 
affected ebuilds?

It is a hack alright, to restore the previous default /usr functionality, so a 
useful option to consider.  If I were to be asked my preference would be to 
revert the systemd inspired changes which caused this loss of functionality.  
;-)

-- 
Regards,

Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: USE flag 'split-usr' is now global

[Mick]

On Monday, 5 August 2019 17:17:53 BST Grant Taylor wrote:
> On 8/5/19 4:49 AM, Mick wrote:

> Just because it's the same developers promoting both does not mean that
> any logic / evidence they might provide in support of /usr merge is
> inherently wrong.  We should judge the merits of their logic / evidence
> on it's own, independent of what we think of their other work.  (Read:
> Don't turn this technical conversation into a character discussion.)

I am not entertaining ad hominem attacks on whoever may have been involved in 
such decisions.  Only the impacts of such decisions on gentoo in particular.


> > Sure, but for how much longer?
> 
> /me looks around for something that he must have missed.

I probably used an incorrect figure of speech and caused confusion.  We're 
only discussing the merge of /bin and /sbin to /usr/bin and /usr/sbin (it 
seems to be more nuanced than this though - see gentoo forums thread further 
down).  However, the takeover of Linux in general by systemd architectural 
changes is a fact.  It is also a fact gentoo has been changed a lot to 
accommodate systemd.  I have set USE="-systemd" but still end up with service 
unit files on my system, unless I take additional steps to remove/mask them.  
At some point udev/dbus/what-ever will be irrevocably linked to systemd, just 
because its devs do not care for alternative architectures.  Some packages 
require systemd components, like (e)logind, and so on.  Some years ago eudev 
was forked from systemd with a stated aim at the time to also restore the 
borked separate /usr without an initrd - did this ever happen?  There is a 
direction of travel and it has been influenced heavily by systemd design 
decisions.


> I didn't see anything about combining bin and sbin.

There isn't any - I haven't seen it either.  Sorry if I confused the point.


> Let's focus on the /usr merger discussion /first/.  Then we can address
> bin vs sbin.
> 
> > You need to check the direction of travel here and how long before a
> > particular dev priesthood which imposes initrd, systemd and a single
> > partition image, or whatever suits their mass market use cases agenda,
> > foists their choice upon *all* users.
> 
> Again, focus on technical, this is not a character discussion.
> 
> I also don't think they will be successful in foisting their ideas on
> *all* users.  I'm quite confident that there will always be some random
> distro that does not subscribe to them.  Maybe the usable percentage
> will be quite small.  But any distro that doesn't tow the line means
> that not /all/ distros follow the agenda.  (Yes, I'm saying distro
> instead of user, but I think you understand either way.)
> 
> I personally don't like the idea of /{,s}bin being a sym-link to
> /usr/\1.  I like the idea that / (root) and /usr are (or can be)
> separate file systems.  That being said, I've not actually /needed/ them
> to be separate file systems in quite a while.  I may have /wanted/ them
> to be separate so that I could utilize different file system types for /
> (root) and /usr.

Yes, same here, but this is primarily because since gentoo's change in this 
area I moved away from using a separate /usr fs to avoid having to use an 
initrd.


> Looking back at all the systems that I've administered for the last ~20
> years, almost all of them did use a single file system for / (root) and
> /usr.  Sure, they likely had other file systems as well; /var, /tmp, and
> /home most likely.
> 
> Given how Unix / Linux is changing—evolving—where and how it's being
> used, I can see how there is no longer any need for the separate file
> systems.  I think this lack of need combined with the additional
> complexity is evolving into a desire for a single file system for /
> (root) and /usr.  Since I can't point to any specific use case—in about
> 90 seconds—that a single file system would break, I'm pausing and thinking.
> 
> So, since we're discussing it, I invite you, and anyone else, to list
> pros and / or cons for either methodology.  I'm quite interested in
> learning what others think.

I have given one benefit of keeping a separate fs for /usr, mounting it read 
only for daily use.  Or you could have a shared NFS partition across various 
client PCs, facilitating system duplication.  You could also have /usr on a 
faster disk for performance reasons.

A benefit of /var being separate (or wherever www/, logs/, mail/ and databases 
are stored) is so that if it runs out of space the remaining system is not 
brought to its knees.

Ditto for /home, with the addition of encrypting user's data/partition and 
mounting it with nosetuid (to prevent the users from running their own secret 
root shell).

So at least two reasons, helping to manage (simply) access rights and space 
are valid enough reasons IMHO to not remove a separate /usr option from 
gentoo, but I'm interested to hear what others think.  One might argue you 
still retain the option of using a separate /usr, but with the 

[gentoo-user] Re: HACK: Boot without an initramfs / initrd while maintaining a separate /usr file system.

[Ian Zimmerman]

On 2019-08-04 19:36, Grant Taylor wrote:

> Create the bin and sbin directories inside of the /usr directory that
> is the mount point so that they are on the underlying file system that
> /usr is mounted over top of.  Then copy the needed binaries to the
> /usr/bin & /usr/sbin directories on the underlying file system.  That
> way, /sbin/fsck -> /usr/sbin/fsck still exists even before the real
> /usr is mounted.

Don't you have to go through some extra hoops (a flag to the mount
command or something) to mount over a non-empty directory?

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

[gentoo-user] Re: USE flag 'split-usr' is now global

[Ian Zimmerman]

If I correctly remember the post by Lennart that spawned this entire
debate, there were and are genuine technical reasons why a separate /usr
filesystem doesn't really work anymore.  Perhaps fixable _if_ all package
developers (other than init) paid attention but that's not going to
happen.

Now of course there is some leap from the above to making /bin and
/usr/bin the same _directory_.  AFAIK there is no good reason for that
other than making it easier to write initscripts (or units).  I'm not
going to opine how good a reason is that :P

Myself, I just have /usr on the rootfs.  I don't have an initramfs; when
I need a "rescue" environment I boot from a USB stick, not necessarily
gentoo.  Devuan seems to be the best for this kind of thing nowadays.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

Re: [gentoo-user] Re: USE flag 'split-usr' is now global

[Grant Taylor]

On 8/5/19 5:34 PM, Mick wrote:
I am not entertaining ad hominem attacks on whoever may have been 
involved in such decisions.  Only the impacts of such decisions on 
gentoo in particular.


:-)

I probably used an incorrect figure of speech and caused confusion. 
We're only discussing the merge of /bin and /sbin to /usr/bin and 
/usr/sbin (it seems to be more nuanced than this though - see gentoo 
forums thread further down).


I started to read to be able to be informed when drafting my reply. 
Emphasis on "started".  The first comment to the quote makes me think 
that it's going to be a lively discussion.  I'll read it later as time 
permits and respond accordingly.


However, the takeover of Linux in general by systemd architectural 
changes is a fact.  It is also a fact gentoo has been changed a lot 
to accommodate systemd.  I have set USE="-systemd" but still end 
up with service unit files on my system, unless I take additional 
steps to remove/mask them.  At some point udev/dbus/what-ever will be 
irrevocably linked to systemd, just because its devs do not care for 
alternative architectures.  Some packages require systemd components, 
like (e)logind, and so on.  Some years ago eudev was forked from 
systemd with a stated aim at the time to also restore the borked 
separate /usr without an initrd - did this ever happen?  There is 
a direction of travel and it has been influenced heavily by systemd 
design decisions.


ACK

I think I could draw analogies with XFree86 vs Xorg vs Wayland.  In the 
beginning, nobody wants to actively stop development of the old method. 
But in the end, nobody wants to devote any effort to keep bring the old 
method forward.  Thus the old method gets left behind.


I'm not saying it's correct, or not, just that it is the nature of things.

There isn't any - I haven't seen it either.  Sorry if I confused 
the point.


Actually, the quote in the first forum post you linked to has the following:

/sbin->usr/bin
/usr/sbin->bin

That takes four directories (/bin, /sbin, /usr/bin, /usr/sbin) and 
combines them into two (/sbin & /usr/bin and /bin & /usr/sbin) but it 
also crosses bin & sbin as well as going opposite directions with the 
links.  —  Yuck!!!


Yes, same here, but this is primarily because since gentoo's change in 
this area I moved away from using a separate /usr fs to avoid having 
to use an initrd.


ACK

I have given one benefit of keeping a separate fs for /usr, mounting 
it read only for daily use.  Or you could have a shared NFS partition 
across various client PCs, facilitating system duplication.  You could 
also have /usr on a faster disk for performance reasons.


ACK

A benefit of /var being separate (or wherever www/, logs/, mail/ 
and databases are stored) is so that if it runs out of space the 
remaining system is not brought to its knees.


ACK


Ditto for /home, with the addition of encrypting user's data/partition 
and mounting it with nosetuid (to prevent the users from running 
their own secret root shell).


ACK

So at least two reasons, helping to manage (simply) access rights and 
space are valid enough reasons IMHO to not remove a separate /usr 
option from gentoo, but I'm interested to hear what others think.


Agreed..

One might argue you still retain the option of using a separate /usr, 
but with the new added restriction of being obliged to engage in 
boot time gymnastics with an initrd, LVM, your mount-bind solution 
and whatever else.


I don't have any current first hand experience with /usr being a 
separate file system without using an initramfs / initrd.  So I'm going 
to have to take what you, and others, say on faith that it can't 
/currently/ be done.  But I've got to say, that I find that idea 
disturbing and highly suspicious.


I'd be curious for pointers to bugs about this if you have them handy. 
Please don't look, I'll dig later if I'm sufficiently motivated.


However, workarounds which add complication (remove simplicity and 
flexibility) to fix something after breaking it, is what all this 
argument is about.  Such changes remove choice.


Ya.  It's sort of like painting yourself into a corner because one (or 
more) too many bad decisions were made in the past.  I'd much rather 
admit that a bad decision was made, undo it, and move forward again with 
new knowledge.  Sadly, IMHO not enough people do that.



I'll try not to mess up the thread.  :-)


:-D

I'll try as well.  But I'm betting that we're both human.

Please do, the systemd merge refers merging /bin to /usr/bin and 
/sbin to / usr/sbin.


https://fedoraproject.org/wiki/Features/UsrMove

However, this gentoo thread mentions further merging, which made my 
head spin:


https://forums.gentoo.org/viewtopic-p-7902764.html


Ya.  I need to read that thread in detail.

The following bit concerns me.  I do hope that it's a typo.

/sbin->usr/bin
/usr/sbin->bin

You're probably correct.  In any case, the initial move of 
subdirectories of the / fs to different 

Re: [gentoo-user] Re: HACK: Boot without an initramfs / initrd while maintaining a separate /usr file system.

[Manuel McLure]

On Mon, Aug 5, 2019 at 4:53 PM Ian Zimmerman  wrote:

>
> Don't you have to go through some extra hoops (a flag to the mount
> command or something) to mount over a non-empty directory?
>
>
Not in my experience, I've done it many times (sometimes even on purpose :)
)
-- 
Manuel A. McLure WW1FA  
...for in Ulthar, according to an ancient and significant law,
no man may kill a cat.   -- H.P. Lovecraft

Re: [gentoo-user] Re: HACK: Boot without an initramfs / initrd while maintaining a separate /usr file system.

[Grant Taylor]

On 8/5/19 8:45 PM, Grant Taylor wrote:

Even bigger hack.


I wouldn't be me if I didn't lob these two words out there:

mount namespaces

/me will see himself out now.



--
Grant. . . .
unix || die

Re: [gentoo-user] Re: HACK: Boot without an initramfs / initrd while maintaining a separate /usr file system.

[Jack]

On 2019.08.05 19:52, Ian Zimmerman wrote:

On 2019-08-04 19:36, Grant Taylor wrote:

Create the bin and sbin directories inside of the /usr directory  
that is the mount point so that they are on the underlying file  
system that /usr is mounted over top of.  Then copy the needed  
binaries to the /usr/bin & /usr/sbin directories on the underlying  
file system.  That way, /sbin/fsck -> /usr/sbin/fsck still exists  
even before the real /usr is mounted.


Don't you have to go through some extra hoops (a flag to the mount  
command or something) to mount over a non-empty directory?


As others have said, no.  However, I keep wondering if an overlay file  
system might not be of some use here.  Start with /bin, containing only  
what's necessary to boot before /usr is available.  Once /usr is  
mounted, overlay mount /usr/bin on /bin (or would it be the other way  
around?)

Re: [gentoo-user] Re: HACK: Boot without an initramfs / initrd while maintaining a separate /usr file system.

[Grant Taylor]

On 8/5/19 6:28 PM, Jack wrote:
However, I keep wondering if an overlay file system might not be of 
some use here.  Start with /bin, containing only what's necessary to 
boot before /usr is available.


I wonder how much of what would need to be in the pre-/usr /bin 
directory can be provided by busybox.  (Assuming that busybox is 
compiled with everything living in / (root).


Once /usr is mounted, overlay mount /usr/bin on /bin (or would it be 
the other way around?)


An overlay mount (mount -o bind /usr/bin /bin) would be an additional 
mount.  Which in and of itself is not a bad thing.  But the sym-link 
from /bin -> /usr/bin would avoid the additional mount.  Admittedly, you 
might need one additional (bind) mount somewhere to be able to access 
the underlay while /usr is mounted.


Unless

...

Even bigger hack.

What if the underlay (/ (root)) file system had the following structure:

/bin -> /usr/bin
/usr/bin -> /.bin

That would mean that the pre-/usr /bin contents would still be 
accessible via /.bin even after /usr is mounted.  And /bin would still 
point to /usr/bin as currently being discussed with /usr merge.




--
Grant. . . .
unix || die

Re: [gentoo-user] Re: HACK: Boot without an initramfs / initrd while maintaining a separate /usr file system.

[Grant Taylor]

On 8/5/19 5:52 PM, Ian Zimmerman wrote:
Don't you have to go through some extra hoops (a flag to the mount 
command or something) to mount over a non-empty directory?


Nope.

I don't recall ever needing to do anything like that in Linux.

I do know that other traditional Unixes are more picky about it.  AIX 
will refuse to use a populated directory as a mount point.


As I type this, perhaps ZFS on Linux complains, but I don't recall.



--
Grant. . . .
unix || die

Re: [gentoo-user] No profile 17.1 for 32-bit (x86) installs?

[Raffaele Belardi]

Walter Dnes wrote:

   I just updated Gentoo on my old backup machine, an 11-year-old Dell
Inspiron 530 desktop, and there's no mention of profile 17.1 in either
"eselect profile list" or "eselect news list".  I'm not looking for
extra hassle, but I wanted to make sure I didn't miss anything obvious.


Same here, nothing to worry about:

"In the new profiles, the lib->lib64 compatibility symlink is removed.
64-bit libraries need to be installed directly to lib64.  /lib
and /usr/lib become real directories, that are used for cross-arch
and native non-library packages (gcc, clang) and 32-bit libraries
on the multilib profile (which improves compatibility with prebuilt x86
packages)." [1]

On x86 system there is no lib32 nor lib64, everything is already under lib.

raffaele

[1] 
https://www.gentoo.org/support/news-items/2019-06-05-amd64-17-1-profiles-are-now-stable.html

[gentoo-user] No profile 17.1 for 32-bit (x86) installs?

[Walter Dnes]

  I just updated Gentoo on my old backup machine, an 11-year-old Dell
Inspiron 530 desktop, and there's no mention of profile 17.1 in either
"eselect profile list" or "eselect news list".  I'm not looking for
extra hassle, but I wanted to make sure I didn't miss anything obvious.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications