Defeat upgrade issues, such as "/lib", glibc, linux, systemd-tools...

SpawnHappyJake · 2012-07-20 23:31:06

I just wanted to share how I overcame some system-wide upgrade issues. There are so many threads about these issues, but none clearly state the whole matter out in the subject, at least not all of the things that I want to explain. Some are only about this or the other. So I thought I'd post something in the "FAQs, Tips & Tutorials".

1. The magic "r" option + move /lib:

What really eventually allowed me to do a full system-wide upgrade was to boot into another installation of ArchBang, and from there, move the target installation's /lib folder to /[target mount point]/libbtemp. Or just anywhere but /lib, and then use the magical "r" option. I did "sudo pacman -Su -r [mount point of target installation]", after running "sudo pacman -Syy". The "r" option allows you to have pacman install to a root other than "/". It achieves a similar goal as chroot, but isn't chroot. When I chrooted into the target installation, every program I tried to run said that it couldn't be found. That's misleading, because it _actually_ means that the _loader_ for the program could not be found, which it expects to be in /lib, but I moved it to /libtemp. I even tried specifying the path to the loader, and that didn't work. Thus the need to use the magic "r" option, rather than chroot.

2. Make the folder it says it needs.

When I wanted to upgrade just the kernel (sudo pacman -S linux), it complained that "/lib/modules/[whatever the version was]" did not exist. Simply making the folder allowed "sudo pacman -S linux" to continue. It did put the kernel in /boot. But it failed to populate /lib/modules/[new kernel version]. It didn't give me all the kernel modules for that kernel version. So when it came time to make a new initrd for the new kernel, the initrd wasn't any good because it found no modules to put in it. Eventually I was able to do a system-wide upgrade, which populated /lib/modules/[new kernel version] with all the modules I needed, and I could then re-run mkinitcpio and I got a good initrd for the new kernel.

3. Develop pacman common-sense
I'm still working on my pacman common-sense, but what pacman common-sense I have developed has helped me immensly. If something doesn't install, this includes explicitly installing one package as well as a problem package a part of an entire system-wide update, read why and respond accordingly.
If it says that one package conflicts with another, most likely you should uninstall the conflicting package so that you can install what you or the system-wide upgrade is trying to install. If you really need that package, try installing it again after installing what conflicted with it after removing the problem package, because you have a good chance that the newer version of the problem package will work just fine.
Do the chain game, but not too much. To install the newer kernel, I had to uninstall some virtualbox package, because that virtualbox package relied on the kernel version I had. But it wouldn't let me uninstall that virtualbox package, because another virtualbox package required the previously mentioned virtualbox package. After uninstalling the second virtualbox package, I could uninstall the first. But I then still couldn't install the kernel, because I had to make a folder it was complaining being missing. Then I could install the newer kernel. As you can see, you can run into chains of dependencies. Even branching trees. At some point, you just have to do a system-wide upgrade, because going through dozens to hundreds of packages isn't worth the time.
Basically, just make pacman happy.

The --ignore option
On my way to a system-wide upgrade, I had to do "sudo pacman -Syyu --ignore glibc,systemd-tools", because glibc and systemd-tools wouldn't let the system-wide upgrade go through. Lots of things needed the them. In the upgrade, udev replaces systemd-tools. And I'm not going to spend the time nessisary to uninstall everything that needs systemd-tools, as well as everything that needs those things and so on. Not to mention some of those things are probably system-critical. Even if I did get rid of them, that'd be bad because they need to be installed to be upgraded by the "-u" option (as far as I know), and I'm not going to re-install them all myself. And glibc had it's little coniption fit over /lib.
This resulted in not much of a system-wide upgrade because many packages either needed glibc to not be ignored in the update, or needed systemd-tools to not be ignored in the update. Those packages had to be skipped.

After doing "sudo pacman -Syyu --ignore glibc,systemd-tools", I was able to do just "sudo pacman -Syyu --ignore glibc". (Or perhaps I did the later via a chroot?) Then I shut it down, booted into another installation of ArchBang, moved /lib to /libtemp and used the magic "r" option to do a full system-wide upgrade without ignoring anything. That got the kernel modules populated, and I could then make a funtional initrd for the kernel.

Things I've read that might not be nesicary
Also, I read somewhere that there's some command you run to see what all programs own various stuff in the /lib folder, and that you have to uninstall all those programs to upgrade glibc.
I ran that command and got a _fat_ list of programs. _No_way_ would I take the time uninstall _all_ those programs and _all_ the programs that need those programs and so on. _Definitely_ easier to just move /lib to /libtemp and use the magic "r".

Also, I've read that you have to uninstall broadcom-wl for the system-wide upgrade to work. Maybe that's a requirement, maybe not. I uninstalled it, and just that alone wasn't enough to make the upgrade go through.

Jake

Mr Green · 2012-07-20 23:59:24

Arch being a rolling release changes daily.

We have no real control post install, can only try to give advice if we can.

SpawnHappyJake · 2012-07-21 00:16:15

Oh, and sometimes you might have to delete /var/run and/or /var/lock.

pablokal · 2012-08-17 15:43:00

Warning: I don't agree with this tutorial and for that matter with most of Jakes posts.
Sorry, Jake.
But you seem a champion in making simple things more and more complicated and making in the process your solutions more and more complicated.
My advice to users of this forums is refrain from using your advice or else consider it with the utmost critical look.

SpawnHappyJake · 2012-08-17 17:51:23

@ Pablokal (and others): I have read elsewhere that you're supposed to uninstall a bunch of packages to get past the glibc thing (all packages that have ownership in /lib).

I looked at that list of packages, and there were _a_lot_ of packages that had ownership in that folder, for me at least. It would be far too time consuming to uninstall all those packages and all the packages that depend on those packages and so on. And then have to reinstall all the system-critical ones.

This method allowed me to circumvent all that uninstallation and re-installation work. So I'd have to say this actually greatly simplifies an existing solution and makes it take _way_ less time, rather than make it more complicated. Sure, it introduces a few new elements (chrooting and the "-r" option), but overall, it's way quicker and easier. It lets the package manager do the work.

Jake

Mr Green · 2012-08-18 00:40:42

This does not simply anything, the simple fact is May iso release is out of date. Testing isos get over this problem as it is based on update glibc.

Truth is our isos go out of date within weeks of release, have proposed a live installer that would get over this issue installing latest and greatest from the start reducing the update & upgrade problems from the beginning.

If left to me abinstall would be removed as no one seems to want to help with getting it running [apart from the legend Oliver!]

This would solve many Arch related posts on forum

SpawnHappyJake · 2012-08-18 00:46:34

Well, while we're waiting for the next official iso, I thought it might be helpful for people who don't want to try a testing iso.

Mr Green · 2012-08-18 00:49:38

Ok I will remove testing isos in the meantime

SpawnHappyJake · 2012-08-18 00:54:45

I'm not saying they're a bad thing. Maybe the average person really _should_ just go to testing isos, and this is a good example of that.

SpawnHappyJake · 2012-08-18 01:02:10

I'm sorry if I caused any trouble. I simply posted what solved the problem for _me_ in hopes that it might help someone. If not that, at least be notes for myself. And I mean that for just about all of my howtos, tips, etc.

Mr Green · 2012-08-18 01:56:51

You have nothing to be sorry about, you seem to have far more Linux knowledge than I do

If more users in the community put some effort into ArchBang iso and installer these issues would go away, can only spare so much time.

Bumps in the road such as grub-bios happen and need to be dealt with.

If Arch goes over to systemd completely then iso will become very out of date.

SpawnHappyJake · 2012-08-18 02:03:14

Forgive me if I didn't read something, but does the ArchBang testing iso use systemd instead of udev? I can assume from your last post that Arch doesn't fully do so, but what about ArchBang?

handy · 2012-08-18 02:16:05

Systemd & udev have been merged upstream.

Udev IS now a part of a package called systemd-tools.

[edit:] Made line above present tense.

Last edited by handy (2012-08-18 03:57:06)

SpawnHappyJake · 2012-08-18 02:18:47

So that means that, by default, it doesn't use _only_ systemd, even in testing?

handy · 2012-08-18 04:07:42

My understanding is that ArchBang testing has not yet gone over to systemd. My interpretation of what Mr Green has said prompts me to say that I believe that it will do in the future.

Mr Green, will correct me if I'm wrong.

Mr Green · 2012-08-18 04:23:45

If and when Arch finally goes over to systemd then we will of course think about changing.

ArchBang testing isos are initscripts based, only issue we had is getting grub-bios working with abinstaller

handy is right, if more Arch/Bangers test out systemd then we could try to get it working on a live iso level [more work!]

SpawnHappyJake · 2012-08-18 09:53:52

Ah. Thanks for the info. I really like this distro. : )

pablokal · 2012-08-18 16:25:17

Ok I will remove testing isos in the meantime

Why delete the most easy way to install AB. Is it the heatwave or the pressure for creating the new iso, that is confusing you?
I have been able to install the May iso and update glib in a much easier way than Jake proposes; that is the reason of my post.
Keep you head cool, Mr Green; green is a cool colour.
Thing is: do we want to rush like sheep because Arch is pushing us some direction or do we keep the simplicity that we like and for which we liked and chose Arch in the first place as long as possible.
My advice has been over and over again; change as little as possible; work from what you know and understand and only change things when necessary and don't go in uncertain terrain if you feel not well equipped or have the feeling you can't master it.
And if you can't manage what you want to do, you can't; nothing to be ashamed of. You have tried.

The reason I would like to ban Jake because he is only creating confusion, by making things on a lot of places in these forums unnecessary complicated.

Arch Linux

Announcement

#1 2012-07-20 23:31:06

Defeat upgrade issues, such as "/lib", glibc, linux, systemd-tools...

#2 2012-07-20 23:59:24

Re: Defeat upgrade issues, such as "/lib", glibc, linux, systemd-tools...

#3 2012-07-21 00:16:15

Re: Defeat upgrade issues, such as "/lib", glibc, linux, systemd-tools...

#4 2012-08-17 15:43:00

Re: Defeat upgrade issues, such as "/lib", glibc, linux, systemd-tools...

#5 2012-08-17 17:51:23

Re: Defeat upgrade issues, such as "/lib", glibc, linux, systemd-tools...

#6 2012-08-18 00:40:42

Re: Defeat upgrade issues, such as "/lib", glibc, linux, systemd-tools...

#7 2012-08-18 00:46:34

Re: Defeat upgrade issues, such as "/lib", glibc, linux, systemd-tools...

#8 2012-08-18 00:49:38

Re: Defeat upgrade issues, such as "/lib", glibc, linux, systemd-tools...

#9 2012-08-18 00:54:45

Re: Defeat upgrade issues, such as "/lib", glibc, linux, systemd-tools...

#10 2012-08-18 01:02:10

Re: Defeat upgrade issues, such as "/lib", glibc, linux, systemd-tools...

#11 2012-08-18 01:56:51

Re: Defeat upgrade issues, such as "/lib", glibc, linux, systemd-tools...

#12 2012-08-18 02:03:14

Re: Defeat upgrade issues, such as "/lib", glibc, linux, systemd-tools...

#13 2012-08-18 02:16:05

Re: Defeat upgrade issues, such as "/lib", glibc, linux, systemd-tools...

#14 2012-08-18 02:18:47

Re: Defeat upgrade issues, such as "/lib", glibc, linux, systemd-tools...

#15 2012-08-18 04:07:42

Re: Defeat upgrade issues, such as "/lib", glibc, linux, systemd-tools...

#16 2012-08-18 04:23:45

Re: Defeat upgrade issues, such as "/lib", glibc, linux, systemd-tools...

#17 2012-08-18 09:53:52

Re: Defeat upgrade issues, such as "/lib", glibc, linux, systemd-tools...

#18 2012-08-18 16:25:17

Re: Defeat upgrade issues, such as "/lib", glibc, linux, systemd-tools...

Board footer