You are not logged in.
Just tested a new Daedalus install in a VM: the installer fails to execute the usrmerge program when answering yes to the question. It never came to my mind that this might be the case. Its also no translation error (I am using German language), no matter if Y or N, no usrmerge. I executed it past the netinstall without mirror connection. Its executed and shown later by the links in Caja (MATE DE).
I guess I will file a bug report tomorrow.
Offline
I vaguely recall early versions of the daedalus mini.iso installer failing when I opted out.
Current versions are fine -- I wonder if this is what fixed it ;-)
Offline
This bit me this morning:
sed (4.9-2) unstable; urgency=medium
[ Gioele Barabucci ]
* Support <nodoc> build profile. closes: #1051792.
[ Clint Adams ]
* Patch from Helmut Grohne to move sed to /usr/bin. closes: #1059821.
-- Clint Adams <clint@debian.org> Mon, 01 Jan 2024 18:37:14 -0500
I manually added a symbolic link from /bin/sed to /usr/bin/sed afterwards.
Fortunately the recent coreutils update still installed programs in /bin:
coreutils (9.4-3) unstable; urgency=low
* remove arch restriction from libssl-dev build-depend
* revert cp -n behavior to debian 12 & prior (Closes: #1058752)
* add deprecation/compatibility warning for above
-- Michael Stone <mstone@debian.org> Tue, 02 Jan 2024 08:54:03 -0500
Offline
Status as of today:
* Crosscheck with a Bookworm VM shows that there the links from bin/sbin/lib are present.
* VM with a Chimaera installation that was upgraded from Beowulf does not show the links nor is the usrmerge package installed.
* Wrote a bug report against the installer, #824
* Manually converted the Chimaera VM and my two Excalibur VMs with different DEs to usrmerge. Links are present now. Chimaera went smooth, on the two Excalibur VMs I had to remove some files from /lib/udev.
Last edited by rolfie (2024-01-03 16:51:17)
Offline
More fun today with grep and egrep and fgrep moving to /usr/bin
eudev apparently tries to find egrep in /bin and I had only added a symbolic link for /bin/grep to /usr/bin/grep at the time.
Offline
Maintaner: Anibal Monsalve Salazar <anibal@debian.org>
Like for sed, maintainer Clint Adams <clint@debian.org>, the only motivations for those moves are hubris and deliberate intent to cause trouble.
Online
Now it's the turn of kmod / libkmod2
After experimenting, it seems to work if one upgrades to version (31-1), then create the following symbolic links:
# cd /sbin
am64:/sbin# ln -s /usr/sbin/depmod depmod
am64:/sbin# ln -s /usr/sbin/insmod insmod
am64:/sbin# ln -s /usr/sbin/modinfo modinfo
am64:/sbin# ln -s /usr/sbin/modprobe modprobe
am64:/sbin# ln -s /usr/sbin/rmmod rmmod
EDIT, forgot lsmod:
cd /sbin
ln -s /usr/sbin/lsmod lsmod
then re-installing kmod (31-1) so that update-initramfs is run successfully.
Last edited by mirrortokyo (2024-01-10 06:47:15)
Offline
Maintainer: Marco d'Itri <md@linux.it> ... hubris and deliberate intent to cause trouble.
Online
I would *assume* that a merged /usr would have moved everything in /sbin to /usr/sbin and replaced /sbin with a symlink to /usr/sbin (and similar for /bin, /lib, etc). But that's probably too simple for the designers to think of.
Offline
... hubris and deliberate intent to cause trouble.
Problems aside, this gave me a good chuckle.
Offline
As someone once said,
Never ascribe to malice that which is adequately explained by incompetence.
Supposedly by Napoleon, according to my sources, but I was told that's a misattribution. Unfortunately I forgot the name of the "real" author.
Offline
eudev apparently tries to find egrep in /bin and I had only added a symbolic link for /bin/grep to /usr/bin/grep at the time.
I may have encountered this issue today when I upgraded Excalibur on a couple of different laptops. I saw some eudev errors during boot, but I wasn't able to find any related info anywhere in /var/log. Is there somewhere else these errors might have been logged?
Anything that accessed the display backlight had stopped working: console blanking no longer turned off the backlight, and brightnessctl couldn't find the display. Also, I'm not sure if it was related, but X would no longer start with the modesetting driver. Oddly, it still worked with the Intel and nouveau drivers (on different machines.)
I went ahead and installed the usrmerge package. It failed on the first pass, but I got lucky, and only had to delete a few relatively unimportant files to get it to finish. Everything seemed to be working normally again on the next boot, with no errors reported.
Edited to add: I just ran usrmerge on the second laptop with zero errors, which was a pleasant surprise. The backlight is working again on this machine as well; however, a Minecraft server is still failing to start, so it appears I still have other issues. The Minecraft issue was due to a Java update, and unrelated to usrmerge. All is now working on this system as well.
Last edited by stultumanto (2024-01-07 11:39:49)
Offline
Interesting thread on Slackware about it.
https://www.linuxquestions.org/question … 175732250/
Offline
Latest issues:
[UPGRADE] dmsetup:i386 2:1.02.185-2 -> 2:1.02.185-3
this moves /sbin/dmsetup to /usr/sbin/dmsetup
initramfs-tools 0.142 uses /sbin/dmsetup in /usr/share/initramfs-tools/hooks/dmsetup
The easiest temporary solution was to downgrade the following packages:
[DOWNGRADE] dmsetup:i386 2:1.02.185-3 -> 2:1.02.185-2
[DOWNGRADE] libdevmapper-dev:i386 2:1.02.185-3 -> 2:1.02.185-2
[DOWNGRADE] libdevmapper-event1.02.1:i386 2:1.02.185-3 -> 2:1.02.185-2
[DOWNGRADE] libdevmapper1.02.1:i386 2:1.02.185-3 -> 2:1.02.185-2
Alternatively, (and this would require a boot from rescue media and mounting the root file system and being careful to make the symbolic links point correctly),
moving /lib/i386-linux-gnu to /usr/lib/i386-linux-gnu and providing a symbolic link from /lib/i386/linux-gnu to ../usr/lib/i386-linux-gnu
and moving /lib/modules to /usr/lib/modules and providing a symbolic link from /lib/modules to ../usr/lib/modules
and moving /lib/udev/* to /usr/lib/udev and providing a symbolic link from /lib/udev to ../usr/lib/udev
then rebooting without the rescue media
then upgrade dmsetup / libdevmapper and then create a symbolic link from /sbin/dmsetup to /usr/sbin/dmsetup
Last edited by mirrortokyo (2024-01-08 14:42:02)
Offline
Interesting read here: https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge
Q: Does dpkg support merged-/usr-via-aliased-dirs?
A: No. This approach is considered broken by design and breaks many common expectations.Further down in the page:
Debian officially only supports merged-/usr-via-aliased-dirs systems. Converting to an unmerged-/usr setup might break the system in unexpected ways in the future, including data loss or failure to boot.
I don't know what to make out of this.
Offline
I don't know what to make out of this.
...I'm nobody, but I'm thinkin' what ralph said is pretty accurate...
the only motivations for those moves are hubris and deliberate intent to cause trouble
Offline
Apparently dpkg started displaying a warning about this issue to users sometime last year, I'm not sure if it still does. Someone filed a bug report about it last year:
https://bugs.debian.org/cgi-bin/bugrepo … 994388#132
More discussion at lwn.net, including a comment from the responsible party, and some critical responses:
https://lwn.net/Articles/889026/
I can't vouch for the accuracy of the comments, but one person in the lwn.net thread posted the following:
There is no actual breakage. Apart from a few minor issues that were fixed long ago, everything else is purely theoretical constructions that nobody has ever seen outside of manually-crafted examples in the 3 years this has been the default for new Debian and Ubuntu installations... The reality is that you personally don't like the change. Which is cool. And it appears you are using your position to try to block it and retroactively justify it using old dpkg bugs, giving yourself a veto over the technical committee.
Offline
hostname (3.23+nmu2) unstable; urgency=medium
* Non-maintainer upload.
* Install into /usr/bin instead of /bin. (Closes: #1056978)-- Chris Hofstaedtler <zeha@debian.org> Mon, 27 Nov 2023 14:03:42 +0100
If they are going to do that, why not put a symbolic link from /bin/hostname to /usr/bin/hostname like I have to do manually?
Offline
If they are going to do that, why not put a symbolic link from /bin/hostname to /usr/bin/hostname like I have to do manually?
Because the plan is to empty /bin completely and replace it with a symlink to /usr/bin. This article explains it in vague terms: https://www.freedesktop.org/wiki/Softwa … eUsrMerge/
Like for sed, maintainer Clint Adams <clint@debian.org>, the only motivations for those moves are hubris and deliberate intent to cause trouble.
They're just maintainers, they follow the party line: https://lists.debian.org/debian-devel-a … 00003.html
Offline
cpio:amd64 2.14+dfsg-1 -> 2.15+dfsg-1
broke because /bin/mt-gnu no longer existed:
Errors were encountered while processing:
cpio
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up cpio (2.15+dfsg-1) ...
update-alternatives: error: alternative path /bin/mt-gnu doesn't exist
dpkg: error processing package cpio (--configure):
installed cpio package post-installation script subprocess returned error exit status 2
Errors were encountered while processing:
cpio
Press Return to continue, 'q' followed by Return to quit.
cd /bin
ln -s /usr/bin/mt-gnu mt-gnu
and re-running aptitude resulted in:
Performing actions...
Setting up cpio (2.15+dfsg-1) ...
Press Return to continue, 'q' followed by Return to quit.
Postscript, I also created a symbolic link from /bin/cpio to /usr/bin/cpio just in case some program hard codes the path or has /bin in the path but not /usr/bin.
changelog:
cpio (2.15+dfsg-1) unstable; urgency=medium
* New upstream release
Noteworthy changes in this release:
- Fix operation of --no-absolute-filenames --make-directories
- Restore access and modification times of symlinks in copy-in
and copy-pass modes.
* Update debian/watch
* Move files to /usr
Patch by Helmut Grohne <helmut@subdivi.de>
Closes: #1059756
Last edited by mirrortokyo (2024-01-16 13:53:39)
Offline
Funnily enough, package acl was also updated, removing files from /bin to /usr/bin but also creating symbolic links:
acl (2.3.1-6) unstable; urgency=medium
* Take DPKG_ROOT into account in maintainer scripts.
-- Guillem Jover <guillem@debian.org> Tue, 16 Jan 2024 04:32:54 +0100
acl (2.3.1-5) experimental; urgency=medium
* Move programs to their canonical location under /usr, and flip the
direction of the backward compatibility symlinks. Closes: #1060156
-- Guillem Jover <guillem@debian.org> Sun, 07 Jan 2024 04:28:06 +0100
ls -al /bin|grep acl
lrwxrwxrwx 1 root root 14 Jan 16 23:55 chacl -> /usr/bin/chacl
lrwxrwxrwx 1 root root 16 Jan 16 23:55 getfacl -> /usr/bin/getfacl
lrwxrwxrwx 1 root root 16 Jan 16 23:55 setfacl -> /usr/bin/setfacl
How come other packages don't have backward compatibility symlinks?
Offline
Now it's the turn of nano:
Setting up nano (7.2-2) ...
Installing new version of config file /etc/nanorc ...
update-alternatives: error: alternative path /bin/nano doesn't exist
dpkg: error processing package nano (--configure):
installed nano package post-installation script subprocess returned error exit status 2
cd /bin
ln -s /usr/bin/nano nano
after which:
Performing actions...
Setting up nano (7.2-2) ...
Press Return to continue, 'q' followed by Return to quit.
Debian changelog:
nano (7.2-2) unstable; urgency=medium
[ Jordi Mallach ]
* The "Pellets" release.
* Fix a partial sync of debian/nanorc in the previous upload.
This updates some example bindings to the new syntax, avoiding
having control characters in the configuration file (closes: #1032422).
* Build-Depend on pkgconf instead of pkg-config.
* Update Standards-Version to 4.6.2, with no changes needed.
[ Chris Hofstaedtler ]
* Install all files below /usr. (Closes: #1059411)
Keep update-alternatives calls unchanged to preserve user
configuration.
-- Jordi Mallach <jordi@debian.org> Wed, 17 Jan 2024 01:35:55 +0100
Last edited by mirrortokyo (2024-01-17 07:02:48)
Offline
TDR rant:
changing where packages install files so that they end up in /usr/{bin|sbin|lib} can only be expected to happen one package at a time (or with packages that have dependencies on each other package's versions), so those packages should create symbolic links from /{bin|sbin|lib} if directories /{bin|sbin|lib} themselves aren't symbolic links to /usr/{bin|sbin|lib}
So far, I've only noticed package acl "doing the right thing" by leaving symbolic links in /bin pointing to the new binaries in /usr/bin
I have finally moved anything in /bin that is not a symbolic link to /usr/bin to /usr/bin
Also, moved anything in /sbin that is not a symbolic link to /usr/sbin to /usr/sbin
WARNING ln, ls, mv are in /bin - if you don't already have copies of ls, ln and mv in /usr/bin you should probably copy the versions in /bin to /usr/bin before doing a move / link that involves mv, ls and ln.
Alternatively, just leave files from package coreutils in /bin.
The tactic that I used was to run a command like:
cd /bin
ls -lt|grep -v /usr/bin|more
to see files grouped by date of installation.
It turned out that many newly updated packages had the newer files in /bin but there were still files from the same packages in /usr/bin from older versions of the packages.
So what I needed to do was move the files from /bin to /usr/bin a few packages at a time, then create symbolic links from /bin to /usr/bin
To do this I ran:
cd /bin
ls -lt|grep -v /usr/bin|awk '{print $9}' > tmp.tmp
then manually edited tmp.tmp to just include the file/link names of the oldest few packages.
Then I ran the following to move the files/links to /usr/bin:
cat tmp.tmp|xargs -i mv {} /usr/bin
and the following to create symbolic links in the /bin/directory:
cat tmp.tmp|xargs -i ln -s /usr/bin/{} {}
This was repeated until all file/link names in /bin that weren't symbolic links to /usr/bin had been moved to /usr/bin and sybolic links from /bin to /usr/bin created.
I then did the same for /sbin:
cd /sbin
ls -lt|grep -v /usr/sbin|awk '{print $9}' > tmp.tmp
edit tmp.tmp manually to only include file/link names from a few packages at a time, then ran
cat tmp.tmp|xargs -i mv {} /usr/sbin
to move the files/links to /usr/sbin and
cat tmp.tmp|xargs -i ln -s /usr/sbin/{} {}
to create symbolic links from /sbin to /usr/sbin:
Again, this was repeated until all file/link names in /bin that weren't symbolic links to /usr/sbin had been moved to /usr/sbin and sybolic links from /bin to /usr/bin created.
I then re-ran:
update-initramfs -u -k $(uname -r)
to make sure that update-initramfs was using the latest installed packages.
Last edited by mirrortokyo (2024-01-18 08:57:36)
Offline
dpkg: warning: This system uses merged-usr-via-aliased-dirs, going behind dpkg's
dpkg: warning: back, breaking its core assumptions. This can cause silent file
dpkg: warning: overwrites and disappearances, and its general tools misbehavior.
dpkg: warning: See <https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge>.
I haven't seen this one before, is this new? The phrase "going behind [one's] back" implies deception, which really crosses a line.
Offline
Got the same message on my two Testing/Excalibur VMs, not on my laptop running Chimaera and Daedalus. All three with usrmerge applied.
Looked at the linked FAQ: What I understand from my limited English Debian is broken, there are completely contradicting messages and no solution. The team does not seem to know how to attack this usrmerge process.
Last edited by rolfie (2024-01-29 19:29:23)
Offline