Dominique Leuenberger / DimStar wrote:
[...] At this point, I opted to 'retry' (unsurprisingly leading to the same error_, followed by abort. None of the commands were usable (ls, bash) and all responded with relocation error: /lib64/libc.so.6: symbol _dl_fatal_printf, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference
A strange case indeed. Probably needs someone with deeper glibc knowledge to explain. From the log it looks like all usrmerge steps were executed successfully. So bin, sbin, lib and lib64 were merged into /usr. The last thing that happened before the mv was to replace /lib64 with a symlink to the merged /usr/lib64. It looks like /lib64/ld-linux-x86-64.so.2 is there. Otherwise starting mv would fail with file not found. AFAICT _dl_fatal_printf is an internal symbol that only ld uses. So ld probably wants to say something there. ld is statically linked though. In my experiments it does not seem to need glibc to print errors. Like so: # tree . ├── bin -> usr/bin ├── lib64 -> usr/lib64 └── usr ├── bin │ └── true └── lib64 ├── ld-2.33.so └── ld-linux-x86-64.so.2 -> ld-2.33.so 5 directories, 3 files # chroot $PWD /lib64/ld-2.33.so /bin/true /bin/true: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory Anyway if ld was merged successfully to /usr/lib64 why shouldn't libc work too? Maybe some corruption? Dominique filed https://bugzilla.opensuse.org/show_bug.cgi?id=1186730 Ideas how to explain that welcome. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)