You are not logged in.

#1 2012-05-06 07:49:04

dtw
Forum Fellow
From: UK
Registered: 2004-08-03
Posts: 4,439
Website

[solved]Broke my system - udev can't find librt.so.1 (multilib issue?)

This one is entirely my fault.

I want to swap my main desktop from i686 to x86_64 using this guide: Migrating Between Architectures Without Reinstalling.

After performing several steps, I changed my mind and tried to revert.  Obviously that didn't work as Udev in the ram disk now can't find librt.so.1

Here is the relevant pacman.log: http://pastebin.com/1J2ig3dM

This is what I did:

  1. I followed method 2

    1. At the top of the article it mentions installing some fallback packages so I tried to

      pacman -S busybox lib32-glibc

      but realised lib32-glibc was not available so just installed busybox.  I realise I would have been instructed to do this later anyway.

    2. I ran

      pacman -Sw $(comm -23 <(pacman -Qq) <(pacman -Qmq))
    3. I removed hdup (probably irrelevant)

    4. I edit pacman to use x86_64 and ran

      pacman -Syy
    5. That was slow so I resorted my mirrors and ran it again (line 20-21 in pastebin)

    6. I then ran

      pacman -Sw $(comm <(pacman -Qq|sed '/^lib32-/ d'|sort) <(pacman -Qqm|sort) -23)

      to get all the x86_64 packages

    7. That was slow so I resorted my mirrors (again) and ran it again (line 23 in pastebin)

    8. Installed 64 bit kernel

    9. Tried to install lib32-glibc again but did not have [multilib] enabled in pacman.conf (line 57 - 61)

    10. Forced install of lib32-glibc (line 64)

  2. This is where I changed my mind - I realised my system needed a lot of updates before it was stable enough for the switch (I added the note on the wiki about that)

  3. I edited pacman to use i686 and ran

    pacman -Syy

    (line 65)

  4. Ran

    pacman -Syu

    to see extent of needed upgrades but cancelled it

  5. Reinstalled the the i686 kernel (71 - 103)

  6. Wasn't sure if it was supposed to be i686 or auto in pacman.conf so I edited pacman to use auto and ran

    pacman -Syy

    (line 104)

  7. Started and aborted full system upgrade before any installation

  8. Removed rhythmbox (line 108 - 137)

  9. Removed avidemux (line 138 - 145)

  10. Started and aborted full system upgrade before any installation (line 145)

  11. Started and full system upgrade (line 150 - 365)

  12. Rebooted

My first thought when I couldn't boot was I had left lib32-glibc installed.

My main concern is that swapping the Arch from i686 to auto at step 6 has installed a bunch of x86_64 packages into an i686 environment.  However, since I never booted into the x86_64 kernel, I dunno how that could happen.

Anything from line 367 is me trying to fix the system in various chroots.  However, I had lots of problems in the chroot and I think this has probably done more harm than good.

I tried to remove lib32-glibc and that seemed to work but reinstalling pacman -S glibc always gave errors.

To start off I was chrooting in from an x86_64 install and that worked fine - then I started getting the /bin/bash not found.  So I tried to chroot in from an i686 install USB and got the same thing.

It's a mess.

Last edited by dtw (2012-05-06 10:06:38)

Offline

#2 2012-05-06 08:34:57

dtw
Forum Fellow
From: UK
Registered: 2004-08-03
Posts: 4,439
Website

Re: [solved]Broke my system - udev can't find librt.so.1 (multilib issue?)

On the plus side - I do have all the glibc packages I could possibly need in my cache!

Offline

#3 2012-05-06 10:06:17

dtw
Forum Fellow
From: UK
Registered: 2004-08-03
Posts: 4,439
Website

Re: [solved]Broke my system - udev can't find librt.so.1 (multilib issue?)

I fixed it.

I couldn't chroot anymore because, during my 2am fumblings, I somehow managed to install an x86_64 version of glibc.  I fixed that in 32 bit Live Env.

Once I could chroot in I ran the glibc post_upgrade script and rebuilt the init ram disk.  That's fixed it.

It also seems that even though I used pacman -Syy to force downloads of the dbases each time I changed Architecture in pacman, the system was still pointing at the x86_64 pkgs.

Just a note for any foolhardy adventurers - it's much simpler to fix a system from with an Arch Live env of the same Arch as the one you're trying to fix.

.:edit:.
Just another quick tip.  Running the following really saved me some time:

find /var/lib/pacman/local -type f -name desc -exec grep x86_64 {} \;

That allayed my suspicions I had totally borked it!

Last edited by dtw (2012-05-06 10:08:24)

Offline

Board footer

Powered by FluxBB