Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #265735 > unrolled thread

disable auto-linking of /bin -> /usr/bin/

Back to article view | Back to linux.debian.user

Contents

  disable auto-linking of /bin -> /usr/bin/ miphix <miphix@insomnia247.nl> - 2024-01-10 06:20 +0100
    Re: disable auto-linking of /bin -> /usr/bin/ <tomas@tuxteam.de> - 2024-01-10 06:50 +0100
      Re: disable auto-linking of /bin -> /usr/bin/ Jeffrey Walton <noloader@gmail.com> - 2024-01-10 08:00 +0100
        Re: disable auto-linking of /bin -> /usr/bin/ Tim Woodall <debianuser@woodall.me.uk> - 2024-01-10 08:10 +0100
    Re: disable auto-linking of /bin -> /usr/bin/ Tim Woodall <debianuser@woodall.me.uk> - 2024-01-10 07:40 +0100
    Re: disable auto-linking of /bin -> /usr/bin/ Andy Smith <andy@strugglers.net> - 2024-01-10 17:40 +0100
      Re: disable auto-linking of /bin -> /usr/bin/ Mike Castle <dalgoda+debian@gmail.com> - 2024-01-10 19:50 +0100
        Re: disable auto-linking of /bin -> /usr/bin/ <tomas@tuxteam.de> - 2024-01-10 20:00 +0100
          Re: disable auto-linking of /bin -> /usr/bin/ Mike Castle <dalgoda+debian@gmail.com> - 2024-01-10 20:50 +0100
            Re: disable auto-linking of /bin -> /usr/bin/ tomas@tuxteam.de - 2024-01-11 06:50 +0100
            Re: disable auto-linking of /bin -> /usr/bin/ Michael Stone <mstone@debian.org> - 2024-01-11 14:20 +0100
        /usr on NFS (was: Re: disable auto-linking of /bin -> /usr/bin/) Andy Smith <andy@strugglers.net> - 2024-01-10 22:40 +0100
    Re: disable auto-linking of /bin -> /usr/bin/ Stefan Monnier <monnier@iro.umontreal.ca> - 2024-01-11 05:10 +0100

#265735 — disable auto-linking of /bin -> /usr/bin/

If you were to issue 'ls -l /' You'll find that /bin, /sbin,
lib{32,64,x32} are linked to their counterparts in /usr/. I under-
stand the logic in doing so. However, for specific reasons that would
require exhaustive explanations that I would prefer to save us all from
me doing, I would like to break this behaviour by having /usr genuinely
be whole heartedly installed on its own partition. I'm cool with doing
things the hard and painful way. Any details you can share that would
allow me to figure out how to break, or divert this behaviour would
be appreciated. I'm not elite with linux enough to figure this out,
but I am comfertable with digging deep with the right background
knowledge to navigate what's needed.

[toc] | [next] | [standalone]

#265736

[Multipart message — attachments visible in raw view] — view raw

Hi, miphix

On Wed, Jan 10, 2024 at 05:06:33AM +0000, miphix wrote:
> If you were to issue 'ls -l /' You'll find that /bin, /sbin,
> lib{32,64,x32} are linked to their counterparts in /usr/. I under-
> stand the logic in doing so. However, for specific reasons that would
> require exhaustive explanations that I would prefer to save us all from
> me doing, I would like to break this behaviour by having /usr genuinely
> be whole heartedly installed on its own partition. I'm cool with doing
> things the hard and painful way. Any details you can share that would
> allow me to figure out how to break, or divert this behaviour would
> be appreciated. I'm not elite with linux enough to figure this out,
> but I am comfertable with digging deep with the right background
> knowledge to navigate what's needed.

The jargon for this thing is "usrmerge". With that, search engines
turn up some hits on other people with your same needs, e.g.

  https://brontosaurusrex.github.io/2023/09/11/Upgrade-Debian-11-to-12-without-usrmerge-errors/

I don't know whether some applications start breaking because of that
(why should they, but there's badly designed software everywhere).

Cheers & good luck
-- 
tomás

[toc] | [prev] | [next] | [standalone]

#265738

On Wed, Jan 10, 2024 at 12:49 AM <tomas@tuxteam.de> wrote:
>
> On Wed, Jan 10, 2024 at 05:06:33AM +0000, miphix wrote:
> > If you were to issue 'ls -l /' You'll find that /bin, /sbin,
> > lib{32,64,x32} are linked to their counterparts in /usr/. I under-
> > stand the logic in doing so. However, for specific reasons that would
> > require exhaustive explanations that I would prefer to save us all from
> > me doing, I would like to break this behaviour by having /usr genuinely
> > be whole heartedly installed on its own partition. I'm cool with doing
> > things the hard and painful way. Any details you can share that would
> > allow me to figure out how to break, or divert this behaviour would
> > be appreciated. I'm not elite with linux enough to figure this out,
> > but I am comfertable with digging deep with the right background
> > knowledge to navigate what's needed.
>
> The jargon for this thing is "usrmerge". With that, search engines
> turn up some hits on other people with your same needs, e.g.
>
>   https://brontosaurusrex.github.io/2023/09/11/Upgrade-Debian-11-to-12-without-usrmerge-errors/
>
> I don't know whether some applications start breaking because of that
> (why should they, but there's badly designed software everywhere).

I think some programs can break, like those that assume / and /usr are
both mounted early in the boot process. I think the only guarantee is
/ will be mounted early, and all programs needed to boot are available
from /. I thought there was a discussion about some problems with
systemd when / and /usr are different mount points (and only / is
mounted early), but I can't find it at the moment.

Also see <https://news.ycombinator.com/item?id=30929024> and
<https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=usrmerge>.

Jeff

[toc] | [prev] | [next] | [standalone]

#265739

On Wed, 10 Jan 2024, Jeffrey Walton wrote:

>
> I think some programs can break, like those that assume / and /usr are
> both mounted early in the boot process. I think the only guarantee is
> / will be mounted early, and all programs needed to boot are available
> from /. I thought there was a discussion about some problems with
> systemd when / and /usr are different mount points (and only / is
> mounted early), but I can't find it at the moment.
>

Yes, I thought systemd requires /usr mounted by the initrd.

[toc] | [prev] | [next] | [standalone]

#265737

On Wed, 10 Jan 2024, miphix wrote:

> If you were to issue 'ls -l /' You'll find that /bin, /sbin,
> lib{32,64,x32} are linked to their counterparts in /usr/. I under-
> stand the logic in doing so. However, for specific reasons that would
> require exhaustive explanations that I would prefer to save us all from
> me doing, I would like to break this behaviour by having /usr genuinely
> be whole heartedly installed on its own partition. I'm cool with doing
> things the hard and painful way. Any details you can share that would
> allow me to figure out how to break, or divert this behaviour would
> be appreciated. I'm not elite with linux enough to figure this out,
> but I am comfertable with digging deep with the right background
> knowledge to navigate what's needed.
>
>

This is a very complex migration in progress.

IIRC, before bookworm not having merged usr will work. bookworm will
probably work, but it will fight you and it's not supported, and trixie
plain just won't work.

By the time trixie is released, everything will be in /usr according to
dpkg. Scripts may no longer have consistent paths to the same
application.

[toc] | [prev] | [next] | [standalone]

#265742

Hello,

On Wed, Jan 10, 2024 at 05:06:33AM +0000, miphix wrote:
> If you were to issue 'ls -l /' You'll find that /bin, /sbin,
> lib{32,64,x32} are linked to their counterparts in /usr/. I under-
> stand the logic in doing so. However, for specific reasons that would
> require exhaustive explanations that I would prefer to save us all from
> me doing, I would like to break this behaviour by having /usr genuinely
> be whole heartedly installed on its own partition.

Why do you believe that putting /usr on its own partition will
break anything, much less anything to do with usrmerge?

Debian has always supported /usr on its own partition; the only
thing that changed in recent history is that such a mount will take
place in the initramfs. The use case that was rendered unsupported
at that time was separate usr *with no initramfs*¹.

As you can still symlink /bin to /usr/bin even when /usr is
mounted from somewhere else, usrmerge should still work too.

Perhaps you have some reason for not wanting a usrmerged system that
isn't what you explained. I'd be interested to know what it was if
so, but I don't think it is a good idea.

The reasons why I think that are:

1) a non-usrmerged layout is not supported. You are going to make
   life hard for yourself by encountering problems that Debian
   maintainers aren't obliged to care about.

2) Most other distros are already usrmerged long before Debian was.
   So every other piece of software "outside" Debian is expecting
   that layout too.

We can stroke our real or imaginary beards until the cows come home
about whether it is bad form to assume usrmerge or whatnot but is it
a hill you want to die on?

> I am comfertable with digging deep with the right background
> knowledge to navigate what's needed.

Thing is, at this point it's being different just for the sake of
it, as far as I can see.

Thanks,
Andy

¹ There was another use-case which is "sharing a read-only /usr
  between systems by NFS, etc." but at the time this was widely
  regarded a lost cause as so many other things violated the
  premise.

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#265750

On Wed, Jan 10, 2024 at 9:53 AM Andy Smith <andy@strugglers.net> wrote:
> น There was another use-case which is "sharing a read-only /usr
>   between systems by NFS, etc." but at the time this was widely
>   regarded a lost cause as so many other things violated the
>   premise.

I did that for years.

Then again, when I started doing that, I was using PLIP over a
null-printer cable.  But even after I could afford larger harddrives
(so I had room to install /usr), and Ethernet cards (and later a hub),
I still ran /usr over NFS.

Personally, I'm rather saddened by usrmerge.  But, such is life.

mrc

[toc] | [prev] | [next] | [standalone]

#265752

[Multipart message — attachments visible in raw view] — view raw

On Wed, Jan 10, 2024 at 10:41:05AM -0800, Mike Castle wrote:
> On Wed, Jan 10, 2024 at 9:53 AM Andy Smith <andy@strugglers.net> wrote:
> > น There was another use-case which is "sharing a read-only /usr
> >   between systems by NFS, etc." but at the time this was widely
> >   regarded a lost cause as so many other things violated the
> >   premise.
> 
> I did that for years.
> 
> Then again, when I started doing that, I was using PLIP over a
> null-printer cable.  But even after I could afford larger harddrives
> (so I had room to install /usr), and Ethernet cards (and later a hub),
> I still ran /usr over NFS.
> 
> Personally, I'm rather saddened by usrmerge.  But, such is life.

For me it's one of those fairly harmless but useless churns.

Yes, the main reason for the separation of /usr has more or less
disappeared with the arrival of initramfs, but still... why.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#265757

On Wed, Jan 10, 2024 at 10:57 AM <tomas@tuxteam.de> wrote:
> Yes, the main reason for the separation of /usr has more or less
> disappeared with the arrival of initramfs, but still... why.

To some extent, it will make it easier for packaging.

Look at any package built using autoconf, for instance, you run:
./configure --prefix=/usr

Well, except for those you want installed in /, in which case you use
'--prefix=/'

But, what if you don't want all of those in /, you want some in / and
some in /usr?  Requires more manual work on part of the package
maintainer to make sure that things work properly, that files are
split across the destinations properly, reference config files
appropriately, and so on.

With usrmerge, that particular class of problems goes away.

Back when I used my own home grown distribution (I was doing Linux
>From Scratch before LFS was even a thing), that was one of the issues
I'd run into every once in a while.

mrc

[toc] | [prev] | [next] | [standalone]

#265775

[Multipart message — attachments visible in raw view] — view raw

On Wed, Jan 10, 2024 at 11:49:02AM -0800, Mike Castle wrote:
> On Wed, Jan 10, 2024 at 10:57 AM <tomas@tuxteam.de> wrote:
> > Yes, the main reason for the separation of /usr has more or less
> > disappeared with the arrival of initramfs, but still... why.
> 
> To some extent, it will make it easier for packaging.

Yes, I get that. It's one of those flourishes which lie around
and somewhat complicate things. But given the drama of those
transitions, many of them just stay put and get the label "for
histerical raisins" slapped on, until the world changes so much
that they lose relevance anyway.

To me this one had the taste of a manichæan purge, but hey.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#265783

On Wed, Jan 10, 2024 at 11:49:02AM -0800, Mike Castle wrote:
>To some extent, it will make it easier for packaging.

No, not at all--new packages have not had to worry about putting things 
anywhere but /usr for a long time. Only old packages (for which the work 
you described had been done years, if not decades, ago) needed logic to 
split things up, and that required essentially zero ongoing effort.

The benefits you describe came from elminating the requirement that a 
system boot from / without /usr being mounted, and don't require moving 
anything.

[toc] | [prev] | [next] | [standalone]

#265761 — /usr on NFS (was: Re: disable auto-linking of /bin -> /usr/bin/)

Hello,

On Wed, Jan 10, 2024 at 10:41:05AM -0800, Mike Castle wrote:
> I did that for years.
> 
> Then again, when I started doing that, I was using PLIP over a
> null-printer cable.  But even after I could afford larger harddrives
> (so I had room to install /usr), and Ethernet cards (and later a hub),
> I still ran /usr over NFS.

You can still do it if you want, as long as your initramfs mounts
/usr from nfs, which I'm pretty sure it will without any difficulty
if you have the correct entry in /etc/fstab. I don't think anything
has gone out of its way to break that use it's just that it's been
given up on, and I don't blame Debian for that since it would mean
lots of work to bend upstream authors to a use case that they have
no interest in.

Time moved on and the way to do "immutable OS" evolved.

Just a couple of days ago I retired a Debian machine that had been
running constantly for 18½ years from the mostly-read-only 512M
CompactFlash boot device it came with. 😀

    https://social.bitfolk.com/@grifferz/111704438510674644

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#265771

> If you were to issue 'ls -l /' You'll find that /bin, /sbin,
> lib{32,64,x32} are linked to their counterparts in /usr/. I under-
> stand the logic in doing so. However, for specific reasons that would
> require exhaustive explanations that I would prefer to save us all from
> me doing, I would like to break this behaviour by having /usr genuinely
> be whole heartedly installed on its own partition.

As mentioned by Andy, the symlinks still work fine when `/usr` is on
another partition.

> I'm cool with doing things the hard and painful way. Any details you
> can share that would allow me to figure out how to break, or divert
> this behaviour would be appreciated. I'm not elite with linux enough
> to figure this out, but I am comfertable with digging deep with the
> right background knowledge to navigate what's needed.

Assuming you still want to "unmerge" / and /usr, for some reason, I'd
start by replacing those top-level symlinks with directories full
of symlinks.  E.g. replace the `/bin` symlink with a fresh new `/bin`
directory which contains symlinks to everything in `/usr/bin`.

That should be pretty safe.  After that, you can start removing some of
those many symlinks, e.g. for those executables that have never lived in
`/bin` (you can (still) use `dpkg -L` or `dpkg -S` to figure out if
that executable "belongs to /usr or to /").

You may also decide to move some executables from `/usr/bin` to `/bin`
and place a symlink in `/usr/bin` for those (a.k.a. reverse the
direction of those symlinks).


        Stefan

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web