| 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: Wed Apr 29, 2020 2:32 am Post subject: |
 |
|
pjp thanks for that feed back. I assumed that migration was
necessary. It was rolled out almost a year ago so I wonder
i that has created the problem in my system.
Thank God for Clonezilla! I' may roll back and go back
and look at my list of blocking libraries.
Thanks again.
_________________
ASPushkin
"In a time of universal deceit - telling the truth is a revolutionary act." -- George Orwell |
|
| Back to top |
|
 |
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Wed Apr 29, 2020 3:02 am Post subject: |
|
|
@UlFie: Thanks, fixed. Forgot to change from topic to post.
| A.S. Pushkin wrote: | pjp thanks for that feed back. I assumed that migration was
necessary. It was rolled out almost a year ago so I wonder
i that has created the problem in my system.
Thank God for Clonezilla! I' may roll back and go back
and look at my list of blocking libraries. |
It's existence seems very unlikely to have caused a problem. The most likely scenario was something going wrong in the conversion.
I'm inclined to delay converting in hopes that a "better alternative" presents itself.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
A.S. Pushkin
Guru
Joined: 09 Nov 2002
Posts: 418
Location: dx/dt, dy/dt, dz/dt, t
|
| Posted: Thu Apr 30, 2020 2:49 am Post subject: |
|
|
Well, thanks to Clonezilla I rolled back to a installation that I used to
delete blacking libraries in /usr/lib64 Whether I delete them in /usr/lib
or /usr/lib64 the same thing occurs. When I run the arguement
--migrate and then --finish
No errors seem to occur through Step 9 of the Profile Migration,
but 10, rebuilding the tool chain emerging gcc fails as
I note that among the output errors when trying to re-emerge gcc
are
| Quote: | ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded
cannot open shared object file> |
I had noted that some of the applications were, I assume, 32-bit, so
I did not touch those. I deleted libraries in /usr/lib64 with similar results
to when deleting them from /usr/lib
I may try this again but not delete they symbolic links.
Thnaks
_________________
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: Fri May 01, 2020 3:21 pm Post subject: |
|
|
pjp
Question: Is it possible to rebuild my system without doing full reinstall but using 64 bit only?
I assume abi_x86_32 while abi_x86_64 means 64 bit. I set these had indicated when installing
packages.
Is there any documentation I can look at?
Thanks.
_________________
ASPushkin
"In a time of universal deceit - telling the truth is a revolutionary act." -- George Orwell |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Fri May 01, 2020 10:55 pm Post subject: |
|
|
It is possible, but if I've ever done it, it was before 2010.
https://packages.gentoo.org/useflags/abi_x86_64
I'd work on one thing at a time. Start out with a system that has everything updated to your portage repository. You don't necessarily need to sync again. Be sure you've done the usual depclean and revdep-rebuild checks.
I'd then look at what was required to convert to abi_x86_64.
After that, I'd determine why/if rebuilding the entire system was what I wanted to do.
I thought there was a document about upgrading and the toolchain, but I'm not finding it. Perhaps it was a thread.
With that in mind, I've not had any problems with using the various documents about upgrading GCC, so that's probably where I'd go after abi_x86_64. Depending on what you find there, you may decide to incorporate that into upgrading the whole system.
https://wiki.gentoo.org/wiki/Upgrading_GCC
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
A.S. Pushkin
Guru
Joined: 09 Nov 2002
Posts: 418
Location: dx/dt, dy/dt, dz/dt, t
|
| Posted: Sat May 02, 2020 2:18 am Post subject: |
|
|
pjp
Thanks you for that info. I may try it as I can always rollback thanks to Clonezilla.
If I have any thing to report I'll be certain to do so.
_________________
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: 1530
Location: South America
|
| Posted: Sat May 02, 2020 4:23 pm Post subject: |
|
|
I think it's time for you to start looking more closely at what you are doing with Clonezilla, and gaining a deeper understanding. Judging by your recent posts, after your repeated "rollbacks", it looks like Portage's idea about your installed packages never completely matches what is actually present in the filesystem, as UlFie pointed out. Until you somehow manage to bring them in alignment, you'll just run into an endless list of problems. Symptoms:
- At different times, for different packages, unsymlink-lib (and Portage, indirectly) claimed that there were files installed in both /lib and /lib64, but that is simply impossible for profile 17.0: one is a symlink to the other. Likely explanation: at some point you made an incomplete migration to profile 17.1, for which /lib and /lib64 are indeed different directories, and then you proceeded to install or update packages, so Portage correctly started recording that 32-bit libraries were installed in /lib, and 64-bit libraries (with the same name!) were installed in /lib64. But when you rolled back to the 17.0 layout, Portages's database, and therefore its idea of installed packages, seemed not to reflect the change.
- At some point, unsymlik-lib claimed that you had tons of orphaned files. While I don't have all the packages you have, comparing files for those that I do, it seems that they are from an older version of their corresponding packages. Likely explanation: your rollbacks reinstalled those files, but again Portage's database seemed not to reflect the change, because it claims that no package owns them.
- This. Likely explanation: Portage's recorded information about kde-apps/akonadi's files does not match what is actually in the filesystem. Likely explanation: they are from an older version that your rollbacks put back again, but Portage doesn't know.
| A.S. Pushkin wrote: | I deleted libraries in /usr/lib64 with similar results
to when deleting them from /usr/lib
I may try this again but not delete they symbolic links. |
...and if this means that you are actually deleting files by a means other than emerge --unmerge or emerge --oneshot (e.g. directly rm'ing them), you are just making things worse.
| A.S. Pushkin wrote: | pjp thanks for that feed back. I assumed that migration was
necessary. |
Profile 17.1 is Gentoo's current standard setup, at least for amd64. Each time you deviate from the standard setup, you are in effect creating a little fork. Gentoo makes this easy, and IMO that is one of its killer features, that sets it apart from every other distribution. But it also means that you effectively become the sole maintainer of your 'forks', and, therefore, you must be ready for taking on the extra work of making them play well with the rest of the system. The more of them you have, the less your system looks like Gentoo, and the more it looks like Linux From Scratch (LFS). Alternative repositories (a.k.a 'overlays') are kind of a middle ground: depending on how many of their offered packages overlap Gentoo's official repository, they are also kind of 'forks', but you are 'outsourcing' their maintainance to the corresponding repository owner(s) (If the overlap is small, they are more 'extensions' than 'forks'). |
|
| Back to top |
|
|
A.S. Pushkin
Guru
Joined: 09 Nov 2002
Posts: 418
Location: dx/dt, dy/dt, dz/dt, t
|
| Posted: Mon May 04, 2020 5:29 am Post subject: |
|
|
I just stumbled on this old bug post:
dev-util/cmake: stores incorrect paths to lib64 libraries
| Quote: | | https://bugs.gentoo.org/644538 |
It';s not new, but I think I"ll hold off before trying to
make any further migration attempts.
Maybe it has been corrected, but I'll need to wait.
If I decide to try 17.1 I may have to do do a full re-install.
_________________
ASPushkin
"In a time of universal deceit - telling the truth is a revolutionary act." -- George Orwell |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8936
|
| Posted: Mon May 04, 2020 6:02 am Post subject: |
|
|
| A.S. Pushkin wrote: | I just stumbled on this old bug post:
dev-util/cmake: stores incorrect paths to lib64 libraries
| Quote: | | https://bugs.gentoo.org/644538 |
It';s not new, but I think I"ll hold off before trying to
make any further migration attempts. |
Not necessary at all for the one or two packages you might have to rebuild for that. cmake only did it wrong because of the pre-17.1 /usr/lib symlink in the first place. |
|
| Back to top |
|
|
figueroa
Advocate
Joined: 14 Aug 2005
Posts: 2963
Location: Edge of marsh USA
|
| Posted: Tue May 05, 2020 4:48 am Post subject: |
|
|
| A.S. Pushkin wrote: | | If I decide to try 17.1 I may have to do do a full re-install. |
I lost track of this thread till now. Sorry.
Yes, I think it might save a lot of headache to do a fresh install. Save /home/user(s), /var/lib/portage/world, /etc (for reference), and your kernel's .config (also maybe just for reference).
Backing up your home directory and other personal files, I would forget clonezilla, just "tar czpf /some/destination/path/userhome.tgz /home/user" and similar for /etc although, if you are a clonezilla expert and can carefully and selectively restore those things, maybe you have all the backups you need.
Then do a stage3 install. After you get your network and portage squared away, drop your backed up /var/lib/portage/world back into the new system, do an emerge -uDU world and come back when it's done. Do any necessary portage housekeeping, and reboot into your shiny new install.
Afterwards, restore your personal files, maybe being selective. Good chance to have cleaned house.
Wishing you clear sailing.
_________________
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 |
|
|
|
|
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
