OpenMandriva Lx version:
Lx 3.0 installed from Lx 3.03beta ISO 1390 and fully updated. This is x86_64.
Desktop environment (KDE, LXQT…):
Plasma5 but that is irrelevant to this issue.
Description of the issue (screenshots if relevant):
Relevant informations (hardware involved, software version, logs or output…):
# urpmi --auto-update
To satisfy dependencies, the following packages are going to be installed:
Package Version Release Dist DEpoch Arch
(medium "main updates")
glibc 2.26 4 omv 2015.0 x86_64
glibc-devel 2.26 4 omv 2015.0 x86_64
lib64nss_myhostname2 234 2 omv 2015.0 x86_64
lib64systemd-devel 234 2 omv 2015.0 x86_64
lib64systemd0 234 2 omv 2015.0 x86_64
libc6 2.26 4 omv 2015.0 x86_64
systemd 234 2 omv 2015.0 x86_64
systemd-bash-completion 234 2 omv 2015.0 x86_64 (suggested)
systemd-zsh-completion 234 2 omv 2015.0 x86_64 (suggested)
and after system will not boot with many systems not starting including login manager and authorization manager.
I believe there is a way to get logs in this situation by adding something to boot parameters. If so can someone describe procedure so I can gather some logs?
I’m following this and will try to get some debugging information if I can.
EDIT: So far I don’t understand how to use this information.
You may try to adding rd.debug to boot line (and remove quiet to get more output at screen) so you can find a log file called something as /run/initramfs/rdsosreport.log with lots useful infos. This works on emergency shell but I don’t sure it applies in your situation.
How do you find a log file for a system that never boots?
Edit: At any rate I can’t figure out how to get logs for a system that does not boot. Need help with that. I do have this problem reproduced in VirtualBox.
Don’t know if this can be of any help. I’ve just updated the system with the mentioned packages and much more: kernel 4.13, etc.
I’ve restarted the system without any problem.
Forgot to say that I did not restarted the system just after new systemd installation. In fact, after installation of the mentioned packages there it appeared the message to restart the system and right after that it also appeared,
$ restarting urpmi
and a new huge list of updates showed up.
I restarted the system only after the installation of this second updates list.
Ben79, could it be the lack of some packages of the new update list that caused the booting problem?
Looks like the problem is not systemd but it is something in those updates perhaps glibc?
Was glibc in the list. Please post the complete list of updated packages.
ben79, I only updated glibc as I am cautious about such things and it broke my system.
Fortunately I was able to get it back.
You can do it in the following way.
Boot with live cd/stick go to https://abf-downloads/3.0/repository/x86_64/main/release.
and download these files.
You can leave out the devel and doc ones if your aren’t doing development.
Mount the root partition of your broken system on /mnt
mount -t ext4 /dev/sda2 /mnt (on my ssystem)
Cd to the directory that holds your downloaded rpms.
use the following command to install them.
rpm -i --oldpackage --root /mnt --nodeps --force *.rpm
This fixed it for me though I suspect that ny system is not perfect and will probably only be ok after another glibc update buit it soes at least work.
Thanks. Doesn’t glibc include locales? They seem to go together.
Anyway problem seems to be either glibc 2.26-4 or libc6 2.26-4.
Edit: I should say that if I update only those 2 packages it causes the system to not boot as in above screenshot.
I have two computers. The laptop does not show this problem. The desktop does. Both had glibc updates.
Upon recovery mode boot, the message (I translated),
"cannot access password database"
shows up. Thus, one cannot login as root for fixing anything.
I guess whatever could be done (viewing systemctl logs as suggested) will demand an installation disk in live mode …
As a complement,
The computer that is not showing this problem has,
Your’e quite right it does but I chose to ignore them though probably thou should add your chosen locale package.
Sorry for this inconvenience. Looks like in some cases after glibc update, password db is not updated or so.
Now we need a detailed description of simplest method to recovery system. Remember that this bug could have affected many user, including not so skilled ones.
I confirm glibc was in both lists, but I no longer have access to the
lists. I remember systemd was not in the updates list of the computer that
has problems. However, its version is 234 too, I’ve checked because it was
different from that of the other (working) computer.
Solution suggested in https://forum3.openmandriva.org/t/glibc-update/1410
After the update has taken place and before any reboots, this file must be copied over nsswitch.conf, viz
can be used “before reboot” only.
Unfortunately many users, including me, rebooted already.
We need a “simple” solution, probably using “live” version.