| View previous topic :: View next topic |
| Author |
Message |
A.S. Pushkin
Guru
Joined: 09 Nov 2002
Posts: 418
Location: dx/dt, dy/dt, dz/dt, t
|
 Posted: Sat Apr 25, 2020 2:37 am Post subject: 17.1 migration troubles |
 |
|
[Split from 17.1 migration troubles, which featured a different problem. -Hu]
I missed the migration to 17.1 so I finally am prepared, but ran into this problem
One or more files are both in /lib/ and /lib64/, making the conversion impossible.
ld-2.29.so
libBrokenLocale-2.29.so
libBrokenLocale.so.1
libSegFault.so
libanl-2.29.so
libanl.so.1
libc-2.29.so
libc.so.6
libcrypt-2.29.so
libcrypt.so.1
libdl-2.29.so
libdl.so.2
libm-2.29.so
libm.so.6
libmemusage.so
libnsl-2.29.so
libnsl.so.1
libnss_compat-2.29.so
libnss_compat.so.2
libnss_db-2.29.so
libnss_db.so.2
libnss_dns-2.29.so
libnss_dns.so.2
libnss_files-2.29.so
libnss_files.so.2
libnss_hesiod-2.29.so
libnss_hesiod.so.2
libpcprofile.so
libpthread-2.29.so
libpthread.so.0
libresolv-2.29.so
libresolv.so.2
librt-2.29.so
librt.so.1
libthread_db-1.0.so
libthread_db.so.1
libutil-2.29.so
libutil.so.1
I have no clue where to start?
_________________
ASPushkin
"In a time of universal deceit - telling the truth is a revolutionary act." -- George Orwell |
|
| Back to top |
|
 |
figueroa
Advocate
Joined: 14 Aug 2005
Posts: 2958
Location: Edge of marsh USA
|
| Posted: Sat Apr 25, 2020 4:13 am Post subject: |
|
|
| A.S. Pushkin wrote: | I missed the migration to 17.1 so I finally am prepared, but ran into this problem
One or more files are both in /lib/ and /lib64/, making the conversion impossible.
...
I have no clue where to start? |
What did you do to get into that state? How did you find out about the duplicate files? What is your current profile? Did you read/follow the news item with 12 steps to migrate?
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
| Back to top |
|
|
A.S. Pushkin
Guru
Joined: 09 Nov 2002
Posts: 418
Location: dx/dt, dy/dt, dz/dt, t
|
| Posted: Sat Apr 25, 2020 6:02 am Post subject: |
|
|
I wish I knew how I got into this state.
I've just spent some time running on each of the
extraneous files.
The original list plus results of the equery are here.
http://dpaste.com/2N6HB97
They all belong to sys-libs/glibc-2.29-r7. I'm rather lacking on the flags still so I wonder if I put
some flags incorrectly in my configuration.
My current Profile is: | Quote: | | default/linux/amd64/17.0/desktop/plasma (stable) |
| Code: | emerge --info
Portage 2.3.84 (python 3.6.9-final-0, default/linux/amd64/17.0/desktop/plasma, gcc-8.3.0, glibc-2.29-r7, 5.4.28-gentoo x86_64) |
I can not call myself a programmer as my experience is in Autolisp no C or C++
Yes, I'm working through | Quote: | | 2019-06-05 amd64 17.1 profiles are now stable |
having completed a portage update.
I must say that I had started through the migration and found it a problem so Clonezilla
saved my skin, but perhaps I need to go back a month a run through the total process again.
I have never looked at the various directories that closely so I am unable to say when the duplication
occurred.
My #ls -F / did yield similar results to GDH-gentoo.
I should note that I maintain a separate drive for my distfiles as I always download all my files prior to a rebuild.
_________________
ASPushkin
"In a time of universal deceit - telling the truth is a revolutionary act." -- George Orwell |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1524
Location: South America
|
| Posted: Sat Apr 25, 2020 3:17 pm Post subject: |
|
|
| Code: | Running the ls command with upper case "F" as arguement on the root file systemdyields:
#ls -F /
bin/ dev/ etc/ lib@ lib64/ media/ mnt.cdrom/ proc/ run/ sys/ usb/ usr/
boot/ distfiles/ home/ lib32/ lost+found/ mnt/ opt/ root/ sbin/ tmp/ usb-storage/ var/
Note that lib is a symbolic link as shown below where "lib" is the arguement to ls:
#ls -la lib
lrwxrwxrwx 1 root root 5 Jan 30 01:53 lib -> lib64 |
So /lib is a symlink to /lib64, and there is a /lib32 directory. That is correct for profile 17.0. I suspect that Portage is somehow confused about the way sys-libs/glibc-2.29-r7 is installed.
Post the output of:
| Code: | $ portageq envvar SYMLINK_LIB
$ qlist glibc | grep /lib | sort
$ ls -F /lib32 |
|
|
| Back to top |
|
|
UlFie
Tux's lil' helper
Joined: 01 Nov 2011
Posts: 112
Location: Wuppertal
|
| Posted: Sat Apr 25, 2020 5:22 pm Post subject: |
|
|
| A.S. Pushkin wrote: | The original list plus results of the equery are here.
http://dpaste.com/2N6HB97
They all belong to sys-libs/glibc-2.29-r7. |
If I correctly understand what unsymlink-libs (as found in https://github.com/mgorny/unsymlink-lib/blob/master/unsymlink-lib) does, then you must have these files recorded under both /lib/ and /lib64/, but there should be only one of them. And I am not sure if equery b can help here as it may resolve links it comes accross (i.e. with lib -> lib64 it may not actually look for /lib/xxx, but /lib64/xxx), but I do not know what behaviour exactly equery exhibits in this case. Maybe you can try it the other way round and see what files glibc installed under /lib* :
| Code: | | equery f glibc | grep '^/lib' |
You might have installed that with some incorrect setting in the past, and due to /lib being a link to /lib64 only one of the two versions of each of these libraries has survived the installation (making it a surprise you don't have lots of trouble...).
In this case, emerging glibc again with correct settings (whatever these are, you need help from someone else here) might fix your problem. |
|
| Back to top |
|
|
A.S. Pushkin
Guru
Joined: 09 Nov 2002
Posts: 418
Location: dx/dt, dy/dt, dz/dt, t
|
| Posted: Sat Apr 25, 2020 8:37 pm Post subject: |
|
|
UlFie and GDH-gentoo thanks for the insight.
| Code: | portageq envvar SYMLINK_LIB
yes
|
| Code: | | qlist glibc | grep /lib | sort |
yields:
http://dpaste.com/1J6G5KH
yields:
http://dpaste.com/2TFPYX7
Your thought that emerging glibc again crossed my mind yesterday, but I'm unsure what settings may have given this result. I assume it may be a USE flag,
but I'm still not certain on which USE flags I might change.
Thank you very much for your feed back. This is rather new territory, but I suspect it will be one more reason I stick with Gentoo.
I learn something that is invaluable for maintaining the system.
_________________
ASPushkin
"In a time of universal deceit - telling the truth is a revolutionary act." -- George Orwell |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1524
Location: South America
|
| Posted: Sat Apr 25, 2020 10:14 pm Post subject: |
|
|
| Code: | /lib/ld-2.29.so
/lib/ld-linux.so.2
/lib/libanl-2.29.so
/lib/libanl.so.1
[...]
/lib/libutil-2.29.so
/lib/libutil.so.1 |
| Code: | ld-2.29.so* libcrypt-2.29.so* libm.so.6@ libnss_dns-2.29.so* libpthread-2.29.so* libthread_db-1.0.so*
ld-linux.so.2@ libcrypt.so.1@ libnsl-2.29.so* libnss_dns.so.2@ libpthread.so.0@ libthread_db.so.1@
libanl-2.29.so* libc.so.6@ libnsl.so.1@ libnss_files-2.29.so* libresolv-2.29.so* libutil-2.29.so*
libanl.so.1@ libdl-2.29.so* libnss_compat-2.29.so* libnss_files.so.2@ libresolv.so.2@ libutil.so.1@
libBrokenLocale-2.29.so* libdl.so.2@ libnss_compat.so.2@ libnss_hesiod-2.29.so* librt-2.29.so*
libBrokenLocale.so.1@ libm-2.29.so* libnss_db-2.29.so* libnss_hesiod.so.2@ librt.so.1@
libc-2.29.so* libmemusage.so* libnss_db.so.2@ libpcprofile.so* libSegFault.so* |
Well, Portage does seem to be confused. You have libc files in /lib32, which is correct for profile 17.0, but Pörtage claims they are installed in /lib, which is very likely what is confusing unsymlink-lib in turn (which also consults Portage's database through its Python interface). I no longer have a computer with profile 17.0, but I think qlist's output should be showing /lib32 and /usr/lib32 before the migration. Have you switched to profile 17.1 with eselect profile at some point in the past and installed new packages, without performing a proper upgrade?
I am tempted to suggest reinstalling sys-libs/glibc, but I don't know if you have some unusual setup that will result in the same problem. Maybe go ahead and reinstall the package, or post the output of emerge --info sys-libs/glibc? |
|
| Back to top |
|
|
A.S. Pushkin
Guru
Joined: 09 Nov 2002
Posts: 418
Location: dx/dt, dy/dt, dz/dt, t
|
| Posted: Sat Apr 25, 2020 11:20 pm Post subject: |
|
|
GDH-gentoo, thanks for the observations.
I had begun a Profile migration, but decided it was not doing well and this prior to this recent portage upgrade to bring the system
current. I use Clonezilla, which I recommend(on a flash drive) so decided to revert to an older and previous installation. I thought
I had gone back fir enough, but perhaps I did not?
I hate to go back and redo it all over again, but I will back up what I have right now and start from a clearly older installation.
I've more tools to run through the update process thanks to the Gentooers.
Thanks and will see what happens! Thank you Clonezilla too!
_________________
ASPushkin
"In a time of universal deceit - telling the truth is a revolutionary act." -- George Orwell |
|
| Back to top |
|
|
A.S. Pushkin
Guru
Joined: 09 Nov 2002
Posts: 418
Location: dx/dt, dy/dt, dz/dt, t
|
| Posted: Sun Apr 26, 2020 5:18 am Post subject: |
|
|
I hate to ask this, but I'm woefully lacking in interpreting some important output.
I am assuming that when placed in make.conf multilib builds both 32 and 64 bit apps. I've on a hunch
removed it as my 17.0 profile is not multilib.
I've done sync and after doing so I removed the multilib flag. Having done that
I've run | Code: | | emerge -avuDN system |
and as I expected some blocks acme up. Editing portage.use unblocked them, but here is one remainder and I"m unclear how to interpret it:
| Code: | emerge -avDuN system
* IMPORTANT: 2 news items need reading for repository 'gentoo'.
* Use eselect news read to view new items.
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] dev-libs/ell-0.28::gentoo USE="-glib* -pie" ABI_X86="(64) -32* (-x32)" 464 KiB
[ebuild R ] app-arch/xz-utils-5.2.4-r2::gentoo USE="extra-filters nls (split-usr) static-libs threads" ABI_X86="(64) -32* (-x32)" 0 KiB
[ebuild R ] dev-qt/qtgui-5.14.1-r4:5/5.14.1::gentoo USE="X dbus egl gif jpeg libinput png udev -accessibility -debug -eglfs -evdev* -gles2-only -ibus -test -tslib -tuio -vnc -vulkan -wayland" 48,661 KiB
[ebuild R ] sys-apps/dbus-1.12.16::gentoo USE="X elogind -debug -doc (-selinux) -static-libs -systemd -test -user-session" ABI_X86="(64) -32* (-x32)" 0 KiB
[ebuild R ] net-wireless/bluez-5.54:0/3::gentoo USE="cups mesh midi obex readline udev -btpclient -debug -deprecated -doc -experimental -extra-tools (-selinux) -systemd -test -test-programs -user-session" ABI_X86="(64) -32 (-x32)" PYTHON_SINGLE_TARGET="-python3_6* -python3_7 (-python3_8)" 1,957 KiB
[ebuild R ] dev-lang/yasm-1.3.0::gentoo USE="nls -python" PYTHON_SINGLE_TARGET="-python2_7%" PYTHON_TARGETS="(-python2_7%*)" 0 KiB
[ebuild R ] net-misc/networkmanager-1.18.4-r3::gentoo USE="bluetooth dhclient elogind introspection modemmanager ncurses nss (policykit) ppp wext wifi -audit -connection-sharing* -consolekit -dhcpcd* -gnutls* -iwd -json* -ofono -ovs -resolvconf (-selinux) -systemd -teamd -test -vala" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild R ] dev-qt/qtdeclarative-5.14.1-r2:5/5.14::gentoo USE="jit widgets -debug -gles2-only -localstorage* -test -vulkan" 20,801 KiB
[ebuild R ] kde-frameworks/kiconthemes-5.67.0:5/5.67::gentoo USE="-debug -designer* -doc -test" 205 KiB
Total: 9 packages (9 reinstalls), Size of downloads: 72,087 KiB
WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict:
x11-libs/libXext:0
(x11-libs/libXext-1.3.4:0/0::gentoo, ebuild scheduled for merge) USE="-doc -static-libs" ABI_X86="(64) -32 (-x32)" conflicts with
x11-libs/libXext[abi_x86_32(-),abi_x86_64(-)] required by (media-libs/libglvnd-1.3.1:0/0::gentoo, installed) USE="X -test" ABI_X86="32 (64) (-x32)"
>=x11-libs/libXext-1.3.2[abi_x86_32(-),abi_x86_64(-)] required by (x11-libs/libvdpau-1.3:0/0::gentoo, installed) USE="dri -doc -test" ABI_X86="32 (64) (-x32)"
>=x11-libs/libXext-1.3.2[abi_x86_32(-),abi_x86_64(-)] required by (x11-drivers/nvidia-drivers-440.82:0/440::gentoo, installed) USE="X acpi driver kms libglvnd multilib static-libs tools uvm -compat -gtk3 -wayland" ABI_X86="32 (64) (-x32)"
|
I am not certain just what the parentheses mean.
Thanks.
_________________
ASPushkin
"In a time of universal deceit - telling the truth is a revolutionary act." -- George Orwell |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1524
Location: South America
|
| Posted: Sun Apr 26, 2020 3:01 pm Post subject: |
|
|
| A.S. Pushkin wrote: | I am assuming that when placed in make.conf multilib builds both 32 and 64 bit apps. I've on a hunch
removed it as my 17.0 profile is not multilib. |
Unless the profile name contains "no-multilib", it is always a multilib one. However, except for specific packages, 32-bit versions of libraries won't be built by default unless you request it, even if the profile is a multilib one, because USE flag abi_x86_32 is unset by default.
| A.S. Pushkin wrote: | | I've done sync and after doing so I removed the multilib flag. |
What?
| A.S. Pushkin wrote: | | Code: | WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict:
x11-libs/libXext:0
(x11-libs/libXext-1.3.4:0/0::gentoo, ebuild scheduled for merge) USE="-doc -static-libs" ABI_X86="(64) -32 (-x32)" conflicts with
x11-libs/libXext[abi_x86_32(-),abi_x86_64(-)] required by (media-libs/libglvnd-1.3.1:0/0::gentoo, installed) USE="X -test" ABI_X86="32 (64) (-x32)"
>=x11-libs/libXext-1.3.2[abi_x86_32(-),abi_x86_64(-)] required by (x11-libs/libvdpau-1.3:0/0::gentoo, installed) USE="dri -doc -test" ABI_X86="32 (64) (-x32)"
>=x11-libs/libXext-1.3.2[abi_x86_32(-),abi_x86_64(-)] required by (x11-drivers/nvidia-drivers-440.82:0/440::gentoo, installed) USE="X acpi driver kms libglvnd multilib static-libs tools uvm -compat -gtk3 -wayland" ABI_X86="32 (64) (-x32)"
|
|
x11-libs/libXext has abi_x86_32 unset (ABI_X86=-32), but media-libs/libglvnd, x11-libs/libvdpau and x11-drivers/nvidia-drivers have it set (ABI_X86=32). That won't work, abi_x86_32 must be either set for all these packages, or unset for all these packages. |
|
| Back to top |
|
|
A.S. Pushkin
Guru
Joined: 09 Nov 2002
Posts: 418
Location: dx/dt, dy/dt, dz/dt, t
|
| Posted: Sun Apr 26, 2020 10:19 pm Post subject: |
|
|
I went back a corrected the problem you saw.
| Quote: | | x11-libs/libXext has abi_x86_32 unset (ABI_X86=-32), but media-libs/libglvnd, x11-libs/libvdpau and x11-drivers/nvidia-drivers have it set (ABI_X86=32). That won't work, abi_x86_32 must be either set for all these packages, or unset for all these packages. |
It made some small change in the output of unsymlink-lib --analyze. Running it again
yields the below.
http://dpaste.com/0QFZD1E
I've not been comfortable with USE flags, but it is clear my understanding is worse than I had thought.
There are now only 39 libraries blocking the migration from Profile 17.0 to 17.1
I see lot of orphaned files that will be moved, but if they are orphaned do I need them. My knowledge of
libraries is rather limited, but they remind me of external references used in CAD. What my configuration
included to create so many I am not sure.
I'm posting my make.conf as the secret of my error may be there.
http://dpaste.com/37V2KXZ
Thanks.
_________________
ASPushkin
"In a time of universal deceit - telling the truth is a revolutionary act." -- George Orwell |
|
| Back to top |
|
|
UlFie
Tux's lil' helper
Joined: 01 Nov 2011
Posts: 112
Location: Wuppertal
|
| Posted: Mon Apr 27, 2020 12:22 am Post subject: |
|
|
Excuse me, but what have you done? This looks like things became a lot worse. Are you sure you are not yet working with a 17.1 profile? Your recent installations seem to have added libraries from several packages to /lib and /lib64 that (for a 17.0 profile) should only be in one of them, at least emerge has recorded this in its database. Furthermore, you have a lot of orphaned files, but I could imagine this is because an emerge @preserved-rebuild is still waiting to be done, though I fear that could make the list of conflicts even longer as long as the reason for these unexpected additions to the list of conflicts is unclear. It might be helpful to see the output of
| Code: | | ls -FlaR /etc/portage |
and the contents of /var/log/emerge.log |
|
| Back to top |
|
|
A.S. Pushkin
Guru
Joined: 09 Nov 2002
Posts: 418
Location: dx/dt, dy/dt, dz/dt, t
|
| Posted: Mon Apr 27, 2020 3:20 am Post subject: |
|
|
I rolled back my Gentoo Box to prior to an attempt to migrate to Profile 17.1
Here is the out put of | Code: | | ls -FlaR /etc/portage |
http://dpaste.com/1N1REEM
On | Code: | | emerge @preserved-rebuild |
I constantly anf for a long time have this
to follow many emerges:
| Code: | No outdated packages were found on your system.
* GNU info directory index is up-to-date.
!!! existing preserved libs:
>>> package: media-libs/gst-plugins-base-0.10.36-r2
* - /usr/lib64/libgstinterfaces-0.10.so.0
* - /usr/lib64/libgstinterfaces-0.10.so.0.25.0
* used by /usr/lib64/openoffice/program/libavmediagst.so (app-office/openoffice-bin-4.1.7)
>>> package: media-libs/gstreamer-0.10.36-r2
* - /usr/lib64/libgstreamer-0.10.so.0
* - /usr/lib64/libgstreamer-0.10.so.0.30.0
* used by /usr/lib64/openoffice/program/libavmediagst.so (app-office/openoffice-bin-4.1.7)
Use emerge @preserved-rebuild to rebuild packages using these libraries |
Looking at the list of files where one or more files are in both /usr/lib/ and /usr/lib64/ making migration impossible
I came up with six packages that are a problem: x11-libs/libXau, x11-libs/libXdmcp, sys-apps/util-linux, sys-libs/zlib,
dev-libs/libpcre,and sys-apps/sandbox
I checked my emerge and I did emerge unsymlink-lib on 10Apr2020, but this current install was started from prior to that..
I may back the current state up with Clonezilla and install an image from earlier in March and check what /lib, /lib32 and /lib64
look like.
http://dpaste.com/31XGTA1
One other thought. I just noticed there are similar packages. I wonder if I need both:
dev-libs/libpcre and dev-libs/libpcre2
Thanks
_________________
ASPushkin
"In a time of universal deceit - telling the truth is a revolutionary act." -- George Orwell |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Mon Apr 27, 2020 4:22 am Post subject: |
|
|
What you should do is only care about your problem
And your problem is easy, unable to run the unsymlink program because of the errors shown.
It's how i would go:
1/ ident files that block me: easy, you already have that list, unsymlink is giving you that list
| Code: | One or more files are both in /usr/lib/ and /usr/lib64/, making the conversion impossible.
libXau.so
libXau.so.6
libXau.so.6.0.0
... |
/2 when lib and lib64 are real directory, lib is use for 32bits, and lib64 for 64bits, having both files in the same directory mean you have lost the 32bits or the 64bits version, nobody cares about the 32bits version, but we "may" (who cares if libXau is not working, we only cares about critical for the system files, critical to allow portage/gcc... to be able to build) cares about the 64bits
So the best to do is removing their version from the /lib directory and keep the other version from /lib64
Once done, unsymlink should be able to do the work
3/ remove useless cases: orphans files and directory (i would say move them elsewhere, but you have a good backup, so cleaning looks ok), and unmerge openoffice-bin to stop any complain and because you could easy re-emerge a binary package and it will be broken anyway ; with that idea in mind, i would also just rm /var/lib/portage/preserved_libs_registry
Once you are able to run unsymlink with success, continue from step 9 in the news (changing profile) |
|
| Back to top |
|
|
UlFie
Tux's lil' helper
Joined: 01 Nov 2011
Posts: 112
Location: Wuppertal
|
| Posted: Mon Apr 27, 2020 2:20 pm Post subject: |
|
|
| krinn wrote: | So the best to do is removing their version from the /lib directory and keep the other version from /lib64
|
I'm afraid that's a misunderstanding of how unsymlink-lib works, and as lib is a symlink to lib64, you can't remove a file from one of them without removing it from the other anyway. As I have mentioned earlier, unsymlink-lib looks at a database where emerge records all the files it installs, and that database says that files with the same name have been installed to both /lib and /lib64, and with the symlink only one of them can have survived. With a 17.0 profile used during emerge, this should not happen.
I know nothing about Clonezilla, but I wonder if it backs up really everything, i.e. both the installed libraries and the database in which they are recorded. But if you are using that, you could either try to go back to a point in time before libraries started to get installed so wrongly (but you may not even have a backup from that time) or to a point where the number of conflicts is minimal. That point where only glibc files were involved wasn't that bad, so let's assume you start from there. Then you should try to emerge glibc again, and if that fails because of dependencies or other conflicts, these need to be resolved (but I would assume that's easier with just one package as a starting point, even if it is such a vital one). If you are really, really brave (and I mean REALLY!) you could try emerging glibc with --nodeps, but you might end up with a completely dysfunctional system. Then again, at that point your Clonezilla might be helpful (if you can run that from some rescue system).
Admittedly, I am overwhelmed by the sheer number of keyword/use/mask files. Some conflicts might be resolvable by simply getting rid of some installed packages, but to cleanly do this you must of course be in a state after a successful deep @world update. Note to myself: Never mess up your system!  |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Mon Apr 27, 2020 4:18 pm Post subject: |
|
|
| UlFie wrote: | | I'm afraid that's a misunderstanding of how unsymlink-lib works, and as lib is a symlink to lib64, you can't remove a file from one of them without removing it from the other anyway. |
The only way to have a file in double, is to have /lib and /lib64 that are not symlink, else you don't have a double file, you just have the same file.
And it goes the same for your assumption that it look at emerge database, if file X is write to be in location /lib in the database, then if you emerge the package again so the location of X goes in /lib64, the database will now be update and will hold the new location, because the package that create X is still the same package, and you would then could only have one entry for X.
I think user was in middle of migration and endup with /lib is already a directory and unsymlink has start copy content into it, making the duplicate (because it didn't remove original to have a chance to revert it)
That's something he could easy check by looking if his /lib is a directory or still a symlink
| Quote: | | that database says that files with the same name have been installed to both /lib and /lib64 |
I also doubt that, if your database record only the filename, then you would had millions complains because of classic filename that appears everywhere (readme, COPYING, make, configure...)...
To me unsymlink just do check the file presence on disk in /lib and /lib64, no need to read/open or manipulate any database to see in this case you cannot go futher because you will be unable to know what file to remove and what file to keep, so you will stop the program and tell user why. And this is what unsymlink say to user.
I don't pretend i know how unsymlink works, i didn't even use it myself (it's just an helper), i have just delete the symlinks and replace them with true directories and discard any 32bits, and fix who need 32bits later: see https://forums.gentoo.org/viewtopic-p-8366428.html#8366428
But until you prove me my logic is false and unsymlink works as you think, i will still think i'm closer to how it works than you
ps: find any "possible" answer and i will just say you are right, no way i would dig unsymlink code to check you're saying truth  |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1524
Location: South America
|
| Posted: Mon Apr 27, 2020 7:13 pm Post subject: |
|
|
| A.S. Pushkin wrote: | Looking at the list of files where one or more files are in both /usr/lib/ and /usr/lib64/ making migration impossible
I came up with six packages that are a problem: x11-libs/libXau, x11-libs/libXdmcp, sys-apps/util-linux, sys-libs/zlib,
dev-libs/libpcre,and sys-apps/sandbox |
I'm going to bet those are packages that were installed with USE=abi_x86_32, have 32-bit libraries in /usr/lib32, but Portage thinks they are in /usr/lib. I think it's just the same that happened with the libc before.
| UlFie wrote: | | I'm afraid that's a misunderstanding of how unsymlink-lib works, and as lib is a symlink to lib64, you can't remove a file from one of them without removing it from the other anyway. As I have mentioned earlier, unsymlink-lib looks at a database where emerge records all the files it installs, and that database says that files with the same name have been installed to both /lib and /lib64, and with the symlink only one of them can have survived. With a 17.0 profile used during emerge, this should not happen. |
Agreed.
| UlFie wrote: | | I know nothing about Clonezilla, but I wonder if it backs up really everything, i.e. both the installed libraries and the database in which they are recorded. |
Same.
| krinn wrote: | | To me unsymlink just do check the file presence on disk in /lib and /lib64, no need to read/open or manipulate any database [...] |
Hmmm.
unsymlink-lib
| Code: | def analyze(self, usr_merge, real_prefixes):
from portage import create_trees, _encodings
log('Analyzing files installed into lib & lib64...')
# ...
trees = create_trees(config_root=self.eroot)
vardb = trees[max(trees)]['vartree'].dbapi
# ...
for p in vardb.cpv_all():
for f, details in vardb._dblink(p).getcontents().items(): |
From Portage:
lib/portage/dbapi/vartree.py
| Code: | class vartree(object):
"this tree will scan a var/db/pkg database located at root (passed to init)"
def __init__(self, root=None, virtual=DeprecationWarning, categories=None,
settings=None):
# ...
self.dbapi = vardbapi(settings=settings, vartree=self) |
lib/portage/dbapi/vartree.py
| Code: | class vardbapi(dbapi):
def __init__(self, _unused_param=DeprecationWarning,
categories=None, settings=None, vartree=None):
# ...
def _dblink(self, cpv):
category, pf = catsplit(cpv)
return dblink(category, pf, settings=self.settings,
vartree=self.vartree, treetype="vartree") |
lib/portage/dbapi/vartree.py
| Code: | class dblink(object):
"""
This class provides an interface to the installed package database
At present this is implemented as a text backend in /var/db/pkg.
"""
# ...
def __init__(self, cat, pkg, myroot=None, settings=None, treetype=None,
vartree=None, blockers=None, scheduler=None, pipe=None):
# ...
def getcontents(self):
"""
Get the installed files of a given package (aka what that package installed)
"""
# ...
contents_file = os.path.join(self.dbdir, "CONTENTS")
pkgfiles = {}
try:
with io.open(_unicode_encode(contents_file,
encoding=_encodings['fs'], errors='strict'),
mode='r', encoding=_encodings['repo.content'],
errors='replace') as f: |
I'n not going to read the full code, but this does look like an access to Portage's database to me. Furthermore, do you want to have a look at what the /var/db/pkg/*/*/CONTENTS files contain  ? |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3267
Location: Canada
|
| Posted: Mon Apr 27, 2020 8:00 pm Post subject: |
|
|
| krinn wrote: |
| Quote: | | that database says that files with the same name have been installed to both /lib and /lib64 |
I also doubt that, if your database record only the filename, then you would had millions complains because of classic filename that appears everywhere (readme, COPYING, make, configure...)...
To me unsymlink just do check the file presence on disk in /lib and /lib64, no need to read/open or manipulate any database to see in this case you cannot go futher because you will be unable to know what file to remove and what file to keep, so you will stop the program and tell user why. And this is what unsymlink say to user.
|
I also think so, since unsymlink is very fast, much faster than any database inquiries would be |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Tue Apr 28, 2020 9:05 am Post subject: |
|
|
| GDH-gentoo wrote: | | I'n not going to read the full code |
you win! |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1524
Location: South America
|
| Posted: Tue Apr 28, 2020 1:08 pm Post subject: |
|
|
| ... other that the quoted snippets, which look like unsymlink-lib iterating over the contents of the /var/db/pkg/*/*/CONTENTS files using Portage's Python interface |
|
| Back to top |
|
|
A.S. Pushkin
Guru
Joined: 09 Nov 2002
Posts: 418
Location: dx/dt, dy/dt, dz/dt, t
|
| Posted: Tue Apr 28, 2020 10:22 pm Post subject: |
|
|
I used unsymlink-lib to tell me what the blockers were. .After deleting
the blockers from /usr/lib unsymlink-lib gave me the OK to proceed
and I ran the closing commands. My system booted but SLIM was broken
I logged in the terminal and followed the profile migration, but discovered that
sandbox is broken.
I backed up the system before continuing so I can go back.
Any suggestions?
Thanks.
_________________
ASPushkin
"In a time of universal deceit - telling the truth is a revolutionary act." -- George Orwell
Last edited by A.S. Pushkin on Wed Apr 29, 2020 2:27 am; edited 1 time in total |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Tue Apr 28, 2020 10:35 pm Post subject: |
|
|
| A.S. Pushkin wrote: | | Any sugegstions? |
Stayon 17.0
You don't have to follow everything Red Hat does. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Tue Apr 28, 2020 11:24 pm Post subject: |
|
|
| Tony0945 wrote: | | A.S. Pushkin wrote: | | Any sugegstions? |
Stayon 17.0
You don't have to follow everything Red Hat does. |
And when 17.0 is eventually deprecated and removed?
Out of curiosity I just checked migration for the first time, and unsymlink-lib is overly concerned about what I have in /usr/local. | Code: | | /usr/local/lib64 needs to exist as a real directory! |
Then | Code: | | /usr/local/lib is a real directory! was the migration done already? |
Seems to be a problem similar to if not an extension of Is it just me, or should baselayout not touch /usr/local?
I'm not sure I'm up for doing it manually / having to deal with disaster recovery, which doesn't leave me in a good long term position.
edit / fixed link.
_________________
Quis separabit? Quo animo?
Last edited by pjp on Wed Apr 29, 2020 2:45 am; edited 1 time in total |
|
| Back to top |
|
|
UlFie
Tux's lil' helper
Joined: 01 Nov 2011
Posts: 112
Location: Wuppertal
|
| Posted: Wed Apr 29, 2020 1:24 am Post subject: |
|
|
| A.S. Pushkin wrote: | After deleting
the blockers from /usr/lib unsymlink-lib gave me the OK to proceed |
You had previously let us know that /lib was a link to /lib64, but haven't let us know about /usr/lib yet. If it is a symlink to /usr/lib64, then you have deleted the files not only from /usr/lib, but also from /usr/lib64. Although I haven't analysed unsymlink-lib as thoroughly as GDH-gentoo (thanks for your support of my argument!), I'm quite sure that after such deletions this script should warn about missing files and recommend reinstallation of the packages these files belong to. So just do that reinstallation, and I would assume that your problems with dysfunctional programs go away. With all the problems you have had, you may even want to reinstall each and every package on your system using emerge -e (see the man page). |
|
| Back to top |
|
|
UlFie
Tux's lil' helper
Joined: 01 Nov 2011
Posts: 112
Location: Wuppertal
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
