Boot stuck at "activating encrypted devices"

[gc-user]

Not sure if it is important, but the system uses zfs on root (not not encrypted, only user home is).

Prior to the issue appearing I was:

• Extracting an archive to /usr.
• Later on, thunar crashed as it does from time to time. When restarting thunar, it came up with default settings, default locale, default icons etc. Trying to log out and re-log-in, I got an error message stating something about COLLATE, the login screen did not come up. Switching to a different tty to reboot. There were some error messages I can't recall.

From that moment on, trying to boot that BootEnvironment, the boot process always ends at "activating encrypted devices".

I can xchroot just fine into that BE from another BE.

I don't know what to make of it or how to fix it. It doesn't seem unfixable, though.

The only odd thing I noticed going through the files that were obvious to me, comparing them to the BE I'm currently using, was /etc/fstab having an additional, empty line at the start, while still having the same timestamp as the file in the working BE. I removed that additional line, but without effect on the boot hangup.

Is there anything I could / should check?

Here's screenshot of tty1 I took on the working BE. The red arrow marks the line where the defunkt BE hangs at boot:

[classabbyamp]

what were you extracting? you may have overwritten something, like an important symlink (like /bin or /sbin). from a live environment, try using xbps-pkgdb -a to find issues (especially in things like base-files) and xbps-install -f to repair them. you may need to grab static xbps

[classabbyamp]

can you provide a link or copy of the exact archive you were extracting? I doubt this is true:

nothing that should affect the base system

next time, extract elsewhere and copy the files you want to /usr (or even better: /usr/local or ~/.local)

[gc-user]

The archive link is https://archive.org/download/flashplayer_old/flashplayer32_0r0_371_linux.x86_64.tar.gz .

I extracted the archive to a directory in Downloads and then copied the usr folder contained in there to /
The other files and the second folder I did not copy over, except the .so file, according to these instructions.

[gc-user]

I think I found the issue.

Comparing (ls -lah) /usr of working and defunct BE, I instantly noticed that the symlink (is that the correct term?) from lib64 to lib is missing - just like your initial thought. I do more digging, but this might be the biggy...

[classabbyamp]

in that tarball:

drwxrwxr-x  0 soluser soluser        0 avr 24  2020 usr/lib64/

/usr/lib64 is a directory, not a symlink, so you overwrote the symlink that should exist and broke things. also, the only thing in /usr/lib64 in that archive is:

-rwxr-xr-x  0 soluser soluser   912096 avr 24  2020 usr/lib64/kde4/kcm_adobe_flash_player.so

which is useless on a modern system (it's a kde4 config module)

the symlink from lib64 to lib is missing

xbps-pkgdb -a should show that, as well as all other errors

copied the usr folder contained in there to /

yeah don't put things in /usr not managed by xbps (except /usr/local), this will prevent issues like this

[gc-user]

Yeah, that was the problem.

Thanks, Abby, for the help and the winning hunch!

I even have the xbps-pkgdb -a command in my bash history, but it must have been a long time since I used it, because it was like I never heard of it before.

I actually like easy errors with grave consequences but also with easy solutions. No harm done in the long run, but I'll never forget it or do it ever again...! :-)

I didn't think that easy because of the boot messages I didn't think the boot process had access to the file system as the "mounting zfs file systems" only comes later on.

Back on my main BE.

Thanks again!