Are these the updates? They don't install

Tags: #<Tag:0x00007fb45c57ed70> #<Tag:0x00007fb45c57eca8>

I just ran updates on my LX 4.1 installation. I was informed there were 1477 updates packages. I’m guessing this is an attempt at moving to 4.2?

So I got all the files downloads. And then it attempted, and failed, to install every one of them. Here is a selection of my Terminal text:

file /usr/share/locale/zh_TW/LC_MESSAGES/kcm_cursortheme.mo from install of plasma-workspace-5.20.5-1.x86_64 conflicts with file from package plasma-desktop-5.17.5-2.x86_64
file /usr/share/locale/zh_TW/LC_MESSAGES/kcm_desktoptheme.mo from install of plasma-workspace-5.20.5-1.x86_64 conflicts with file from package plasma-desktop-5.17.5-2.x86_64
file /usr/share/locale/zh_TW/LC_MESSAGES/kcm_fonts.mo from install of plasma-workspace-5.20.5-1.x86_64 conflicts with file from package plasma-desktop-5.17.5-2.x86_64
file /usr/share/locale/zh_TW/LC_MESSAGES/kcm_lookandfeel.mo from install of plasma-workspace-5.20.5-1.x86_64 conflicts with file from package plasma-desktop-5.17.5-2.x86_64
file /usr/share/locale/zh_TW/LC_MESSAGES/kfontinst.mo from install of plasma-workspace-5.20.5-1.x86_64 conflicts with file from package plasma-desktop-5.17.5-2.x86_64
file /usr/share/locale/zh_TW/LC_MESSAGES/krdb.mo from install of plasma-workspace-5.20.5-1.x86_64 conflicts with file from package plasma-desktop-5.17.5-2.x86_64
file /usr/share/polkit-1/actions/org.kde.fontinst.policy from install of plasma-workspace-5.20.5-1.x86_64 conflicts with file from package plasma-desktop-5.17.5-2.x86_64

[zaivala@zaivala-FuzZ400 ~]$

The machine in use is an HP Z400 Workstation, with an old quad-core Xeon processor, and AMD video cars (also fairly old), 16 Gb RAM and a 512 Gib SSD.

When something looks unusual better option is to stop and ask here at the forum or even better to look for any useful communication.

I literally ran
sudo dnf remove plasma-desktop-5.17 (full name of package)
then re-ran the upgrade. Everything worked. I was scared for a moment…

However, now when I reboot, I get the nice new 4.2 screen… and a dialog box which tells me that a configuration file …greeterrc is not writable and to contact my system administrator. Then it continues to boot, takes me to a login screen where my login name is displayed and a box is provided for my password…

and it rejects my password. No, I didn’t change it. It is poor security, but I use the same password on all my distros. Poor security, but no way I got it wrong after several attempts.

OK, I see now I did everything wrong, and had to switch Rock repos. I’m doing that now on my laptop installation. So far it’s working. Wow that’s a lot of files.

Pay attention to the questions the script will ask you towards the end of the upgrade process.

about questions and scripts file at the end process
is there a good option to follow ,
or we need always check and merge ?

this is not easy , on Arch/Manjaro we have .pacnew for that , there is always documentation about the change ( wiki arch or in announce , First reply )

I got a whole series of scripts that made no sense other than to say “Y” to. Each of them looked the same except for the name of the package I was being prompted to do something about. This is NOT USER FRIENDLY, which means you just broke the first Rule of Mandrake.

I now have TWO installations of OM4.2 which give me the same error dialog box at bootup and will not allow me to log in. Incidentally, I noticed it in the Z400 upgrade and found it again in the Kudu upgrade, that when I went to reboot, clicking the reboot icon did absolutely nothing, did not bring up the confirmation box, nothing. I had to do a hard shutdown on both machines. I do not know whether it works now in 4.2, because I can’t get logged in.

This is not the best documented process I’ve seen. Serious understatement. Now, how do I fix it?

I am going to attempt a clean installation on the Z400. I hope I have better success. [ominous voice]You will hear from me.[/ominous voice]

For each question there is a “default is …” (or so, going by memory atm) usually ‘Y’ or ‘N’
Anyway if one just hits enter, the script assumes you are ok with default.

Thanks for posting this excellent question.

Yes there is some guidance here for that. Also guidance for the entire process of upgrading from Lx 4.1 to Lx 4.2.

If you accept the default for everything you will end up with the old mirror.list instead of Mirrorbits which is a notable improvement. That is why I suggest to accept the new files for all the .repo files. If you accept the default for grub you may miss changes in how grub boots newer kernels so also it is recommenced to accept the new file for grub. Otherwise for the rest the default is good.

Note: Accepting the default for everything works as far as I know. I am just suggesting there is a better path.

Note-2: I accept that I should have explained this in more detail in the other post.

1 Like

Thank you @ben79 for more informations and better explanation.

I edited this post with the explanation i put forth here. Thanks again for the suggestion.

@zaivala Thanks for bringing this topic to our attention. System upgrades like this are not the easiest thing in the world for users. They also can be difficult to explain to users. Thanks to you and @stephane I believe the explanation has gotten a bit better.

Thanks for doing your best, Ben. But I answered Y to everything, and got an unusable system. I have, however, done a clean install on one of my machines (Z400, as mentioned above), and it looks great (although I miss the flower)! I will likely just do a clean install on the laptop, as soon as I get an answer to another topic I posted.

Some new flower will be back very soon.

1 Like