re the nfs server is not running linux). Or even better maybe
the package maintainer might adjust the script within usrmerge to work
properly with nfs using these ideas.
- Starting from bullseye (I rolled back to a snapshot pre-install of
usrmerge), downloaded src of usrmerge to get access to t
patched out the dpkg complaints about usrmerge, but they
> have _not_ added proper support for it. For instance, the problem
> mentioned by the OP is present in Ubuntu's dpkg.
I'm sorry, I was not aware of that and I stand corrected.
Thanks!
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
On 2023-10-06 22:32 +, Andy Smith wrote:
> On Fri, Oct 06, 2023 at 04:42:56PM +0200, Urs Thuermann wrote:
>> Greg Wooledge writes:
>>
>> > Yeah, usrmerge is a bit wonky in these early stages.
>>
>> $ apt-get changelog usrmerge | tail -n2
>>
Hello,
On Fri, Oct 06, 2023 at 04:42:56PM +0200, Urs Thuermann wrote:
> Greg Wooledge writes:
>
> > Yeah, usrmerge is a bit wonky in these early stages.
>
> $ apt-get changelog usrmerge | tail -n2
> -- Marco d'Itri Tue, 04 Nov 2014 22:42:44 +0100
> Fet
Greg Wooledge writes:
> Yeah, usrmerge is a bit wonky in these early stages.
$ apt-get changelog usrmerge | tail -n2
-- Marco d'Itri Tue, 04 Nov 2014 22:42:44 +0100
Fetched 11.0 kB in 0s (58.9 kB/s)
Not what I'd call 'early' stages.
> Part of the reason for this is tha
Marco writes:
> Am 06.10.2023 schrieb Steve Keller :
>
> > I have always been sceptical about /usr merge, since all binaries now
> > appear in two places, "type sh" in bash gives the strange looking
> > /usr/bin/sh where all Uni*ers are strongly used to /bin/sh. But also
> > things like the
On Fri, Oct 06, 2023 at 11:06:56AM +0200, Steve Keller wrote:
> $ dpkg -S $(type -p sh)
> dpkg-query: no path found matching pattern /usr/bin/sh
>
> And I don't see a comfortable way around this.
Yeah, usrmerge is a bit wonky in these early stages. Part o
Am 06.10.2023 schrieb Steve Keller :
> I have upgraded from bullseye to bookworm and it seems the package
> usrmerge is installed forcedly now. At least it has been installed
> and I haven't been asked about it :-(
>
> I have always been sceptical about /usr merge, since a
I have upgraded from bullseye to bookworm and it seems the package usrmerge is
installed forcedly now. At least it has been installed and I haven't been
asked about it :-(
I have always been sceptical about /usr merge, since all binaries now appear in
two places, "type sh" in
On Thu, 14 Sep 2023 22:17:35 +0200
Marco wrote:
> If I screw with this I'd prefer to do it at night or on a weekend to
> keep the systems running during business hours.
Followup:
I went through the list and resolved each conflict manually. I
launched usrmerge after every change and d
ot *one* Debian installation, it's many (diskless
workstations PXE boot). Each host has it's own root on the NFS.
Some stuff is shared, but that's not relevant here.
> - You're trying to do an upgrade to Debian 12 running on one of the
> clients.
Not on one on *all* clients.
> - I
tiple clients
- You're trying to do an upgrade to Debian 12 running on one of the
clients.
- It tries to do a usrmerge but aborts because NFS is not supported
by that script?
If so, have you tried reporting a bug on this yet? It seems like an
interesting problem which although being quite a c
> So the file in /lib appears to be newer. So what to do? Can I delete
> the one in /usr/lib ?
Yes.
Stefan
d to see if you might have an
> idea how to merge them?
Yes, I did. On some hosts they are identical, on others they're
different. That's why I asked how to handle that.
> `usrmerge` did give you a pretty clear explanation of the problem it's
> facing (AFAIC)
It does indeed.
> and
On Thu, 14 Sep 2023 16:43:09 -0400
Dan Ritter wrote:
> The heart of the convert-usrmerge perl script is pretty
> reasonable. However:
>
> […]
>
> Similarly, there are calls to stat and du which probably have
> some incompatibilities.
>
> The effect of runnin
Still going on with this?
Have you actually looked at those two files:
/lib/udev/rules.d/60-libsane1.rules and
/usr/lib/udev/rules.d/60-libsane1.rules
to see if they're identical or not and to see if you might have an idea
how to merge them?
[ as I suggested a week ago. ]
`usrmerge` did
On Thu, 14 Sep 2023 15:01:50 -0400
Dan Ritter wrote:
> Is this a mission-critical server?
I'd say so, yes. It's not one single server. It's *all*
workstations.
> i.e. will screwing it up for a day cause other people to be upset
Yes, because no one can use their computer.
> or you to lose
s are raw disk
access (ZVOL), NFS and Samba.
However, usrmerge is a perl script. Can I run it on the server
(after chroot'ing) in a jail (under FreeBSD)? Or does this mess
things up? Just a thought.
Marco
On Thu, 14 Sep 2023 11:00:17 -0400
Dan Ritter wrote:
> What VM software are you using
bhyve
…which I know very little about. It's supported on the server, I've
tried it, set up a VM, it works. But the server is mainly serving
NFS shares to various clients.
> and what's the OS on which that
Marco wrote:
> On Fri, 8 Sep 2023 12:26:38 -0400
> Dan Ritter wrote:
> > * have the VM mount the filesystem directly
>
> How? I can only attach devices (=whole disks) to the VM or mount the
> FS via NFS. I can't attach it as a device because it's not a device,
> rather than a directory with the
This leaves me with an NFS mount in the VM. But NFS mounts are not
supported by usrmerge, that's the whole issue I'm facing here.
So this VM-on-the-server idea doesn't work in my case or am I
missing something here?
Another question: if usrmerge complains that the file is present in
/lib as w
to check the following days.
>
> > If so, you can
> > * stop your remote Debian machine
> > * run a Debian rescue image in the VM on the NFS server
> > * have the VM mount the filesystem directly
> > * chroot, run usrmerge
> > * unmount
>
> Ok, that'
ue image in the VM on the NFS server
> * have the VM mount the filesystem directly
> * chroot, run usrmerge
> * unmount
Ok, that's also quite a task, but it seems less error-prone than
copying a bunch of system files across the network and hope for the
best. I'll try.
Marco
> root@foobar:~# /usr/lib/usrmerge/convert-usrmerge
>
> FATAL ERROR:
> Both /lib/udev/rules.d/60-libsane1.rules and
> /usr/lib/udev/rules.d/60-libsane1.rules exist.
The problem is that "usrmerge" needs to unify those two and doesn't
know how. So you need to do
On Fri, 8 Sep 2023 16:55:23 +0200
zithro wrote:
> On 08 Sep 2023 12:54, Marco wrote:
> >Warning: NFS detected, /usr/lib/usrmerge/convert-usrmerge will
> > not be run automatically. See #842145 for details.
>
> Read :
> - https://bugs.debian.org/cgi-bin/bugrep
On 08 Sep 2023 12:54, Marco wrote:
Warning: NFS detected, /usr/lib/usrmerge/convert-usrmerge will not be run
automatically. See #842145 for details.
Read :
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842145
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039522
The solution
Hi,
I'm in the process of upgrading my Debian stable hosts and run into
a problem with usrmerge:
Setting up usrmerge (35) ...
Warning: NFS detected, /usr/lib/usrmerge/convert-usrmerge will not be run
automatically. See #842145 for details.
E: usrmerge failed.
dpkg: error processing
Le lundi 12 juin 2023 à 14:02 -0400, Jeffrey Walton a écrit :
> On Mon, Jun 12, 2023 at 5:48 AM Bastien Durel
> wrote:
> >
> > Hello,
> >
> > During bookworm upgrade, I ran into some usrmerge failures, which
> > led
> > to an hard-to-fix situ
On Mon, Jun 12, 2023 at 09:35:13PM +, bw wrote:
> Right now I'm studying and trying to come up with a way to identify duplicate
> filenames and/or symlinks between /bin /sbin /lib, and /usr/bin /usr/sbin
> /usr/lib. I bet someone on the list could do it in a one line command.
Well, it's not
in-reply-to=
>> On Mon, Jun 12, 2023 at 11:24:00AM +0200, Bastien Durel wrote:
> During bookworm upgrade, I ran into some usrmerge failures, which led
> to an hard-to-fix situation
...
>>Well, that's somewhat terrifying. I looked at bugs.debian.org/usrmerge
>>and
On Mon, Jun 12, 2023 at 5:48 AM Bastien Durel
wrote:
>
> Hello,
>
> During bookworm upgrade, I ran into some usrmerge failures, which led
> to an hard-to-fix situation
>
> Paramétrage de usrmerge (35) ...
>
> FATAL ERROR:
> Both /lib/x86_64-linux-gnu/libidn.so.11 an
But don't count on my success.
>
> I've succeeded in *partially* reproducing this error, but not fully.
> My resulting state simply has usrmerge failing with the OP's error
> message, and each subsequent instance of /usr/lib/usrmerge/convert-usrmerge
> giving the same error again. I d
producing this error, but not fully.
My resulting state simply has usrmerge failing with the OP's error
message, and each subsequent instance of /usr/lib/usrmerge/convert-usrmerge
giving the same error again. I do not get the GLIBC errors, nor do I
get an unusable system.
Here's what I did:
1) Star
On Mon, Jun 12, 2023 at 11:24:00AM +0200, Bastien Durel wrote:
>
> During bookworm upgrade, I ran into some usrmerge failures, which led
> to an hard-to-fix situation
>
> Paramétrage de usrmerge (35) ...
>
> FATAL ERROR:
> Both /lib/x86_64-linux-gnu/libidn.so.11 and
>
Hello,
During bookworm upgrade, I ran into some usrmerge failures, which led
to an hard-to-fix situation
Paramétrage de usrmerge (35) ...
FATAL ERROR:
Both /lib/x86_64-linux-gnu/libidn.so.11 and
/usr/lib/x86_64-linux-gnu/libidn.so.11 exist.
You can try correcting the errors reported
)
Tim.
To followup here:
If the docker container already has merged usr (/bin is a symlink to
/usr/bin etc) then usr-is-merged should install - it has no
dependencies.
if usr-is-merged is installed then the upgrade of base-files will not
(I
believe) pull in usrmerge and therefore you
What you said about overlayfs is true and usrmerge is imho giving a
rather clear error message.
That said, I thought the best practice for docker containers is to throw
them away and rebuild them and that upgrading containers is frowned upon?
If you build / pull a new bookworm docker
container already has merged usr (/bin is a symlink to
/usr/bin etc) then usr-is-merged should install - it has no
dependencies.
if usr-is-merged is installed then the upgrade of base-files will not (I
believe) pull in usrmerge and therefore you will not get the configure
error.
What I'm not sure
wrote:
Anybody can help me or confirm me that it?s a bug and I need to open a bug
issue ?
#9 28.26 Preparing to unpack .../archives/usrmerge_33_all.deb ...
#9 28.28 Unpacking usrmerge (33) ...
#9 28.32 Setting up usrmerge (33) ...
#9 28.42 Warning: overlayfs detected, /usr/lib/usrmerge/convert
On Thu, 27 Oct 2022, Hogren wrote:
Anybody can help me or confirm me that it?s a bug and I need to open a bug
issue ?
#9 28.26 Preparing to unpack .../archives/usrmerge_33_all.deb ...
#9 28.28 Unpacking usrmerge (33) ...
#9 28.32 Setting up usrmerge (33) ...
#9 28.42 Warning: overlayfs
Le 27 octobre 2022 20:03:57 GMT+02:00, "Andrew M.A. Cater"
a écrit :
>On Thu, Oct 27, 2022 at 09:05:54AM -0400, Greg Wooledge wrote:
>> On Thu, Oct 27, 2022 at 06:55:12AM -0600, Charles Curley wrote:
>> > On Thu, 27 Oct 2022 09:47:39 +0200
>> > Hogren wrote:
>> >
>> > > RUN echo 'deb
On Thu, Oct 27, 2022 at 09:05:54AM -0400, Greg Wooledge wrote:
> On Thu, Oct 27, 2022 at 06:55:12AM -0600, Charles Curley wrote:
> > On Thu, 27 Oct 2022 09:47:39 +0200
> > Hogren wrote:
> >
> > > RUN echo 'deb http://deb.debian.org/debian testing main' >
> > > /etc/apt/sources.list
> >
> > I
On Thu, Oct 27, 2022 at 06:55:12AM -0600, Charles Curley wrote:
> On Thu, 27 Oct 2022 09:47:39 +0200
> Hogren wrote:
>
> > RUN echo 'deb http://deb.debian.org/debian testing main' >
> > /etc/apt/sources.list
>
> I haven't yet read the entire email, but this sticks out like a sore
> thumb. It
On Thu, 27 Oct 2022 09:47:39 +0200
Hogren wrote:
> RUN echo 'deb http://deb.debian.org/debian testing main' >
> /etc/apt/sources.list
I haven't yet read the entire email, but this sticks out like a sore
thumb. It is almost certainly not what you want. This completely
obliterates your entire
ind-rule-perl
libgdbm-compat4 libgdbm6
#9 2.126 libnumber-compare-perl libperl5.34 libssl3 libtext-glob-perl
netbase perl
#9 2.126 perl-modules-5.34 sensible-utils usrmerge util-linux-extra
#9 2.128 The following packages have been kept back:
#9 2.129 libsemanage-common passwd
#9 2.130 T
Sent this earlier, but it doesn't show up on the list, so I must have
used 'reply to sender' instead of 'reply to list'... :(
Op 03-10-2022 om 15:30 schreef billium:
There was no failed or manual moves. usrmerge may have failed during
previous upgrades and I may not have noticed.
Please do
ended up in
two places (earlier failed usrmerge? another script? manually after
all?), but in my view there are only two possible ways to fix this: the
clean one (reinstalling) and the messy one (completing the usrmerge
manually).
Be aware that the latter comes with no guarantees whatsoever and will
r failed usrmerge? another script? manually after
all?), but in my view there are only two possible ways to fix this: the
clean one (reinstalling) and the messy one (completing the usrmerge
manually).
Be aware that the latter comes with no guarantees whatsoever and will
probably fail massively if you didn
/libc.so.6? Both files?
And /lib/x86_64-linux-gnu and /usr/lib/x86_64-linux-gnu? Both directories?
Did you by any chance copy (or move or symlink) individual files before
the usrmerge upgrade?
Regards,
Frank
Thanks Frank
/usr/bin /usr/lib* & /usr/sbin are directories
/lib/x86_64-linux-gnu &a
-linux-gnu and /usr/lib/x86_64-linux-gnu? Both directories?
Did you by any chance copy (or move or symlink) individual files before
the usrmerge upgrade?
Regards,
Frank
On 02/10/2022 18:19, Michael Stone wrote:
On Sun, Oct 02, 2022 at 06:12:45PM +0100, billium wrote:
may be I am idiot for keeping it so long since a re-install. I think
stretch was the install, and it is now on bookworm.
FYI, skipping releases is not supported; in future, go through each
On Sun, Oct 02, 2022 at 06:12:45PM +0100, billium wrote:
may be I am idiot for keeping it so long since a re-install. I think
stretch was the install, and it is now on bookworm.
FYI, skipping releases is not supported; in future, go through each
release in order when upgrading. Whether that
On 02/10/2022 15:32, Michael Biebl wrote:
On Sat, Oct 01, 2022 at 11:06:55AM +0100, billium wrote:
Since the last update to my debian testing I am unable to install
anything
or upgrade.
Setting up usrmerge (31) ...
FATAL ERROR:
Both /lib/x86_64-linux-gnu/libc.so.6 and
/usr/lib/x86_64-linux
On Sat, Oct 01, 2022 at 11:06:55AM +0100, billium wrote:
Since the last update to my debian testing I am unable to install anything
or upgrade.
Setting up usrmerge (31) ...
FATAL ERROR:
Both /lib/x86_64-linux-gnu/libc.so.6 and /usr/lib/x86_64-linux-gnu/libc.so.6
exist.
How did you arrive
space will be used.
Setting up usrmerge (31) ...
FATAL ERROR:
Both /lib/x86_64-linux-gnu/libc.so.6 and
/usr/lib/x86_64-linux-gnu/libc.so.6 exist.
You can try correcting the errors reported and running again
/usr/lib/usrmerge/convert-usrmerge until it will complete without errors.
Do not install
:
aurora:~# apt autoremove
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 604 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up usrmerge
On Sat, Oct 01, 2022 at 11:06:55AM +0100, billium wrote:
> Since the last update to my debian testing I am unable to install anything
> or upgrade.
>
> Setting up usrmerge (31) ...
>
> FATAL ERROR:
> Both /lib/x86_64-linux-gnu/libc.so.6 and /usr/lib/x86_64-linux-gnu/libc.s
Since the last update to my debian testing I am unable to install
anything or upgrade.
Setting up usrmerge (31) ...
FATAL ERROR:
Both /lib/x86_64-linux-gnu/libc.so.6 and
/usr/lib/x86_64-linux-gnu/libc.so.6 exist.
I can move the stated file and create a symlink but there are so many
files
le libre.
> La vraie question que je me pose depuis que des trucs comme ça sont
> apparus (je classe systemd, dbus et usrmerge dans la même catégorie)
> est de savoir si les développeurs actuels des linuxeries sont bien
> conscients des détails techniques qui ont permis d'arrive
rivers/md/raid456.ko
usr/sbin/mdadm
Le risque zéro n'existe pas (donc faites une sauvegarde complète
et préparez une clé de récupération avant toute manipulation de
ce type ;), mais pour peu que les pilotes soient effectivement
présents dans l'initrd, un usrmerge devrait bien se passer,
besoin
de /usr pour qu'il démarre jusqu'au bout. Pour un Unix traditionnel
(c'est-à-dire dans usrmerge), tu as besoin :
- - du noyau
- - éventuellement de ses modules (dans /lib sous Linux, /stand ailleurs..
.)
- - de /bin et /sbin
- - de /lib
- - de /etc pour la configuration
- - éventuellement d
Le 25-06-2021, à 09:09:32 +, Hugues Larrive a écrit :
Sur un système avec tout dans la même partition ça ne devrait pas poser de
problème, même en mettant tous les binaires dans un dossier unique avec
des liens symboliques de leurs dossiers d'origine pointant dessus ça devrait
fonctionner.
donc rester comme je suis en attendant d'autres réponses
peut-être moins anxiogènes…
J'ai utilisé usrmerge sur mon PC perso sans problème. Il n'y avait
qu'une partition pour l'ensemble du système.
--
==
| FRÉDÉRIC MASSOT
Le 24-06-2021, à 08:48:45 +0200, BERTRAND Joël a écrit :
Personnellement, tant que je peux garder / et /usr séparées, je le
ferai. Et lorsque ce sera une obligation, je passerai à autre chose.
Et bien c'est rassurant comme réponse :)
Je vais donc rester comme je suis en attendant
steve a écrit :
> Bonjour,
>
> Dans un autre post concernant pulseaudio, Hugues parle de usrmerge. Je
> teste sur mon système:
>
> ls -ail /
>
> 12 drwxr-xr-x 2 root root 12288 23 jun 09:52 bin
> 917506 drwxr-xr-x 2 root root 12288 10 jun 08:36 sbin
&g
Bonjour,
Dans un autre post concernant pulseaudio, Hugues parle de usrmerge. Je
teste sur mon système:
ls -ail /
12 drwxr-xr-x 2 root root 12288 23 jun 09:52 bin
917506 drwxr-xr-x 2 root root 12288 10 jun 08:36 sbin
262146 drwxr-xr-x 17 root root 4096 7 jun 08:27 lib
66 matches
Mail list logo
