Profile 17.1 unbootable after /lib32 removal [SOLVED]

[Chris1969]

I switched three of my quite old systems to profile 17.1, after several modifications (removal of some old programs etc which prevented the recompilation of all 32-bit programs) all 32-bit programs were recompiled and portage removed the /usr/lib32. However /lib32 was not removed.

I used the systems for several days and updated them several times, then decided to remove the /lib32 directory on one of my systems. It worked.

Then I did it on my second system, which now does now not reboot (the kernel boots, but the system does not come up). I booted from livecd and copied /lib32 back, but that did not help. I really have no understanding of this principal lib changes...

Before I mess it up even more, I wanted to check, what the best procedure would be to fix the system. Hope there is any?

Thanks for any replies and help!

[C5ace]

Had a similar problem with a "must work 24/7" laptop. My solution was to restore the last backup instead of spending days trying to fix a unecessay problem.
_________________
Observation after 30 years working with computers:
All software has known and unknown bugs and vulnerabilities. Especially software written in complex, unstable and object oriented languages such as python, perl, C++, C#, Rust and the likes.

[krinn]

The solve is finding the real cause, no 32 bits should be use to boot, so your problem is that a critical to boot program is having a problem, but unrelated certainly to its 32 bits part (if it have any). But with no error message, can't do better.
and the change is before: 32bits in /lib32, 64bits in /lib64
and now : 32bits in /lib 64 in /lib64
It mean a 32bits gentoo building a binary will then requiere some file in /lib, and it will work with 17.1 profile, while it would had fail previously. It's not a bad change, just a weak one as it will help mostly running closed source code program.

[Chris1969]

Before I removed /lib32, I compared it (not deeply) with /lib and both seemed to have the same contents. Now /lib is empty, does that mean that it was linked to /lib32?
Could I try to just copy the content of /lib32 to /lib?

[krinn]

i think you didn't catch what i said.

nobody's cares about the 32bits part of your programs, only your toolchain you might care of its 32bits part, if you want it to be able to run or build something in 32bits

once your system is usable, if you want rebuild everything that still depends on "old" lib32 : equery b /lib32 and you get the list to rebuild
and if you want find who is broken because it's not in /lib where it should: emerge -1 lib
but an usable system, is one that boot.

I have done myself the migration like that, rebuild toolchain as said, then remove all lib32 (yes broken all 32bits part, but toolchain wasn't anymore in any lib32), and revdep-rebuild, equery b /lib32 /usr/lib32... for the sole reason i want migrate faster and not taking care about any 32bits part broken after that (it would had take lot of time to rebuild all 32bits prior migrating)
So i can confirm you, no 32bits is need to boot

[Chris1969]

Hello krinn, no, I still don't catch it. Because the system did boot several times with the /lib32 present.

As soon as I removed the /lib32 it does not boot anymore.

[Chris1969]

Thanks for the discussion, it boots again, I copied the content of /lib32 to /lib and removed /lib32. Maybe it was the missing firmware directory or some other component I have no idea.
At least the system seems to be sane and bootable again.

[dmpogo]

[Chris1969]

grub2