Something in --auto-update causes system to not boot

Support
,
21

Well you may use live version or another installed SO if you have a multiboot system.

22

In post,
https://forum3.openmandriva.org/t/glibc-update/1410/11
there is a workaround by Christopher_tanner

cd /etc
sudo mv nsswitch.conf nsswitch.conf.old
sudo mv nsswitch.conf.rpmnew nsswitch.conf

I’ll try asap.

But I’m still wondering why I have one computer that is working fine without this workaround.

1 Like
23

Doesn’t matter if you’ve attempted a boot or not. If you correct the ‘/etc/nsswitch.conf’ file your system will work again.

24

Now i am back again (by booting via rosa_os). Thanks to Christopher_tanner and his

sudo mv nsswitch.conf nsswitch.conf.old
sudo mv nsswitch.conf.rpmnew nsswitch.conf

25

It works for me too. Thanks.

One big question: packages are checked before issue?
I have 18 pc with OpenMandriva and if I update today I had almost a day with all pcs unusable!

1 Like
26

They are supposed to be. In this case it looks like some packages that should have gone to main testing instead went to main updates. Edit: Which makes testing before release impossible. Packages are supposed to first go to a testing repo for testing and are voted up (‘Accept’ in Kahinah) by testers. 3 ‘Accept’ votes are required to publish a package.

Just like we don’t have enough developers to do everything that needs doing we also don’t have nearly enough people testing packages. We could use some volunteers on this.

1 Like
27

The fix proposed by Chistopher_Tanner worked here too.

But I’m really afraid that something else is still wrong since one laptop here is apparently working fine without replacing /etc/nsswitch.conf file. To me, nsswitch.conf is just part of the problem, not the problem itself.
The usual for a new update is to create a .rpmnew, to be replaced or not by the administrator.

I just have no idea of what else makes the laptop to work fine with the old nsswitch.conf file and if the original problem is going to show up anytime, anywhere.

28

Does urpmi inform the admin that a new file (*.rpmnew) is available during an update?

I’m not going to pretend to know the answer to this one. But if you look at what nsswitch does and all that it affects it is easy to see how a system change made in the past to fix something or other could result in this. Things involving passwords, groups, or hostnames for instance.

29

Yes, usually. Particularly this time it happened.

Here it follows the output of,

$ diff nsswitch.conf_with_problems nsswitch_without_problems

30,32c30,32
< passwd:               files
< shadow:               files
< group:                files
---
> passwd:               files compat
> shadow:               files nis
> group:                files compat
34c34
< hosts:        files nis mdns4_minimal [NOTFOUND=return] dns wins
---
> hosts:        files nis dns wins myhostname
46c46
< automount:    files
---
> automount:    files nis
30

Either I didn’t say what I meant well or you didn’t understand what I mean.

When in the process or where in the output of ‘urpmi --auto-update’ does it ask me if I want to use the old file or the new file for a given updated package? I don’t recall ever seeing such a dialog in urpmi output. In this instance I don’t recall urpmi saying anything about glibc other than to “restart your computer for glibc”. I’m pretty sure there was no mention of any new file created. Or I’ve been missing that line for all these years…

As a package tester I’m wonder what key there might be to look for a .rpmnew file/files when running ‘urpmi --auto-update’.

EDIT: Apparently urpmi does tell user/admin this. I’ve just been missing it.

31

I meant updating certain packages like glibc usually are followed by a
warning about the creation of some .rpmnew file. It happened this time.
I guess I shouldn’t have sent the diff file since it let me unclear.

32

Yeah, that’s what I’m looking for because I missed it. Would like for someone to copy and paste the exact message if possible. But it is probably to late for that. As I said all I remember seeing is suggestion “restart your computer for glibc”.

33

I can understand but I suggest to delay an update until it reach at least 3 Accept in different hardware. Otherwise we can create a lot of problem to normal (and not so skilled) users. And, in turn, less user probably lead to less volunteers and developers …

34

Closing thread. Offending package has been removed.

Colin or I will inform everyone when a new glibc package stack is available. In the mean time apologies for the inconvenience.

1 Like