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?
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.
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?
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.
glibc-2.23-4-omv2015.0.x86_64.rpm
glibc-devel-2.23-4-omv2015.0.x86_64.rpm
glibc-doc-2.23-4-omv2015.0.noarch.rpm
glibc-i18ndata-2.23-4-omv2015.0.x86_64.rpm
glibc-static-devel-2.23-4-omv2015.0.x86_64.rpm
glibc-utils-2.23-4-omv2015.0.x86_64.rpm
You can leave out the devel and doc ones if your aren’t doing development.
Become root
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.
Best,
Colin
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 …
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.