[gentoo-dev] Re: usr merge

[gentoo-dev] Re: usr merge

[Duncan]

Alexis Ballier posted on Tue, 05 Apr 2016 12:10:51 +0200 as excerpted:

> On Tuesday, April 5, 2016 3:19:59 AM CEST, William Hubbs wrote:
> [...]
>> I don't think creating usr merged stages would be that difficult. I
>> think it would just be a matter of creating a new version of baselayout
>> that puts these symlinks in place:
>>
>> /bin->usr/bin /lib->usr/lib /lib32->usr/lib32 /lib64->usr/lib64
> 
> (OT: maybe it'd be a good oportunity to kill SYMLINK_LIB too :p)
> 
>> /sbin->usr/bin /usr/sbin->bin
>>
>> Once that is in place in a new baselayout, I think portage's colission
>> detection would be able to catch files that had the same names and were
>> originally in different paths when building the new stages.
> 
> 
> I think that prior to that we have to ensure that packages with intra
> collisions are not merged: What happens with current coreutils ebuilds
> that install, e.g., /bin/seq and a /usr/bin/seq symlink to it ?
> I haven't looked at the actual code, thus I can only assume there are no
> guarantees, which is definitely bad.

As I said in the other thread, I'm running merged /usr and bin/sbin here, 
except that I merged them the other way, with /usr -> . so everything in 
/usr is now in /.

Portage has long "just worked" in that regard, tho I've no idea whether 
the other PMs do.  Portage has enough intelligence to avoid replacing a 
file with a symlink pointing to it (and thus to itself once the 
replacement is done), regardless of which way the directory symlinks 
point.

As such, coreutils "just works".  If the two would end up in the same 
canonical location, the file wins and the symlink isn't installed.

There are a few individual package bugs, including one open right now 
where the gcc-config ebuild does an unconditional rm -f of any old 
versions found in its old sbin location, even when it removes the 
executable it just installed into the bin location, because they're the 
same canonical location.  (Bug number for that and other bugs in the 
reply on the other thread.)  And cmake can get mixed up in some instances 
so a few packages (baloo) have problems with some cmake versions.

But the bugs aren't with portage, they're with the ebuild or the upstream 
sources, and the number of them I've run into in the two years plus I've 
been running merged can fit on one hand.  Certainly, they're few enough 
to deal with on a case-by-case basis.

>> I put some thought also in how to nigrate live systems, and I'm not
>> sure what the best way to do that is. I wrote a script, which would do
>> it in theory, but I haven't tested because I only have one system and
>> if it breaks it the only way back would be to reinstall.
> 
> 
> Does it behave properly wrt portage's way of tracking of package files?
> I remember that modifying files owned by portage used to cause issues.

What I did for my migration was simply move everything from /usr to / and 
create the /usr -> . symlink.  I did that with mc, and kept it running 
just in case I ended up not being able to start something, until I had 
the symlink in place and had tested starting various things, including X/
KDE, so I knew it was working.

Similarly for the sbin -> bin moves and symlinks.

The moves worked fine, and with the directory symlinks replacing the old 
dirs, everything else, including portage on updates after that, worked 
just fine.


There are a couple things that behave slightly differently regarding 
packages, that one needs to be aware of, but in general it just works.  
Those couple things are:

1) Unless one is sure of the actual install path used and uses it, equery 
belongs and I assume q and similar tools with the same query, need the 
bare file name, not the full path, because you might use the wrong one.

For instance, /bin/grep, /sbin/grep, /usr/sbin/grep, and /usr/bin/grep, 
are all the same file due to directory level symlinks.  However, if you 
try equery belongs with all four paths, only one of them will return the 
hit you're looking for.

Easily solved by simply doing equery belongs grep (no path), and letting 
equery supply the installed path in its results.  That's actually how I 
find out which path a file was actually installed to, these days, as 
well. =:^)

2) revdep-rebuild will, in its default configuration, end up processing 
files using all paths.  So grep, to use the same example as above, will 
be processed four times, one each for /bin and /sbin, /usr/bin and /usr/
sbin.

While it's possible to reconfigure revdep-rebuild to ignore three of 
those paths and only check one of them (and similarly, ignore one of 
/lib64 and /usr/lib64, etc), doing so will result in revdep-rebuild 
complaining about unowned broken binaries if they're installed using a 
different path than the one it processed.

That's not a big problem, because equery belongs <file> (without the 
path) will tell you what owns it as well as the installed path it used, 
and then that package can be remerged manually, if needed.

So with revdep-rebuild, it's a tradeoff.  You can either have it taking 
4X as long to resolve executables and 2X as long to resolve libs, but 
handle the rebuilds automatically when it's done, or shorten its 
processing time by only processing one of the paths, and then have to 
figure out what owns some of the files it complains about and remerge 
them manually.

(FWIW, I chose the short but often manual method when I first setup the 
merge, as the revdep-rebuild shell script was slow and processing things 
four times took way too long.  But the newer python-based revdep-rebuild 
is far faster, and I've been going to switch back to letting it process 
all the paths now so it handles all its rebuilds automatically once 
again.  But I've yet to get around to switching the config around, so 
it's still using the short but often semi-manual method.)



> Also, I think your script may not work:
> 
> # copy binaries for dir in /bin /sbin /usr/sbin; do
> 	run_command cp -a $dir/* /usr/bin
> done
> 
> ---> Here it is important to ensure nothing /usr/bin/ is a symlink to
> /bin,
> otherwise this would just copy, e.g., /bin/seq onto /bin/seq

Very good point!

When I did it the migration here, I did the move (in mc) skipping files 
that existed in the new location.  There were twenty or so skipped, IIRC, 
few enough to manually investigate.  From memory, all of them were 
symlinks in one place or the other, so I could delete the symlinks and 
move the rest of the files over, without hitting skips the second time.

Obviously a naive move will replace some of the files with dead (once 
replaced) symlinks, so valid point raised. =:^)

> # Create the /usr merge compatibility symlinks for dir in /bin /sbin; do
> run_command rm -rf $dir
> 
> ---> where are the 'ln' and 'rm' taken from after this step ?
> If this fails here, you're also leaving the system in a broken state.
> 
> run_command ln -s usr/bin $dir done

In my case I was using the mc binary, which continued to run after the 
transfer, so it wasn't an issue.

But using the individual ln and rm binaries, while they'll still be on 
the path, you may need to run hash -r in the shell so it forgets the old 
location and checks the path again.

Similar thing for the libs, since the lib cache will be screwed after the 
move, until the symlink has been created so the old paths work again, at 
least.  In my case I was using the mc binary which continued to run and 
thus could be used to create the symlink, but for one-shot executables 
like ln, that could be an issue.

One way around the problem would be to create a few static-linked 
executables for the purpose, and ship them in a tarball that's unpacked 
to an unchanging tmp location for the run, so they can be called from 
there to finish up regardless of whether the dynamically linked normal 
executables can still be invoked.

Smart use of the shell's builtin read, echo and redirection could 
probably do some of it too, but can ln be emulated using shell builtins?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: usr merge

[Jonathan Callen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 04/05/2016 12:53 PM, Alexis Ballier wrote:
> On Tuesday, April 5, 2016 2:26:53 PM CEST, Duncan wrote:
>> 
>> As I said in the other thread, I'm running merged /usr and
>> bin/sbin here, except that I merged them the other way, with /usr
>> -> . so everything in /usr is now in /.
>> 
>> Portage has long "just worked" in that regard, tho I've no idea 
>> whether the other PMs do.  Portage has enough intelligence to
>> avoid replacing a file with a symlink pointing to it (and thus to
>> itself once the replacement is done), regardless of which way the
>> directory symlinks point.
>> 
>> As such, coreutils "just works".  If the two would end up in the
>> same canonical location, the file wins and the symlink isn't
>> installed.
> 
> What about the unlikely case with two files ?
> 

Having actually run this way myself, I did find one case that I
haven't filed a bug for yet: the plymouth ebuild tries to install
symlinks in /sbin pointing at /usr/sbin, and portage chose to install
the symlinks instead of the real files, for whatever reason
(apparently because the $ED/sbin directory is created after the
$ED/usr directory).  Because of this, it might be best to ensure that
packages that do install in both places are modified not to do so
under such a configuration.

- -- 
Jonathan Callen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJXBFMbAAoJEEIQbvYRB3mg2e4P/2lPBxpyjY311LP7gN2Nndn4
Dd4EtFbh8tQWoedPJQgr2CIeVgpPFA7l/stuvcoZAqLVDuFnn4ZmMWSIQOgHmgPp
+mIiCDPuLMjhqw/yINlTGGVVhffHFG4PrHcd2MwP6Gm9ME0NH8+Z0cgAznHsHQ5c
lgNdfXDsgBdrSrKu5/JTw7jDOv1A1TwIACJoLpEYZTlVCBClp6J01kqH1oyEzPf8
FO6fqAvFJXCq1um6/+ve8LOpS0OLBpg0dh5kcdkFgV1430FqNwUczMINhav5J0mp
qTAIZTO4OSLxyswOUiKoxROl4xrQ1ByYi1ZF7g24oh7M1fmkreNClrhJ1kA3M6ff
OJ3LJ6m350LEIVzAED66pnKOTNDOLJSaz6MsPk8CHzuJ2RCMatKjBA3Lb0tkkepp
5LOCBXbnVfSPRI+TQM91cHXVnh87T1zZSeGT8qOCfNoF7rFWNSlpIRnxMeeFlv2n
0kXfJo9YeiUAA9BYXBryMIsWr4StM4I9oq0ITc7h9WmB/WKW6zJhl7WHd7SgiePW
Lb2fHJtz0R8dUIc53Yxuls1Cbt8AUAFYmN9Ve615cVLs3+jO8HWmwiuFfiYH71k1
JaS51cgBjPBnQuiET0iNxu/gjIekwIjoNptn/cCr9IZ4jnZ9L13ai6Wug49vUwwK
bed4Tt3nl8GSbRtlV+rk
=PHpB
-----END PGP SIGNATURE-----

[gentoo-dev] Re: usr merge

[Duncan]

Richard Yao posted on Wed, 06 Apr 2016 00:15:58 -0400 as excerpted:


>> On Apr 4, 2016, at 9:19 PM, William Hubbs <williamh@gentoo.org> wrote:
>> 
>> All,
>> 
>> I thought that since the usr merge is coming up again, and since I lost
>> track of the message where it was brought up, I would open a new thread
>> to discuss it.
>> 
>> When it came up before, some were saying that the /usr merge violates
>> the fhs. I don't remember the specifics of what the claim was at the
>> time, (I'm sure someone will point it out if it is still a concern).
> 
> Here are the violations:
> 
> http://refspecs.linuxfoundation.org/FHS_3.0/
fhs-3.0.html#binEssentialUserCommandBinaries
> 
> http://refspecs.linuxfoundation.org/FHS_3.0/
fhs-3.0.html#sbinSystemBinaries
> 
> http://refspecs.linuxfoundation.org/FHS_3.0/
fhs-3.0.html#libEssentialSharedLibrariesAndKern

(Those links are wrapped and I'm not bothering to jump thru the hoops to 
unwrap them, since readers can either unwrap them manually or refer to 
the parent post I'm quoting for the unwrapped versions.)

If those are the "violations", then putting everything in /usr and making 
the /bin and /sbin locations symlinks isn't going to be a problem, since 
/bin and /sbin are specifically allowed to contain symlinks to the 
executables, instead of the executables themselves, and if the dirs 
themselves are symlinks to the locations in /usr with the files, that 
fulfills that requirement.

And the requirement for /lib is rather vague, saying only that it 
contains the libs linked by the executables in /bin and /sbin.  So once /
bin and /sbin are symlinks to the dirs with the executables, /lib (or the 
arch-specific alternative libdirs) can be a symlink as well.

Tho I must say doing the reverse, making either /usr itself or /usr/bin 
and /usr/sbin symlinks to the root dirs, as I did here, actually makes 
more sense and bends the rules less.

Basically, what the FHS says, at least in the 3.0 version you linked, is 
that the executables must be reachable via whatever specific path, but 
using symlinks to do it is fine.

Which means the merge is allowed, as long as symlinks allow the 
executables to be reached by their specifically defined paths.  And I'm 
not aware of anyone seriously proposing that said symlinks be omitted, 
so...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: usr merge

[Richard Yao]

On 04/06/2016 01:34 AM, Duncan wrote:
> Richard Yao posted on Wed, 06 Apr 2016 00:15:58 -0400 as excerpted:
> 
> 
>>> On Apr 4, 2016, at 9:19 PM, William Hubbs <williamh@gentoo.org> wrote:
>>>
>>> All,
>>>
>>> I thought that since the usr merge is coming up again, and since I lost
>>> track of the message where it was brought up, I would open a new thread
>>> to discuss it.
>>>
>>> When it came up before, some were saying that the /usr merge violates
>>> the fhs. I don't remember the specifics of what the claim was at the
>>> time, (I'm sure someone will point it out if it is still a concern).
>>
>> Here are the violations:
>>
>> http://refspecs.linuxfoundation.org/FHS_3.0/
> fhs-3.0.html#binEssentialUserCommandBinaries
>>
>> http://refspecs.linuxfoundation.org/FHS_3.0/
> fhs-3.0.html#sbinSystemBinaries
>>
>> http://refspecs.linuxfoundation.org/FHS_3.0/
> fhs-3.0.html#libEssentialSharedLibrariesAndKern
> 
> (Those links are wrapped and I'm not bothering to jump thru the hoops to 
> unwrap them, since readers can either unwrap them manually or refer to 
> the parent post I'm quoting for the unwrapped versions.)
> 
> If those are the "violations", then putting everything in /usr and making 
> the /bin and /sbin locations symlinks isn't going to be a problem, since 
> /bin and /sbin are specifically allowed to contain symlinks to the 
> executables, instead of the executables themselves, and if the dirs 
> themselves are symlinks to the locations in /usr with the files, that 
> fulfills that requirement.

Alexis Ballier pointed out that the following had been added to make
this okay:

> The following directories, or symbolic links to directories, are
required in /.

As far as the Single UNIX Specification is concerned, this sort of thing
is okay. The Linux Filesystem Hierarchy Standard that further restricts
things had not been updated to permit this until mid-2015.

> And the requirement for /lib is rather vague, saying only that it 
> contains the libs linked by the executables in /bin and /sbin.  So once /
> bin and /sbin are symlinks to the dirs with the executables, /lib (or the 
> arch-specific alternative libdirs) can be a symlink as well.
> 
> Tho I must say doing the reverse, making either /usr itself or /usr/bin 
> and /usr/sbin symlinks to the root dirs, as I did here, actually makes 
> more sense and bends the rules less.

I agree, but Solaris picked the other way and RHEL followed. My opinion
is that we should support both. Any automated upgrade scripts that do
the /usr merge on behalf of users should detect this state and leave it
alone.

That being said, I am not of the opinion that we should migrate existing
installs or drop support for the older layout for a couple reasons. One
is that existing installs will see no benefit from this layout change.
The other is that supporting the existing installs is necessary so that
we can still do QA on them.

I suspect breakage will be more likely with the older layout than the
newer one. If we end up not migrating existing installs automatically
(maybe via a profile change), we might be able to get away with doing
the majority of testing with the older one. If we do not want to do that
long term, we could always do it for something like a year to minimize
the effect on the userbase.

A portage QA check could be made to detect the presence of files in both
/{bin,sbin,lib,lib64,lib32} and /usr/{bin,sbin,lib,lib64,lib32} to make
verifying that packaging does not do anything weird that would
negatively affect the newer layout easier when testing with the older
layout.

The only exception being the linker scripts. There are at least a few of
them still around:

richard@desktop ~ $ for fA in /lib/*; do
> fB=/usr/lib/${fA##*/};
> [[ -f $fA && -f $fB ]] && echo "$fB";
> done
/usr/lib/libeinfo.so
/usr/lib/libpamc.so
/usr/lib/libpam_misc.so
/usr/lib/libpam.so
/usr/lib/librc.so
richard@desktop ~ $ cat /usr/lib/librc.so
/* GNU ld script
   Since Gentoo has critical dynamic libraries in /lib, and the static
versions
   in /usr/lib, we need to have a "fake" dynamic lib in /usr/lib,
otherwise we
   run into linking problems.  This "fake" dynamic lib is a linker
script that
   redirects the linker to the real lib.  And yes, this works in the cross-
   compiling scenario as the sysroot-ed linker will prepend the real path.

   See bug https://bugs.gentoo.org/4411 for more info.
 */
OUTPUT_FORMAT ( elf64-x86-64 )
GROUP ( /lib64/librc.so )

I am a bit out of date on the status of these. Do we still need them? If
we have not already, we could patch GNU ld to eliminate the need for this.

> Basically, what the FHS says, at least in the 3.0 version you linked, is 
> that the executables must be reachable via whatever specific path, but 
> using symlinks to do it is fine.
> 
> Which means the merge is allowed, as long as symlinks allow the 
> executables to be reached by their specifically defined paths.  And I'm 
> not aware of anyone seriously proposing that said symlinks be omitted, 
> so...

My mistake. I had not spotted that change in my cursory read. At least
we now know that this is not a Linux FHS violation anymore. :)

[gentoo-dev] Re: usr merge

[Duncan]

Richard Yao posted on Wed, 06 Apr 2016 10:04:05 -0400 as excerpted:

> That being said, this is only useful for new installs where people want
> to take advantage of the Solaris way of doing management. It should have
> no benefit for existing installs.

I don't know enough about solaris to comment on that, but my (reverse) 
merging /usr and bin/sbin to / certainly had benefits for my existing 
install.  The biggest one was no longer having the brain overhead of 
having to track whether something's in /usr or direct in /, or in the bin 
or sbin location in /usr or /.  If it's an on-path executable that I 
didn't manually create/install myself, it's now in /bin as the fully 
dereferenced canonical path, tho /usr/bin /sbin, and /usr/sbin also work 
via symlinks, no questions asked.  Similarly, libs are found in /lib64 as 
the fully dereferenced canonical path, tho /lib, /usr/lib64 and /usr/lib 
all work as well, via symlinks.  =:^)

There remains a slight down side in that the PM's idea of where the files 
are located may differ in that it's one of the symlinked versions, and 
various standard paths are slightly less efficient due to having to 
dereference possibly multiple symlinks, but automatic and fast tracking 
of such things while minimizing the wetware tracking load is what 
computers excel at, so on balance I consider it a pretty large benefit.

So there's certainly benefit for existing installs. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: usr merge

[Duncan]

William Hubbs posted on Thu, 07 Apr 2016 09:40:49 -0500 as excerpted:

> After the testing period is over, I'm confused about why we should
> support both layouts. With separate usr without initramfs gone, the usr
> merge is transparent to end users because of the symbolic links in /, so
> there should be no reason to keep supporting both layouts once we are
> satisfied with the migration process.

Because we're Gentoo, and gentooers tend to have rather strong opinions 
on what sort of choices we should be able to make about things like that.

Honestly, that's going to look to a lot of people like another of the 
systemd/RedHat alliance overreaches and they're not going to go for it, 
simple as that.  People are likely to feel strongly enough about it that 
we'll be risking triggering a distro split.  The ability to make that 
sort of choice is /why/ they are on gentoo.

So by all means, present it as an option, document it in the handbooks, 
and even make it the default (and we all know how strongly people feel 
about even changing a default after the eudev debate), but I don't think 
it's a fight worth having to take away the other choices.  At least not 
now.  Maybe in five or ten years, after another generation of devs has 
come and gone, if the new one isn't interested in supporting the 
alternative any longer.

(Again, I say this as one who has already done the merge here, if in 
reverse, and who fully intends to setup new systems the same way as well.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: usr merge

[Rich Freeman]

On Thu, Apr 7, 2016 at 11:12 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> William Hubbs posted on Thu, 07 Apr 2016 09:40:49 -0500 as excerpted:
>
>> After the testing period is over, I'm confused about why we should
>> support both layouts. With separate usr without initramfs gone, the usr
>> merge is transparent to end users because of the symbolic links in /, so
>> there should be no reason to keep supporting both layouts once we are
>> satisfied with the migration process.
>
> Because we're Gentoo, and gentooers tend to have rather strong opinions
> on what sort of choices we should be able to make about things like that.
>

I'm trying to think of whether offering a choice really costs us
anything.  The main issue I see here is that the compatibility
symlinks only go one way.

#!/bin/bash will work whether you've done a usr merge or not
#!/usr/bin/bash will probably only work if you've done the usr merge
#!/usr/bin/python will work whether you've done a usr merge or not
#!/bin/python will probably only work if you've done the usr merge

It seems like a bit of a challenge to try to make sure that all your
links are to wherever the original package tries to install files when
on the system you are developing/testing on everything is in one
place.

We could of course require that maintainers accept patches to fix
these kinds of broken links if they're offered, but users would be
more likely to run into temporary breakage if they didn't use the
merge unless we can come up with a way to offer compatibility in both
directions.

Unless there is a bigger problem lurking it probably still should be
up to the user.

-- 
Rich

Re: [gentoo-dev] Re: usr merge

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]

On Thu, Apr 07, 2016 at 11:42:01AM -0400, Rich Freeman wrote:
> On Thu, Apr 7, 2016 at 11:12 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> > William Hubbs posted on Thu, 07 Apr 2016 09:40:49 -0500 as excerpted:
> >
> >> After the testing period is over, I'm confused about why we should
> >> support both layouts. With separate usr without initramfs gone, the usr
> >> merge is transparent to end users because of the symbolic links in /, so
> >> there should be no reason to keep supporting both layouts once we are
> >> satisfied with the migration process.
> >
> > Because we're Gentoo, and gentooers tend to have rather strong opinions
> > on what sort of choices we should be able to make about things like that.
> >
> 
> I'm trying to think of whether offering a choice really costs us
> anything.  The main issue I see here is that the compatibility
> symlinks only go one way.
> 
> #!/bin/bash will work whether you've done a usr merge or not
> #!/usr/bin/bash will probably only work if you've done the usr merge
> #!/usr/bin/python will work whether you've done a usr merge or not
> #!/bin/python will probably only work if you've done the usr merge
 
 That's correct, but you shouldn't be using shebangs like the second and
 fourth ones now either. The standard shebangs (the first and third
 ones) are fully compatible pre and post usr merge.

 If people decide to start using non-standard shebangs like your second
 and fourth ones above, that is wrong and should be stopped.

 William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] Re: usr merge

[Rich Freeman]

On Thu, Apr 7, 2016 at 11:46 AM, William Hubbs <williamh@gentoo.org> wrote:
>> #!/bin/bash will work whether you've done a usr merge or not
>> #!/usr/bin/bash will probably only work if you've done the usr merge
>> #!/usr/bin/python will work whether you've done a usr merge or not
>> #!/bin/python will probably only work if you've done the usr merge
>
>  That's correct, but you shouldn't be using shebangs like the second and
>  fourth ones now either. The standard shebangs (the first and third
>  ones) are fully compatible pre and post usr merge.
>
>  If people decide to start using non-standard shebangs like your second
>  and fourth ones above, that is wrong and should be stopped.
>

Of course, but how will this be easily prevented?  If a package
(whether new or a routine update) changes a path somewhere it would
work just fine in testing, due to the compatibility symlinks.  I can't
really think of any straightforward way to detect this in an automated
fashion either, at least not 100% reliably.

Upstream could introduce these paths without a developer noticing, or
a developer might just not notice that netstat and bzip2 and more is
in /bin, but lsof and xz and less are in /usr/bin.  Since we do not
have any policy as to what has to go in either path any of these are
subject to change at any time as well.  Heck, we struggle just to get
people to stop using /etc/init.d/functions.sh.

Again, I don't see this as a reason not to make it optional, but I
suspect that we will find bugs here from time to time which users who
run with the split /usr will have to report/fix.

-- 
Rich

[gentoo-dev] Re: usr merge

[Duncan]

M. J. Everitt posted on Fri, 08 Apr 2016 03:35:33 +0100 as excerpted:

> On 08/04/16 02:42, William Hubbs wrote:

>> The default installation location of all coreutils binaries is
>> /usr/bin, then we move everything around in the ebuild.
>> We are deviating from upstream in this example.
>>
> I would expect this isn't the only example of this in Gentoo .. we
> customise the packages to make sense to the Gentoo distro, not conform
> to a multitude of random "standards" applied by many developers. So,
> whilst I accept that its desirable to match 'upstream' - this isn't
> always going to be possible.

Agreed, and moreso, while gentoo does try to stay close to upstream in 
general, I'd argue that paths aren't the place to do that.  Instead, for 
paths, we should be sticking as close to FHS, XDG/freedesktop.org, etc, 
as makes sense (and in general it's reasonable and /does/ make sense, tho 
when the specs are designed with for instance binary distros in mind, 
they don't always).  Because there are specs, but upstreams may do all 
sorts of random things in terms of path, some of which aren't going to 
work particularly well on gentoo or other distros attempting to stay at 
least reasonably close to FHS and XDG/freedesktop.org specs.

> I would also re-iterate, as I'm sure you're aware .. there ARE
> differences between sbin and bin .. unless of course you spend all your
> time in a Rooted VM where it doesn't matter if you accidentally trash
> your system. Some of us maintain a sensible user/superuser distinction
> for a variety of reasons, and simplifying your filesystem to suit some
> particular package style doesn't really sound like good reasoning for
> causing a lot of headaches for maintainers and a distro overall.

But... the real important distinction in terms of user vs. superuser 
executables is file ownership and permissions, not the directory they're 
in.  As long as the ownership and permissions are correct, the user can 
only run what they are supposed to, regardless of whether it's in bin or 
sbin.

And as a user running the bin/sbin merge, I can tell you based on 
experience that tab-completion works differently for users vs. superusers 
with the merge just as it does without it, because again, it's based on 
ownership and permissions too, not just whether it's in the path (tho it 
must be that as well).

Besides which, users unaccustomed to the CLI (and thus not knowing about 
tab completion) don't tend to know or care where binaries are anyway, as 
they prefer menu entries, complete with (graphical) sudo or these days, 
policy-kit integration.

Which is ultimately what distros realized, bin/sbin didn't really matter 
to the general user any more, thus the bin/sbin merge, as having all 
installed executables in the same general location was easier to manage 
and didn't matter to (most) users anyway.

But again, gentoo's about choice, and I'd hate to see that choice taken 
away from gentoo's users anyway, because many of them /do/ actually care, 
quite a bit in fact, which is why they're on gentoo in the first place.
=:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] usr merge

[Damien Levac]

>  Seriously... how many people run Bluetooth keyboards on Gentoo >anyways?

That you ask such a question is concerning to me. Are we discriminating
against normal desktop users now?

-- 
Damien Levac

[gentoo-dev] Re: usr merge

[Duncan]

Rich Freeman posted on Fri, 08 Apr 2016 06:36:48 -0400 as excerpted:

> Really though the main point of merging these paths into /usr is to get
> all the static content of a distro into a single path, which can then be
> maintained as a read-only filesystem, mounted across multiple systems,
> protected using tripwire or signature checking, and so on. As has been
> pointed out the rolling release nature of Gentoo reduces some of these
> benefits somewhat.  To truly get these benefits we would also need to
> rethink how post-install configuration gets managed as was already
> pointed out.

Somewhat unrelated to the /usr or bin/sbin merge here, as (nearly) 
everything the package manager installs to any of its paths (including 
/usr, FWIW, but that's easy because my is a /usr -> . symlink) is on /, 
here, but FWIW, I actually do keep my / read-only mounted by default.

So / is only mounted writable to update and/or change configuration.  
That includes /etc/ and of course my /usr -> . symlink, as well as parts 
of /var.  The parts of /var that system services need to write into 
during normal operation (well, the ones that need to be permanent, those 
like /var/run that should be temporary are already on tmpfs mounts) are 
symlinked into subdirs under /home/var, with /home of course being 
mounted writable by default, so they can be written into during normal 
operation despite / being mounted read-only.

Works out pretty well, actually, improving reliability of /, since it's 
normally mounted ro and thus is fully stable in the event of a system 
crash.  Not having to worry about being unable to get to my system 
recovery tools on / in the event of a bad crash because / was mounted 
read-only and thus wasn't susceptible to the damage that writable-mounted 
filesystems can sustain in the event of a hard shutdown is nice. =:^)


-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] usr merge

[waltdnes]

On Fri, Apr 08, 2016 at 11:59:09PM -0400, Damien Levac wrote
> 
> >  Seriously... how many people run Bluetooth keyboards on Gentoo
> >  anyways?
> 
> That you ask such a question is concerning to me. Are we
> discriminating against normal desktop users now?

  Here's the item that really bugs me...

before - many people successfully used separate /usr, without initramfs.
A few edge cases, e.g. people with bluetooth keyboards, had to use
initramfs if they wanted a separate /usr.  The poor darlings felt left
out because they had to do extra setup work, versus the other 95%.

now - an arbitrary decree comes down that *EVERYBODY* who wants a
separate /usr needs to have initramfs.

* IT DOES NOT MAKE THINGS ANY EASIER FOR THE ORIGINAL 5% EDGE CASES *.
But the other 95% who could run separate /usr are now being told they
must run initramfs "just because".  What does it accomplish?

BTW, I'm still running a separate /usr without initramfs, and no related
problems; thank you.  If I decided to go to an edge-case setup (e.g.
Bluetooth keyboard, or ell partitions encrypted) then I could understand
being asked to run initramfs.

This is reminiscent of the "Mozilla Mentality", where everybody is
forced to the lowest common denominator.  Yes, a desktop GUI sucks on
a tablet/smartphone; I get it.  So Firefox was saddled with the
smartphone-oriented Atrocious^H^H^H^H^H^H Australis GUI, which sucks
on a desktop.  That was the last straw that drove me to Pale Moon.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sat, Apr 9, 2016 at 1:32 AM,  <waltdnes@waltdnes.org> wrote:
>
> now - an arbitrary decree comes down that *EVERYBODY* who wants a
> separate /usr needs to have initramfs.
>

The "decree" wasn't some kind of law that the Gentoo police will come
out to your house and arrest you for violating.

It was simply a recognition that we were already in a state where
booting a system without /usr mounted early can cause problems.  There
isn't really any solution to these problems (other than moving most of
/usr into /, which I doubt is the desire of anybody who puts /usr on a
separate filesystem), and it probably will only get worse.

The intent of the resolution was to not burden package maintainers to
have to cater to a use case that was already failing.

And the wording of the resolution doesn't mention the word "initramfs"
at all, precisely because we recognized that there were many ways to
work around the problem.

If you have concerns about the decision being arbitrary you might want
to read the original summary:
https://projects.gentoo.org/council/meeting-logs/20130813-summary.txt

and log:
https://projects.gentoo.org/council/meeting-logs/20130813.txt

And of course you can read the list archives from the time where the
issue was extensively discussed.

> * IT DOES NOT MAKE THINGS ANY EASIER FOR THE ORIGINAL 5% EDGE CASES *.
> But the other 95% who could run separate /usr are now being told they
> must run initramfs "just because".  What does it accomplish?

I never really got the mentality that using an initramfs is a burden.

You can boot a kernel as an EFI program, but the reality is that many
if not most users of linux on EFI use a secondary bootloader.  Heck,
back in the old days you could actually boot linux directly from the
BIOS without any secondary bootloader, but this was so impractical
that even Linus now tells people to:
bugger_off_msg:
        .ascii  "Use a boot loader.\r\n"
        .ascii  "\n"
        .ascii  "Remove disk and press any key to reboot...\r\n"
        .byte   0
(and I must say that I admire the man with the guts to not insert a
carriage return when the carriage is already on the first column)

An initramfs is just a secondary bootloader for userspace.  I almost
always use them even if I'm just booting a VM with a single partition
on it.  If something goes wrong you can fall back to a shell in the
initramfs and it is like having a rescue disk built into your system
disk.  For a more complex setup it is much more robust than relying on
the kernel to find your root, and it also lets you build with a more
module-based kernel, which has some benefits as well even if you build
kernels tailored to each host.


-- 
Rich

Re: [gentoo-dev] Re: usr merge

[Nicolas Sebrecht]

On Fri, Apr 08, 2016 at 07:58:35AM +0000, Duncan wrote:

> > I would also re-iterate, as I'm sure you're aware .. there ARE
> > differences between sbin and bin .. unless of course you spend all your
> > time in a Rooted VM where it doesn't matter if you accidentally trash
> > your system. Some of us maintain a sensible user/superuser distinction
> > for a variety of reasons, and simplifying your filesystem to suit some
> > particular package style doesn't really sound like good reasoning for
> > causing a lot of headaches for maintainers and a distro overall.
> 
> But... the real important distinction in terms of user vs. superuser 
> executables is file ownership and permissions, not the directory they're 
> in.

No. With a lightweight / I can install systems with two root filesystems
that I rsync once I'm sure there's no regression. If one won't boot
after an upgrade, I can just reboot and select the other root filesystem
in grub.

This is much more easy than anything else.

-- 
Nicolas Sebrecht

Re: [gentoo-dev] usr merge

[waltdnes]

On Sat, Apr 09, 2016 at 07:11:31AM -0400, Rich Freeman wrote

> It was simply a recognition that we were already in a state where
> booting a system without /usr mounted early can cause problems.

  For certain edge cases... yes.  But they were already using initramfs
or merging /usr into /.  I'm talking about the 95% who don't really need
it.

> I never really got the mentality that using an initramfs is a burden.

  One more piece of software that can go wrong.  You have to
maintain+configure it; e.g. sync software and library versions with
what's on the rest of the system.

> An initramfs is just a secondary bootloader for userspace.  I almost
> always use them even if I'm just booting a VM with a single partition
> on it.  If something goes wrong you can fall back to a shell in the
> initramfs and it is like having a rescue disk built into your system
> disk.

  There is single-user mode for rescue.

> For a more complex setup it is much more robust than relying on
> the kernel to find your root, and it also lets you build with a more
> module-based kernel, which has some benefits as well even if you build
> kernels tailored to each host.

  I have "Production" and "Experimental" entries in my LILO menu.  A new
kernel is always set up as the "Experimental" entry.  After running
several days without problems, I run a script which copies the data from
the "Experimental" portion to "Production".

  The only time my system had problems "finding root" was years ago when
the switch from /dev/hd* to /dev/sd* took place.  The "Experimental"
boot with the new kernel died.  I booted "Production", read the mailing
list, changed "hd" to "sd" for the "Experimental" entry, and rebooted.
After several days without problems, I made the same change to the
"Production" entry, and copied the "Experimental" portion to
"Production".

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] usr merge

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 685 bytes --]

On Sat, 9 Apr 2016 12:09:38 -0400
waltdnes@waltdnes.org wrote:

> > I never really got the mentality that using an initramfs is a
> > burden.  
> 
>   One more piece of software that can go wrong.  You have to
> maintain+configure it; e.g. sync software and library versions with
> what's on the rest of the system.

Errm, have you ever actually used dracut?

dracut --kver 4.5

Wow, that was hard! It requires zero configuration and that's true even
if you've got LVM on top of LUKS on top of RAID or something equally
complex. If you're already running that kernel version, you don't even
need to specify it.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] usr merge

[Consus]

On 17:15 Sat 09 Apr, James Le Cuirot wrote:
> On Sat, 9 Apr 2016 12:09:38 -0400
> waltdnes@waltdnes.org wrote:
> 
> > > I never really got the mentality that using an initramfs is a
> > > burden.  
> > 
> >   One more piece of software that can go wrong.  You have to
> > maintain+configure it; e.g. sync software and library versions with
> > what's on the rest of the system.
> 
> Errm, have you ever actually used dracut?
> 
> dracut --kver 4.5
> 
> Wow, that was hard! It requires zero configuration and that's true even
> if you've got LVM on top of LUKS on top of RAID or something equally
> complex. If you're already running that kernel version, you don't even
> need to specify it.

In 2014 I switched from dracut to genkernel because after *every*
dracut's update I was writing to it's devs about a new shiny bug. Like
infinite loops in the pidof() implementation.

[gentoo-dev] Re: usr merge

[»Q«]

On Sat, 9 Apr 2016 12:09:38 -0400
waltdnes@waltdnes.org wrote:

> On Sat, Apr 09, 2016 at 07:11:31AM -0400, Rich Freeman wrote
> 
> > It was simply a recognition that we were already in a state where
> > booting a system without /usr mounted early can cause problems.  
> 
> For certain edge cases... yes.  But they were already using
> initramfs or merging /usr into /.  I'm talking about the 95% who
> don't really need it.

Booting without /usr mounted early is something Gentoo already doesn't
support and can't support, right?

Re: [gentoo-dev] usr merge

[netfab]

Le 09/04/16 à 17:15, James Le Cuirot a tapoté :
> Errm, have you ever actually used dracut?
> 
> dracut --kver 4.5
> 
> Wow, that was hard! It requires zero configuration [...]

Sorry. Not true.

> $ emerge -pv dracut
> 
> [...]
>
> The following keyword changes are necessary to proceed:
>  (see "package.accept_keywords" in the portage(5) man page for more
> details) # required by dracut (argument)
> =sys-kernel/dracut-044 ~amd64

Re: [gentoo-dev] Re: usr merge

[waltdnes]

On Sat, Apr 09, 2016 at 12:18:25PM -0500, »Q« wrote
> On Sat, 9 Apr 2016 12:09:38 -0400
> waltdnes@waltdnes.org wrote:
> 
> > On Sat, Apr 09, 2016 at 07:11:31AM -0400, Rich Freeman wrote
> > 
> > > It was simply a recognition that we were already in a state where
> > > booting a system without /usr mounted early can cause problems.  
> > 
> > For certain edge cases... yes.  But they were already using
> > initramfs or merging /usr into /.  I'm talking about the 95% who
> > don't really need it.
> 
> Booting without /usr mounted early is something Gentoo already doesn't
> support and can't support, right?

  If you can read this post, you've got a mighty powerful imagination.
Because we all know that Gentoo can't boot, let alone send emails, from
a machine with separate /usr and no initramfs... just like I'm using
right now.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] usr merge

[Dale]

James Le Cuirot wrote:
> On Sat, 9 Apr 2016 12:09:38 -0400
> waltdnes@waltdnes.org wrote:
>
>>> I never really got the mentality that using an initramfs is a
>>> burden.  
>>   One more piece of software that can go wrong.  You have to
>> maintain+configure it; e.g. sync software and library versions with
>> what's on the rest of the system.
> Errm, have you ever actually used dracut?
>
> dracut --kver 4.5
>
> Wow, that was hard! It requires zero configuration and that's true even
> if you've got LVM on top of LUKS on top of RAID or something equally
> complex. If you're already running that kernel version, you don't even
> need to specify it.
>


FYI.  I've had those to fail too.  As Walt said, just one more thing to
fail. 

Dale

:-)  :-) 

Re: [gentoo-dev] usr merge

[waltdnes]

On Sat, Apr 09, 2016 at 07:11:31AM -0400, Rich Freeman wrote
> 
> An initramfs is just a secondary bootloader for userspace.  I almost
> always use them even if I'm just booting a VM with a single partition
> on it.  If something goes wrong you can fall back to a shell in the
> initramfs and it is like having a rescue disk built into your system
> disk.  For a more complex setup it is much more robust than relying on
> the kernel to find your root, and it also lets you build with a more
> module-based kernel, which has some benefits as well even if you build
> kernels tailored to each host.

  Another point that just occurred to me...
  - get a machine with 128 gigs of RAM
  - put *ALL* software on the initramfs
  - when initramfs comes up, it won't have to hand off control to the
    "real init", because everything will be running off initramfs.  A
    hard drive will only be used for storing data, and config files.

  What worries me is a future where only initramfs images will boot on
UEFI machines.  Make that *SIGNED* initramfs images.  I'm sure Microsoft
would love that.  initramfs images with annual licence fees, hard-coded
telemetry to the mothership, and forced "upgrades" every so often.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] usr merge

[Canek Peláez Valdés]

On Sat, Apr 9, 2016 at 11:09 AM,  <waltdnes@waltdnes.org> wrote:
> On Sat, Apr 09, 2016 at 07:11:31AM -0400, Rich Freeman wrote
>
>> It was simply a recognition that we were already in a state where
>> booting a system without /usr mounted early can cause problems.
>
>   For certain edge cases... yes.

Edge cases? According to whom?

> But they were already using initramfs
> or merging /usr into /.  I'm talking about the 95% who don't really need
> it.

Do you have *ANY* source for that 95%?

>
>> I never really got the mentality that using an initramfs is a burden.
>
>   One more piece of software that can go wrong.  You have to
> maintain+configure it; e.g. sync software and library versions with
> what's on the rest of the system.

Everything can go wrong; an initramfs is actually a really easy piece
of software to automatize and debug if it goes wrong.

>> An initramfs is just a secondary bootloader for userspace.  I almost
>> always use them even if I'm just booting a VM with a single partition
>> on it.  If something goes wrong you can fall back to a shell in the
>> initramfs and it is like having a rescue disk built into your system
>> disk.
>
>   There is single-user mode for rescue.

Which could fail if, for some reason, you need *something* from /usr
and it hasn't been mounted. And *something* is becoming *anything*,
whether you like it or not.

>> For a more complex setup it is much more robust than relying on
>> the kernel to find your root, and it also lets you build with a more
>> module-based kernel, which has some benefits as well even if you build
>> kernels tailored to each host.
>
>   I have "Production" and "Experimental" entries in my LILO menu.  A new
> kernel is always set up as the "Experimental" entry.  After running
> several days without problems, I run a script which copies the data from
> the "Experimental" portion to "Production".

You use LILO. That means, you don't use UEFI. That means, almost
certainly you don't use recent hardware.

Walter, *YOU* are the 5% edge case. Many people are running UEFI only
hardware, and the number will only increase, since BIOS *is* dead.

>   The only time my system had problems "finding root" was years ago when
> the switch from /dev/hd* to /dev/sd* took place.  The "Experimental"
> boot with the new kernel died.  I booted "Production", read the mailing
> list, changed "hd" to "sd" for the "Experimental" entry, and rebooted.
> After several days without problems, I made the same change to the
> "Production" entry, and copied the "Experimental" portion to
> "Production".

That was the only time *FOR YOU*. But, as I stated above, you are the
5% edge case; the Gentoo devs need to think about the general case,
starting with their own systems so they can do their jobs. I bet most
of them are on UEFI.

Nobody anywhere is telling you what to do with your systems (nor would
they in the future). The Gentoo devs only are saying that if by having
separated /usr without an initramfs, you risk screwing your system,
and if that happens, you are on you own.

Regards.
-- 
Dr. Canek Peláez Valdés
Profesor de Carrera Asociado C
Departamento de Matemáticas
Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Re: usr merge

[Canek Peláez Valdés]

On Sat, Apr 9, 2016 at 1:34 PM,  <waltdnes@waltdnes.org> wrote:
> On Sat, Apr 09, 2016 at 12:18:25PM -0500, »Q« wrote
>> On Sat, 9 Apr 2016 12:09:38 -0400
>> waltdnes@waltdnes.org wrote:
>>
>> > On Sat, Apr 09, 2016 at 07:11:31AM -0400, Rich Freeman wrote
>> >
>> > > It was simply a recognition that we were already in a state where
>> > > booting a system without /usr mounted early can cause problems.
>> >
>> > For certain edge cases... yes.  But they were already using
>> > initramfs or merging /usr into /.  I'm talking about the 95% who
>> > don't really need it.
>>
>> Booting without /usr mounted early is something Gentoo already doesn't
>> support and can't support, right?
>
>   If you can read this post, you've got a mighty powerful imagination.
> Because we all know that Gentoo can't boot, let alone send emails, from
> a machine with separate /usr and no initramfs... just like I'm using
> right now.

Nobody said it was not possible; Q said that it was not supported, and
it cannot be because, in the general case (not *YOU* specific case),
someone somewhere may require something from /usr to boot.

Regards.
-- 
Dr. Canek Peláez Valdés
Profesor de Carrera Asociado C
Departamento de Matemáticas
Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Re: usr merge

[Alan McKinnon]

On 09/04/2016 20:34, waltdnes@waltdnes.org wrote:
> On Sat, Apr 09, 2016 at 12:18:25PM -0500, »Q« wrote
>> On Sat, 9 Apr 2016 12:09:38 -0400
>> waltdnes@waltdnes.org wrote:
>>
>>> On Sat, Apr 09, 2016 at 07:11:31AM -0400, Rich Freeman wrote
>>>
>>>> It was simply a recognition that we were already in a state where
>>>> booting a system without /usr mounted early can cause problems.  
>>>
>>> For certain edge cases... yes.  But they were already using
>>> initramfs or merging /usr into /.  I'm talking about the 95% who
>>> don't really need it.
>>
>> Booting without /usr mounted early is something Gentoo already doesn't
>> support and can't support, right?
> 
>   If you can read this post, you've got a mighty powerful imagination.
> Because we all know that Gentoo can't boot, let alone send emails, from
> a machine with separate /usr and no initramfs... just like I'm using
> right now.
> 


That's not what he said.

He said gentoo doesn't, and can't support it, because it's a world of
pain to provide proper support to everyone who wants it. If you want it,
as you do, you get to do it yourself. While it still works, grat. When
it stops working, you fix it.

He did not say, as you imply, that it cannot work right now.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-dev] usr merge

[Philip Webb]

160409 Canek Peláez Valdés wrote:
> You use LILO : that means, you don't use UEFI :
> that means, almost certainly, you don't use recent hardware.

I've always used Lilo, which is simple + reliable :
I never see questions re it here, but there are many re Grub.
I do use recent hardware, a cutting-edge machine I built  6 mth ago .
When setting it up, I suppressed UEFI in the BIOS settings :
isn't that what anyone not running M$ would do ?
 
> Gentoo devs only are saying that if by having separated /usr
> without an initramfs, you risk screwing your system.

I haven't been reading this long thread -- merely skimming some of it -- ,
& I missed or didn't understand what is being proposed or imposed.
There was an issue earlier re not having  /use  on a separate partition
& both my machines have it on the same partition as  / .
Is this thread re that earlier matter or is it a new item ?

-- 
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sat, Apr 9, 2016 at 3:49 PM, Philip Webb <purslow@ca.inter.net> wrote:
> I've always used Lilo, which is simple + reliable :
> I never see questions re it here, but there are many re Grub.
> I do use recent hardware, a cutting-edge machine I built  6 mth ago .
> When setting it up, I suppressed UEFI in the BIOS settings :
> isn't that what anyone not running M$ would do ?

That depends on how much you care about rootkits...  :)

-- 
Rich

Re: [gentoo-dev] usr merge

[M. J. Everitt]

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]

On 09/04/16 20:53, Rich Freeman wrote:
> On Sat, Apr 9, 2016 at 3:49 PM, Philip Webb <purslow@ca.inter.net> wrote:
>> I've always used Lilo, which is simple + reliable :
>> I never see questions re it here, but there are many re Grub.
>> I do use recent hardware, a cutting-edge machine I built  6 mth ago .
>> When setting it up, I suppressed UEFI in the BIOS settings :
>> isn't that what anyone not running M$ would do ?
> That depends on how much you care about rootkits...  :)
>
Rootkits in linux ... why?!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [gentoo-dev] usr merge

[Canek Peláez Valdés]

On Sat, Apr 9, 2016 at 2:49 PM, Philip Webb <purslow@ca.inter.net> wrote:
> 160409 Canek Peláez Valdés wrote:
>> You use LILO : that means, you don't use UEFI :
>> that means, almost certainly, you don't use recent hardware.
>
> I've always used Lilo, which is simple + reliable :
> I never see questions re it here, but there are many re Grub.
> I do use recent hardware, a cutting-edge machine I built  6 mth ago .
> When setting it up, I suppressed UEFI in the BIOS settings :
> isn't that what anyone not running M$ would do ?

I just disabled secure boot, although it's possible to use it with
Linux. However it would require to manually sign everything from boot
loader to kernel modules, since Gentoo has no infrastructure to do
that. Maybe a future project.

I don't "supress" UEFI, since it's *obviously* so much better than
BIOS, and since bootctl (the program formerly known as gummiboot) it's
incredible easy to use. You don't even notice it's there.

Also, I'm not sure, but I believe there are motherboards where you
don't have the option to "supress" UEFI, since they simply don't have
BIOS anymore. I could be wrong; but even if that's the case, I'm
pretty sure in the future BIOS will get relegated to a niche market,
if it doesn't completely disappear.

Seriously, UEFI is soooo much better.

Regards.
-- 
Dr. Canek Peláez Valdés
Profesor de Carrera Asociado C
Departamento de Matemáticas
Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-dev] usr merge

[Philip Webb]

160409 Canek Peláez Valdés wrote:
> On Sat, Apr 9, 2016 at 2:49 PM, Philip Webb <purslow@ca.inter.net> wrote:
>> I've always used Lilo, which is simple + reliable :
>> I never see questions re it here, but there are many re Grub.
>> I do use recent hardware, a cutting-edge machine I built  6 mth ago .
>> When setting it up, I suppressed UEFI in the BIOS settings :
>> isn't that what anyone not running M$ would do ?
> I just disabled secure boot, although it's possible to use it with Linux.
> However, it would require to manually sign everything from boot loader
> to kernel modules, since Gentoo has no infrastructure to do that.
> I don't "supress" UEFI, since it's *obviously* so much better than BIOS
> and since bootctl (the program formerly known as gummiboot)
> it's incredible easy to use. You don't even notice it's there.

Sorry, I meant "suppress secure boot".  My mobo doesn't have UEFI.

> I believe there are motherboards where you don't have the option
> to "supress" UEFI, since they simply don't have BIOS anymore.
> Seriously, UEFI is soooo much better.

Thanks for the enlightment (smile).

Can you or anyone else answer my other question re the origin of the thread ?
-- ie is this a revival of not putting  /usr  on its own partition
or is it a new proposal to alter the file system in some other way ?

-- 
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca

Re: [gentoo-dev] usr merge

[M. J. Everitt]

[-- Attachment #1: Type: text/plain, Size: 2021 bytes --]

On 09/04/16 23:50, Philip Webb wrote:
> 160409 Canek Peláez Valdés wrote:
>> On Sat, Apr 9, 2016 at 2:49 PM, Philip Webb <purslow@ca.inter.net> wrote:
>>> I've always used Lilo, which is simple + reliable :
>>> I never see questions re it here, but there are many re Grub.
>>> I do use recent hardware, a cutting-edge machine I built  6 mth ago .
>>> When setting it up, I suppressed UEFI in the BIOS settings :
>>> isn't that what anyone not running M$ would do ?
>> I just disabled secure boot, although it's possible to use it with Linux.
>> However, it would require to manually sign everything from boot loader
>> to kernel modules, since Gentoo has no infrastructure to do that.
>> I don't "supress" UEFI, since it's *obviously* so much better than BIOS
>> and since bootctl (the program formerly known as gummiboot)
>> it's incredible easy to use. You don't even notice it's there.
> Sorry, I meant "suppress secure boot".  My mobo doesn't have UEFI.
>
>> I believe there are motherboards where you don't have the option
>> to "supress" UEFI, since they simply don't have BIOS anymore.
>> Seriously, UEFI is soooo much better.
> Thanks for the enlightment (smile).
>
> Can you or anyone else answer my other question re the origin of the thread ?
> -- ie is this a revival of not putting  /usr  on its own partition
> or is it a new proposal to alter the file system in some other way ?
>
Philip, the discussion was prompted from this original message by WilliamH:

https://archives.gentoo.org/gentoo-dev/message/df3c1494ea49191d4e3d442e37eb8ca2

Basically there is a desire to either (1) move /bin, /sbin to /usr/bin,
/usr/sbin or (2) the reverse (ie. eliminate /usr) for a variety of
reasons, but predominately to offer "more users more choice", and uphold
the principle of Gentoo being a distro of flexibility.

Whilst there is some good pros/cons being aired, there is also the usual
amount of gentoo bike-shedding, and personal preference distorting the
discussion :) .


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [gentoo-dev] usr merge

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1137 bytes --]

Hi Philip,

On Sat, Apr 09, 2016 at 06:50:49PM -0400, Philip Webb wrote:
> Can you or anyone else answer my other question re the origin of the thread ?
> -- ie is this a revival of not putting  /usr  on its own partition
> or is it a new proposal to alter the file system in some other way ?

The original discussion was about the usr merge [1], which is taking the
binary parts of / and putting them in /usr, then inserting symlinks in /
to preserve backward compatibility. Yes, I'm pointing to a document on
fdo, but the systemd guys have nothing to do with the /usr merge; it
originally happened in Solaris.

I never supported the reverse merge that has been discussed, it was just
brought up I guess as an example of a Gentoo user being able to do his
own setup. Reverse merge meaning moving everything from /usr to /.

The thread has definitely gotten more out of hand than I anticipated. It
is very hard at this point to separate the pros/cons, bikeshedding and
personal preferences. That's why I requested that someone assist with a
summary. :-)

William

https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] usr merge

[J. Roeleveld]

[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]

On Saturday, April 09, 2016 05:15:08 PM James Le Cuirot wrote:
> On Sat, 9 Apr 2016 12:09:38 -0400
> 
> waltdnes@waltdnes.org wrote:
> > > I never really got the mentality that using an initramfs is a
> > > burden.
> > > 
> >   One more piece of software that can go wrong.  You have to
> > 
> > maintain+configure it; e.g. sync software and library versions with
> > what's on the rest of the system.
> 
> Errm, have you ever actually used dracut?
> 
> dracut --kver 4.5
> 
> Wow, that was hard! It requires zero configuration and that's true even
> if you've got LVM on top of LUKS on top of RAID or something equally
> complex. If you're already running that kernel version, you don't even
> need to specify it.

I actually write my own initramfs because neither dracut not genkernel end up 
with a convenient boot system.

I have 2 disks, both encrypted.
I prefer only to enter the decryption password once. Both Dracut and Genkernel 
insist on asking for the password/key for every single disk.

The ONLY reason why I feel an initramfs is warranted is because of the 
encryption. Without that, it should not be necessary.

--
Joost

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-dev] usr merge

[M. J. Everitt]

[-- Attachment #1: Type: text/plain, Size: 1478 bytes --]

On 10/04/16 00:53, William Hubbs wrote:
>
> The original discussion was about the usr merge [1], which is taking the
> binary parts of / and putting them in /usr, then inserting symlinks in /
> to preserve backward compatibility. Yes, I'm pointing to a document on
> fdo, but the systemd guys have nothing to do with the /usr merge; it
> originally happened in Solaris.
>
> I never supported the reverse merge that has been discussed, it was just
> brought up I guess as an example of a Gentoo user being able to do his
> own setup. Reverse merge meaning moving everything from /usr to /.
>
I may have contributed to the latter point, but addressing the former
specifically, I, like others, have /usr mounted on an NFS server for
thin clients (not in the full-true sense, but with a very minimal /
currently residing on USB).
What you propose moving binaries from / to /usr would render them
completely unbootable without early mounting via initramfs. Granted,
what I have now is rather a bodge, but it's working fine, and provided I
am meticulous about any rare changes from the host build system to /,
this is a small problem in the grander scheme of things, and I have one
maintained 'install' on my build system. Ok, so a full thin-client would
probably be a better* option, but I'm running with what I got, rather
than investing a lot (of/more) time/energy in getting that solution
working, which failed on (several) previous attempts (hence *).


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [gentoo-dev] usr merge

[Gordon Pettey]

[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]

On Sat, Apr 9, 2016 at 5:50 PM, Philip Webb <purslow@ca.inter.net> wrote:

> 160409 Canek Peláez Valdés wrote:
> > On Sat, Apr 9, 2016 at 2:49 PM, Philip Webb <purslow@ca.inter.net>
> wrote:
> >> I've always used Lilo, which is simple + reliable :
> >> I never see questions re it here, but there are many re Grub.
> >> I do use recent hardware, a cutting-edge machine I built  6 mth ago .
> >> When setting it up, I suppressed UEFI in the BIOS settings :
> >> isn't that what anyone not running M$ would do ?
> > I just disabled secure boot, although it's possible to use it with Linux.
> > However, it would require to manually sign everything from boot loader
> > to kernel modules, since Gentoo has no infrastructure to do that.
> > I don't "supress" UEFI, since it's *obviously* so much better than BIOS
> > and since bootctl (the program formerly known as gummiboot)
> > it's incredible easy to use. You don't even notice it's there.
>
> Sorry, I meant "suppress secure boot".  My mobo doesn't have UEFI.


If you have "secure boot", you have UEFI. You can't have it without.

[-- Attachment #2: Type: text/html, Size: 1719 bytes --]

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sat, Apr 9, 2016 at 8:09 PM, J. Roeleveld <joost@antarean.org> wrote:
>
> I actually write my own initramfs because neither dracut not genkernel end up
> with a convenient boot system.
>
> I have 2 disks, both encrypted.
> I prefer only to enter the decryption password once. Both Dracut and Genkernel
> insist on asking for the password/key for every single disk.
>

You can of course roll your own, but I imagine that it would be more
straightforward to just write your own dracut plugin.  They're
basically just scripts that run at whatever boot stage you define.
You might also just be able to modify the existing plugin.

-- 
Rich

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sat, Apr 9, 2016 at 8:37 PM, M. J. Everitt <m.j.everitt@iee.org> wrote:
> I may have contributed to the latter point, but addressing the former
> specifically, I, like others, have /usr mounted on an NFS server for
> thin clients (not in the full-true sense, but with a very minimal /
> currently residing on USB).
> What you propose moving binaries from / to /usr would render them
> completely unbootable without early mounting via initramfs.

I believe dracut will auto-mount /usr.  As long as your fstab is
accurate (double-check - sometimes people don't have correct settings
for root since without something like dracut the root filesystem isn't
mounted according to fstab), I suspect it will just NFS-mount your
/usr before pivoting.  If not you can probably use the fstab-user
module to force it to mount (you stick a second dracut-specific fstab
file in /etc and it will mount everything it finds in there whether it
thinks it needs it or not).  I'd start with the auto-magic detection
since it tends to work.

Dracut needs a root= setting on the kernel command line to get it
started, but once it finds that it tends to figure out how to get it
mounted read-only, then it looks inside for an /etc/fstab to figure
out the rest.  When you build the initramfs dracut will also copy
files like mdadm.conf into the initramfs automatically.  You can also
configure it to load extra stuff in there (my initramfs doubles as a
rescue image, so I stick a few convenience things in there that
strictly aren't needed, like btrfstune and a full bash instead of just
dash).

Part of me also wonders if Gentoo would be better off having emerge
gentoo-sources actually BUILD the kernel and initramfs and not just
dump a bunch of sources on the disk.  Most distros consider an
initramfs a no-brainer because it just ships already setup, and an
initramfs is a lot more forgiving when you add a new drive and your
firmware/kernel decides to re-number everything.  Just label your
filesystems or store UUIDs and the initramfs will figure out what
happened.

-- 
Rich

Re: [gentoo-dev] usr merge

[M. J. Everitt]

[-- Attachment #1: Type: text/plain, Size: 932 bytes --]

On 10/04/16 02:14, Rich Freeman wrote:
> Part of me also wonders if Gentoo would be better off having emerge
> gentoo-sources actually BUILD the kernel and initramfs and not just
> dump a bunch of sources on the disk.  Most distros consider an
> initramfs a no-brainer because it just ships already setup, and an
> initramfs is a lot more forgiving when you add a new drive and your
> firmware/kernel decides to re-number everything.  Just label your
> filesystems or store UUIDs and the initramfs will figure out what
> happened.
>
I think that is the potential for a stage4-style install. I think
previous list discussions have maintained that the flexibility of gentoo
is maintained by having a very basic install image, and a stage3 to
bootstrap into, and have the user compile their own kernel.

Otherwise, go install debian/ubuntu/choose-your-own-ready-boxed-linux
... gentoo isn't that kinda distro. Imho.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sat, Apr 9, 2016 at 9:35 PM, M. J. Everitt <m.j.everitt@iee.org> wrote:
> I think that is the potential for a stage4-style install. I think
> previous list discussions have maintained that the flexibility of gentoo
> is maintained by having a very basic install image, and a stage3 to
> bootstrap into, and have the user compile their own kernel.
>
> Otherwise, go install debian/ubuntu/choose-your-own-ready-boxed-linux
> ... gentoo isn't that kinda distro. Imho.

By that argument, when you run emerge chromium shouldn't it just dump
the chromium sources in /usr/src, so that you can build and install
your own chromium?

The whole point of a source-based package manager is that it actually
BUILDs the packages.  Why do we treat the kernel differently from
every single other package?

I get that users often want to build their own, and that is fine.  We
SHOULD have a package that dumps sources in /usr/src (though to be
honest I prefer to just fetch mine using git).  However, why shouldn't
emerge virtual/kernel not just give you a /boot/vmlinux-x.y.z the same
way that emerge vim gives you a /usr/bin/vim?


-- 
Rich

Re: [gentoo-dev] usr merge

[M. J. Everitt]

[-- Attachment #1: Type: text/plain, Size: 1532 bytes --]

On 10/04/16 03:06, Rich Freeman wrote:
>
> By that argument, when you run emerge chromium shouldn't it just dump
> the chromium sources in /usr/src, so that you can build and install
> your own chromium?
>
> The whole point of a source-based package manager is that it actually
> BUILDs the packages.  Why do we treat the kernel differently from
> every single other package?
>
> I get that users often want to build their own, and that is fine.  We
> SHOULD have a package that dumps sources in /usr/src (though to be
> honest I prefer to just fetch mine using git).  However, why shouldn't
> emerge virtual/kernel not just give you a /boot/vmlinux-x.y.z the same
> way that emerge vim gives you a /usr/bin/vim?
>
I take your point, but I would argue that the kernel and boot subsystem
really are special cases .. you don't go hacking around the chromium
sources to fundamentally alter the way/order it works, right?! Likewise,
if you don't like chromium, you might install firefox .. cf. say, Lilo
and grub. It is the flexibility (and, I concede, the complexity, and
hence 'power') that defines Gentoo here.

This also applies to the whole /usr debate .. and yes, I agree there are
caveats with both our existing setup and many of the others discussed on
this thread. I think there is a debate to be had, and whilst it has born
the inevitable bike-shedding, I think there could be some merit in a
'flattened' system. I suppose the natural follow-on question from this,
is "how best to achieve it?".


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sat, Apr 9, 2016 at 10:17 PM, M. J. Everitt <m.j.everitt@iee.org> wrote:
> I take your point, but I would argue that the kernel and boot subsystem
> really are special cases .. you don't go hacking around the chromium
> sources to fundamentally alter the way/order it works, right?! Likewise,
> if you don't like chromium, you might install firefox .. cf. say, Lilo
> and grub. It is the flexibility (and, I concede, the complexity, and
> hence 'power') that defines Gentoo here.
>

I think the bigger issue with the kernel is the huge configuration
space it has.  Chromium may have a ton of USE flags compared to most
packages, but those pale in comparison to the kernel.  Obviously it
would not make sense to try to create a USE flag for every
configuration option.  Now, a package that built and installed a
kernel might have a few USE flags.  For example, it might have flags
equivalent to the gentoo config add-ons (for openrc/systemd, and so
on).  It might also have flags that give it some default
configuration, or an all-modules configuration, or an all-builtin
configuration.  I imagine that most distros ship something close to an
all-modules config.

In any case, that isn't really any kind of policy issue.  For whatever
reason nobody has bothered to create a package.  Certainly nobody
would object to somebody adding a new kernel package that builds and
installs a fully configured kernel.  It might even become the
recommended default in the kernel (without getting rid of the other
options).

-- 
Rich

Re: [gentoo-dev] usr merge

[M. J. Everitt]

[-- Attachment #1: Type: text/plain, Size: 1378 bytes --]


On 10/04/16 04:08, Rich Freeman wrote:
> I think the bigger issue with the kernel is the huge configuration
> space it has.  Chromium may have a ton of USE flags compared to most
> packages, but those pale in comparison to the kernel.  Obviously it
> would not make sense to try to create a USE flag for every
> configuration option.  Now, a package that built and installed a
> kernel might have a few USE flags.  For example, it might have flags
> equivalent to the gentoo config add-ons (for openrc/systemd, and so
> on).  It might also have flags that give it some default
> configuration, or an all-modules configuration, or an all-builtin
> configuration.  I imagine that most distros ship something close to an
> all-modules config.
>
> In any case, that isn't really any kind of policy issue.  For whatever
> reason nobody has bothered to create a package.  Certainly nobody
> would object to somebody adding a new kernel package that builds and
> installs a fully configured kernel.  It might even become the
> recommended default in the kernel (without getting rid of the other
> options).
>
Ok I'm gonna push the Big Red Button here, and assume you may not have
met 'genkernel' .. ok its not a package, but its the nearest thing to
Gentoo's solution to what you're suggesting ... And it's in the Handbook
.. so, where's the issue, again?!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sat, Apr 9, 2016 at 11:28 PM, M. J. Everitt <m.j.everitt@iee.org> wrote:
> Ok I'm gonna push the Big Red Button here, and assume you may not have
> met 'genkernel' ..

Genkernel has been around for a LONG time.  I'm well aware of it.

> ok its not a package, but its the nearest thing to
> Gentoo's solution to what you're suggesting ... And it's in the Handbook
> .. so, where's the issue, again?!

1. As you point out, its not a package.  That means it works
differently than everything else, and it can't be used as a
dependency/etc.
2. Genkernel's initramfs isn't all that great.  Don't get me wrong -
it was very good back when it was new.  However, I find it hard to
compare it to the likes of dracut.

However, if it were all that serious of an issue somebody would have
fixed it by now.  Manually building a kernel and using dracut is easy
enough, and of course some prefer to not use an initramfs if their
configuration allows it.

-- 
Rich

Re: [gentoo-dev] usr merge

[M. J. Everitt]

[-- Attachment #1: Type: text/plain, Size: 1441 bytes --]


On 10/04/16 04:49, Rich Freeman wrote:
> 1. As you point out, its not a package.  That means it works
> differently than everything else, and it can't be used as a
> dependency/etc.
> 2. Genkernel's initramfs isn't all that great.  Don't get me wrong -
> it was very good back when it was new.  However, I find it hard to
> compare it to the likes of dracut.
>
> However, if it were all that serious of an issue somebody would have
> fixed it by now.  Manually building a kernel and using dracut is easy
> enough, and of course some prefer to not use an initramfs if their
> configuration allows it.
>
I haven't dared explore dracut because last I heard it was still
experimental. That people are actively using it (presumably in
production and not just experimental/development suggests at the very
least that the appropriate Gentoo wiki article needs updating (no
surprise there!).

Perhaps indeed genkernel needs some updating. When I last looked at the
best means of creating an initramfs, it was the least of the evils, but
there did seem a genuine lack of tools to accomplish it, which is where
I assume dracut came about.

Fundamentally, acknowledging a tangent of the original thread, I'd say
the jury remains out on whether Gentoo should be forcing the need of an
initramfs/rd on its users by default anyway. That kind of thing,
however, is of course, subject to a Council ruling if appropriate :) .


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [gentoo-dev] usr merge

[J. Roeleveld]

On Saturday, April 09, 2016 09:07:46 PM Rich Freeman wrote:
> On Sat, Apr 9, 2016 at 8:09 PM, J. Roeleveld <joost@antarean.org> wrote:
> > I actually write my own initramfs because neither dracut not genkernel end
> > up with a convenient boot system.
> > 
> > I have 2 disks, both encrypted.
> > I prefer only to enter the decryption password once. Both Dracut and
> > Genkernel insist on asking for the password/key for every single disk.
> 
> You can of course roll your own, but I imagine that it would be more
> straightforward to just write your own dracut plugin.  They're
> basically just scripts that run at whatever boot stage you define.
> You might also just be able to modify the existing plugin.

Possibly, but that will take longer than it took to create my own.
The config-file is 181 lines. Mostly copied from an example.
The init-file is 45 lines.

And it can be easily maintained.

--
Joost

[gentoo-dev] Re: usr merge

[Duncan]

Luca Barbato posted on Sat, 09 Apr 2016 15:03:15 +0200 as excerpted:

> On 09/04/16 14:37, Rich Freeman wrote:
>> I've certainly haven't had many problems with dracut.  When it fails it
>> is usually because I'm doing something ELSE that is off-the-wall and it
>> just doesn't have a plugin for it yet.  (And in those cases it isn't
>> like the kernel tends to get it right without an initramfs.)
>> 
>> I'd certainly want to test it on a merged /usr, but I'd be surprised if
>> it doesn't work, since it was designed to run on distros that are using
>> a merged /usr.
> 
> I think that should be the first thing to do not the last one =)

FWIW, dracut works just fine with a "reverse-merged" /usr (usr -> .), as 
well as the bin/sbin merge.  And if it works with that, it'll certainly 
work with (normal) merged usr, as AFAIK upstream's fedora/rh sponsored.

>> In an ideal world, you might argue that / should just be a tmpfs or
>> something almost as ephemeral.  It is just a place you hang everything
>> else off of.

> That would be the core concept, but then you can just not have /bin
> /sbin /lib 

That's in the context of (forward) /usr merge, which would make all those 
symlinks to the appropriate /usr location anyway.  Those symlinks could 
of course be created dynamically, as could the various mountpoint 
directories.

Of course /etc would have to be dynamically mounted in that scenario as 
well, but that's not a big issue as long as there's an initr*

I actually thought about doing a tmpfs-based / here, or effectively just 
never doing the pivotroot off the initramfs, with everything else 
dynamically mounted over top the initramfs dirs, but decided to go a 
different way instead, putting (almost) everything installed by the PM 
on /, and doing a reverse-/usr-merge, with /usr -> . , with / then ro-
mounted by default.  Seemed simpler for what I wanted to do than the 
tmpfs or stay-on-initramfs / route.

>> The thing I like about the merge is that it basically puts all your
>> distro-supplied stuff in one place.  /usr basically becomes the OS
>> minus state.  If things started out that way and you just had a short
>> stub loader that gets things initialized, and I were arguing that
>> instead of that little initialization stub you should break up /usr so
>> that the root count mount /usr, would that sound all that compelling? I
>> think having it all in one mountpoint seems a lot more compelling.
> 
> you cannot ever have everything in 1 mount point, you just move the
> problem somewhere else you notice less (initramfs), but the problem
> remains and either is solved or not.
> 
> having everything in /usr and then copy it over ${somewhere} is there,
> it can be debated if /bin or initramfs is the best place to put it.

I suppose many of us have made that point at least to ourselves, at some 
point. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: usr merge

[Duncan]

Nicolas Sebrecht posted on Sat, 09 Apr 2016 14:44:25 +0200 as excerpted:

> On Fri, Apr 08, 2016 at 07:58:35AM +0000, Duncan wrote:
> 
>> > I would also re-iterate, as I'm sure you're aware .. there ARE
>> > differences between sbin and bin .. unless of course you spend all
>> > your time in a Rooted VM where it doesn't matter if you accidentally
>> > trash your system. Some of us maintain a sensible user/superuser
>> > distinction for a variety of reasons, and simplifying your filesystem
>> > to suit some particular package style doesn't really sound like good
>> > reasoning for causing a lot of headaches for maintainers and a distro
>> > overall.
>> 
>> But... the real important distinction in terms of user vs. superuser
>> executables is file ownership and permissions, not the directory
>> they're in.
> 
> No. With a lightweight / I can install systems with two root filesystems
> that I rsync once I'm sure there's no regression. If one won't boot
> after an upgrade, I can just reboot and select the other root filesystem
> in grub.
> 
> This is much more easy than anything else.

Actually I do precisely that, with / itself, which here includes pretty 
much everything the package manager installs (with the exception of a few 
things in /var that need to be writable in normal operation, that are 
symlinked to /home/var as my / is normally read-only mounted), including 
the package database itself, so everything stays in sync with the package 
database tracking it, on the same filesystem. =:^)

$ df /
Filesystem     1M-blocks  Used Available Use% Mounted on
/dev/sda5          8192M 2819M     5132M  36% /

That's the working-copy.  It's actually a two-device btrfs raid1, 8 GiB 
per device (8 GiB partition on each of two SSDs).  That already gives me 
device redundancy.

The first backup is another 8 GiB, again actually two-device btrfs raid1, 
8 GiB per device, on another partition on each of those ssds.  That gives 
me fat-finger and broken update redundancy.

The second backup is an 8 GiB reiserfs on spinning rust, giving me both 
filesystem type redundancy because btrfs is still stabilizing, and a 
second backup in case disaster strikes when I'm actually updating the 
primary backup, taking out both it and the working copy.

All three are independently bootable from grub2 as installed on all three 
devices, using the working copy /boot on one of the ssds, the primary 
backup /boot on the other ssd, or the secondary backup /boot on the 
spinning rust.  /home similarly has a working copy raid1 btrfs on the 
ssds, a primary backup on the ssds, and a reiserfs secondary backup on 
spinning rust.  There are further backups on USB tho I don't keep them as 
current so if I actually had to fall back to them I'd have some work 
ahead of me.

Actually, I don't even have to switch to the grub2 commandline to switch 
between the three, either.  They're all selectable directly from my 
customized grub2 menu, as is init=/bin/bash, systemd emergency and rescue 
mode, etc.  Of course I can go grub commandline if needed, but it's not 
needed for those entries as they're already available in the menu I've 
setup.  And of course the grub installation and corresponding /boot I use 
is selectable directly from the BIOS.


What's nice about this is that the 8 GiB root is plenty big enough to 
hold the entire working system, including all manpages, the X and KDE 
install, etc, so not only do I have full documentation to work with while 
I'm recovering my broken root, but I have a full X and kde-plasma, which 
with /home or one of its backups gives me a fully customized kde install 
as well.  So I can load up X/kde-plasma, and fire up youtube for full-
monitor viewing say some club music videos to keep me awake on the 42-
inch, while I work from one of the backups to recover the working copy 
with multiple konsole terminals on the 48-inch below it, and the system 
performance graphs display on the 21-inch off to the side.

Try doing all /that/ in recovery mode from your "lightweight" / backup. 
=:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] usr merge

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 527 bytes --]

On Sun, 10 Apr 2016 02:09:35 +0200
"J. Roeleveld" <joost@antarean.org> wrote:

> I actually write my own initramfs because neither dracut not
> genkernel end up with a convenient boot system.
> 
> I have 2 disks, both encrypted.
> I prefer only to enter the decryption password once. Both Dracut and
> Genkernel insist on asking for the password/key for every single disk.

Dracut on RHEL actually handles this out of the box. Might be worth
finding out how.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

[gentoo-dev] Re: usr merge

[Duncan]

Dale posted on Sat, 09 Apr 2016 13:42:37 -0500 as excerpted:

> James Le Cuirot wrote:
>> On Sat, 9 Apr 2016 12:09:38 -0400 waltdnes@waltdnes.org wrote:
>>
>>>> I never really got the mentality that using an initramfs is a burden.
>>>   One more piece of software that can go wrong.  You have to
>>> maintain+configure it; e.g. sync software and library versions with
>>> what's on the rest of the system.
>> Errm, have you ever actually used dracut?
>>
>> dracut --kver 4.5
>>
>> Wow, that was hard! It requires zero configuration and that's true even
>> if you've got LVM on top of LUKS on top of RAID or something equally
>> complex. If you're already running that kernel version, you don't even
>> need to specify it.
>>
> FYI.  I've had those to fail too.  As Walt said, just one more thing to
> fail.

And more to the point, if all you know about dracut is dracut --kver 4.5, 
then you're not going to be able to _fix_ those failures.

Some years ago I tried lvm2 as well as mdraid.  I quickly ejected lvm2 
from my system and future plans (keeping mdraid), because it was simply 
too complex for me as an admin to be confident in my ability to work with 
it without fat-fingering something, under the extreme pressure of a 
disaster recovery situation, possibly without proper access to manpages 
and other documentation due to the disaster recovery I was working thru.

Waltdnes has a point, the same point I learned then.  As a responsible 
admin, if the system's too complex to be understood well enough to be 
confident in one's ability to restore in a disaster recovery situation 
with limited or no access to manpages and similar documentation, it's too 
complex.  A reasonable system is one you understand well enough to 
confidently manage it in those sorts of situations.  Otherwise it's 
simply too complex for your skill level as an admin.

And understanding an initr* well enough to confidently deal with a 
disaster recovery situation, possibly/likely without access to 
documentation (it's a disaster recovery, after all!) is definitely *well* 
beyond "dracut --kver 4.5" level, so he's very right to be worried about 
it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: usr merge

[Duncan]

Rich Freeman posted on Sat, 09 Apr 2016 21:07:46 -0400 as excerpted:

> On Sat, Apr 9, 2016 at 8:09 PM, J. Roeleveld <joost@antarean.org> wrote:
>>
>> I actually write my own initramfs because neither dracut not genkernel
>> end up with a convenient boot system.
>>
>> I have 2 disks, both encrypted.
>> I prefer only to enter the decryption password once. Both Dracut and
>> Genkernel insist on asking for the password/key for every single disk.
>>
>>
> You can of course roll your own, but I imagine that it would be more
> straightforward to just write your own dracut plugin.  They're basically
> just scripts that run at whatever boot stage you define.
> You might also just be able to modify the existing plugin.

The problem with writing your own plugin, is that then you have to 
understand /both/ what you want to do, and the system you're writing a 
plugin for, in sufficient depth to actually do so.

Whereas if you write the functionality directly, you only have to, by the 
end, understand the functionality you're implementing, nothing else.  
True, you'll probably be implementing something a bit broader than the 
plugin, and will probably learn a bit more about the topic as you do it, 
but if that was the intent in the first place, you'll definitely have 
achieved it when you're done, while if you write the plugin, you'll only 
have a so-so knowledge of two things, instead of a more in depth 
knowledge of the one you were actually interested in.


This is actually one of the problems I had trying to learn firewalling on 
Linux, back when I switched from MS.  I knew the general concepts, and 
indeed had played with them on my DSL router, back in the day, well 
enough to be the reference person from which many others learned.  But I 
just couldn't get the hang of the various firewall helper scripts, 
shorewall and the like, because they were simply too far from the action, 
and I would have had to effectively learn both them and Linux IPTables, 
particularly when the helper script didn't cover what I wanted to do in 
its simplified model.  When I finally gave up on the so-called helper 
scripts and decided to try IPTables directly, it was *MUCH* simpler, 
because now I was just learning ONE thing!

Similarly, I learned kernel suspend/hibernate and resume by reading the 
kernel docs and writing my own script.  Once I was part way done, I was 
able to actually understand the complex suspend-tools or whatever script 
far better, and could actually borrow a few tricks from it, whereas when 
I started I tried reading it and it was just trying to do far too much 
fancy stuff, far too far from the real action, for me to properly master 
the real kernel action that the fancy script covered.

Grub2 same story.  I ended up learning the advanced scripting stuff and 
doing my own thing, eventually install.masking the normal user-side 
config stuff, which wouldn't let me do what I wanted to do, without 
having to learn BOTH the advanced scripting and the user-side layout, 
because the userside stuff was too dumbed down to expose what I needed to 
do what I wanted to do.


Tho with the initr*, I did go the dracut route myself.  But I'm still not 
entirely convinced that I wouldn't have been better off rolling my own, 
as I'm still not entirely comfortable with the level to which I 
understand, or more accurately don't understand, dracut.  Tho I do 
understand it well enough to have cut it down to the modules I need, 
only, but I still don't understand the scripts at the level I know I 
would had I created them myself...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: usr merge

[Rich Freeman]

On Sun, Apr 10, 2016 at 5:37 AM, Duncan <1i5t5.duncan@cox.net> wrote:
>
> Tho with the initr*, I did go the dracut route myself.  But I'm still not
> entirely convinced that I wouldn't have been better off rolling my own,
> as I'm still not entirely comfortable with the level to which I
> understand, or more accurately don't understand, dracut.  Tho I do
> understand it well enough to have cut it down to the modules I need,
> only, but I still don't understand the scripts at the level I know I
> would had I created them myself...
>

Well, by this logic you ought to be writing your own kernel as well.
How else are you going to deal with a kernel panic?  :)

Dracut is pretty straightforward though and fairly well-documented.
It runs through a series of stages like detecting devices, mounting
filesystems, and so on.  Plugins can run at any stage, and they also
can add files to the initramfs at time of creation.

The advantage of using something standard is that somebody else has
probably already thought of all the edge cases already, and they'll
fix the bugs as well.  If you contribute your plugin upstream they'll
take care of it for you as well.

So, you can just put one line in a config file to add /usr/bin/btrfs
to your initramfs and the built-in code will figure out that you'll
need /usr/lib64/liblzo2.so.2 installed there as well.  Of course, that
is just an example as somebody else has already written the btrfs
module.

I was running into some kind of strange md-raid behavior ages ago and
worked around it by writing a quick module:
https://rich0gentoo.wordpress.com/2012/01/21/a-quick-dracut-module/

That one is a bit of a hack - I suspect there was some underlying bug
in udev or something preventing the raid from being set up by the
normal module.  I suspect that module would no longer be needed (I've
since moved on to btrfs).  However, it demonstrated how dracut plugins
work - you just define hooks that get run at the appropriate phase.

-- 
Rich

[gentoo-dev] Re: usr merge

[»Q«]

On Fri, 8 Apr 2016 21:18:37 -0400
waltdnes@waltdnes.org wrote:

> On Fri, Apr 08, 2016 at 04:30:04PM -0400, Rich Freeman wrote
> 
> > Half the reason we don't officially support running without /usr
> > mounted during early boot is that if we actually put everything in /
> > that could conceivably be needed during early boot we'd end up with
> > everything there.  Bluetooth keyboards is a common example.  The
> > console should work during early boot, right?  
> 
>   Seriously... how many people run Bluetooth keyboards on Gentoo
> anyways?

The sarcasm and the rhetorical questions make it tough to tell -- are
you trying here to make an argument that Gentoo should commit to
supporting boot without /usr mounted early?

Re: [gentoo-dev] usr merge

[J. Roeleveld]

[-- Attachment #1: Type: text/plain, Size: 1059 bytes --]

On Sunday, April 10, 2016 10:04:42 AM James Le Cuirot wrote:
> On Sun, 10 Apr 2016 02:09:35 +0200
> 
> "J. Roeleveld" <joost@antarean.org> wrote:
> > I actually write my own initramfs because neither dracut not
> > genkernel end up with a convenient boot system.
> > 
> > I have 2 disks, both encrypted.
> > I prefer only to enter the decryption password once. Both Dracut and
> > Genkernel insist on asking for the password/key for every single disk.
> 
> Dracut on RHEL actually handles this out of the box. Might be worth
> finding out how.

Might have even been fixed in a more recent version of Dracut.
I just have passed the point where I am interested in it enough to try it. The 
initramfs I use gets embedded into the kernel and doesn't need any kernel 
parameters to work.

It does what it needs to do with minimal work. The simplicity should also make 
it faster than the scripts generated by either Dracut or genkernel. (As they 
need to parse the kernel cmdline and try to figure out static details on the 
fly)

--
Joost

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-dev] usr merge

[Raymond Jennings]

[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]

Please don't do this.  I want my system left alone.



On Sun, Apr 10, 2016 at 11:41 PM, J. Roeleveld <joost@antarean.org> wrote:

> On Sunday, April 10, 2016 10:04:42 AM James Le Cuirot wrote:
> > On Sun, 10 Apr 2016 02:09:35 +0200
> >
> > "J. Roeleveld" <joost@antarean.org> wrote:
> > > I actually write my own initramfs because neither dracut not
> > > genkernel end up with a convenient boot system.
> > >
> > > I have 2 disks, both encrypted.
> > > I prefer only to enter the decryption password once. Both Dracut and
> > > Genkernel insist on asking for the password/key for every single disk.
> >
> > Dracut on RHEL actually handles this out of the box. Might be worth
> > finding out how.
>
> Might have even been fixed in a more recent version of Dracut.
> I just have passed the point where I am interested in it enough to try it.
> The
> initramfs I use gets embedded into the kernel and doesn't need any kernel
> parameters to work.
>
> It does what it needs to do with minimal work. The simplicity should also
> make
> it faster than the scripts generated by either Dracut or genkernel. (As
> they
> need to parse the kernel cmdline and try to figure out static details on
> the
> fly)
>
> --
> Joost

[-- Attachment #2: Type: text/html, Size: 1726 bytes --]

Re: [gentoo-dev] usr merge

[J. Roeleveld]

On Monday, April 11, 2016 01:10:15 AM Raymond Jennings wrote:
> Please don't do this.  I want my system left alone.

Please don't top-post, I want to have a logical flow of the text.


> On Sun, Apr 10, 2016 at 11:41 PM, J. Roeleveld <joost@antarean.org> wrote:
> > On Sunday, April 10, 2016 10:04:42 AM James Le Cuirot wrote:
> > > On Sun, 10 Apr 2016 02:09:35 +0200
> > > 
> > > "J. Roeleveld" <joost@antarean.org> wrote:
> > > > I actually write my own initramfs because neither dracut not
> > > > genkernel end up with a convenient boot system.
> > > > 
> > > > I have 2 disks, both encrypted.
> > > > I prefer only to enter the decryption password once. Both Dracut and
> > > > Genkernel insist on asking for the password/key for every single disk.
> > > 
> > > Dracut on RHEL actually handles this out of the box. Might be worth
> > > finding out how.
> > 
> > Might have even been fixed in a more recent version of Dracut.
> > I just have passed the point where I am interested in it enough to try it.
> > The
> > initramfs I use gets embedded into the kernel and doesn't need any kernel
> > parameters to work.
> > 
> > It does what it needs to do with minimal work. The simplicity should also
> > make
> > it faster than the scripts generated by either Dracut or genkernel. (As
> > they
> > need to parse the kernel cmdline and try to figure out static details on
> > the
> > fly)
> > 
> > --
> > Joost

Please d

Re: [gentoo-dev] Re: usr merge

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/04/16 01:18 PM, »Q« wrote:
> On Sat, 9 Apr 2016 12:09:38 -0400 waltdnes@waltdnes.org wrote:
> 
>> On Sat, Apr 09, 2016 at 07:11:31AM -0400, Rich Freeman wrote
>> 
>>> It was simply a recognition that we were already in a state
>>> where booting a system without /usr mounted early can cause
>>> problems.
>> 
>> For certain edge cases... yes.  But they were already using 
>> initramfs or merging /usr into /.  I'm talking about the 95%
>> who don't really need it.
> 
> Booting without /usr mounted early is something Gentoo already
> doesn't support and can't support, right?
> 
> 

It still works for a number of basic cases, but per the Council's
decision quite a while ago, dev's have zero obligation to ensure it
continues to work -- in effect this means it can break at any time.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlcLstQACgkQAJxUfCtlWe2I+AEAyVX2Zh8YDbbCfTtCJ8C3Y1Gk
8OX3on1uKDCFeybThAgA/3g/uI2WyPhdayARsNNGQuX8tD+ejv/mpZjY2UUJPSpv
=3e1w
-----END PGP SIGNATURE-----