You are not logged in.
Pages: 1
So I got home today to find that my KDE login screen would not let me log in. It said the authentication process failed or something and I needed to terminate the screen lock process manually. So I go over to another virtual terminal and try to log in. As soon as I enter my user name, a bunch of errors come up and I am unable to log in. "This can't be good" I think to myself, and reboot.
I am greeted by this error upon booting: http://img263.imageshack.us/i/img20110221182435.jpg/
It says it cannot find /sbin/init . I loaded up an ubuntu live cd and verified that /sbin/init is indeed present and all my other files still seem to be there. I tried booting into arch fallback on grub but that didn't work either.
Midway through the day I SSHed my desktop from my phone and started it doing an upgrade. I was able to log in then so I assume this problem had not occured yet, and it may be the cause of the problem.
I have no idea how to fix it. I'm currently posting this from my phone so urgent help would be much appreciated.
Offline
I opened up my pacman.log from the live cd and the last entry it has is 'starting full system upgrade', it doent actually list any packages that were upgraded as usual.
Offline
Just some things to try if you haven't already. Maybe run a fsck on the partition and see what that uncovers, then attempt to do a full system upgrade again after chrooting from the LiveCD.
Offline
fsck /dev/sda1 on the live cd returns clean. As for the chroot thing...I have no idea how to do that, I've never chrooted. Would that enable me to run pacman from my ubuntu live cd?
Offline
The kernel cannot find the volume with the UUID listed on the line above the panic line. That volume is where /sbin/init lives. The kernel gets panicky when it cannot find the first program it has to run during initialization. I think your volume is just fine, the kernel just cannot find it.
Verify the UUID. If you changed the partition in any way, it might have changed.
You might also try telling GRUB to tell the kernel to find the root partition by /dev/sd?? rather than by UUID. Do that by hitting 'e' during the GRUB autoboot count down, then edit the command line in accordance with the instructions on the GRUB screen.
edit: fixed typo
Last edited by ewaller (2011-02-22 01:43:02)
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
Alright I edited the root=/dev/whatever/uuid to be root=/dev/sda1 but it comes up with the same panic. It just lists /dev/sda1 before the panic message instead of the by-uuid path
Offline
So would a kernel reinstallation be warranted here or does the problem likely lie elsewhere?
Offline
As for the chroot thing...I have no idea how to do that, I've never chrooted.
using arch live cd:
mkdir /mnt
mount /dev/<device-or-partition-name> /mnt/
mount /dev/<device-or-partition-name> /mnt/boot/ (if you have any other partitions like /boot,/var,/usr mount them also)
cd /mnt
mount -t proc proc proc/
mount -t sysfs sys sys/
mount -o bind /dev dev/
cp -L /etc/resolv.conf etc/resolv.conf
chroot .
pacman -Syyu
you get the point...
to exit chroot use exit
Last edited by JokerBoy (2011-02-22 03:30:50)
Arch64/DWM || My Dropbox referral link
Offline
DWilliams wrote:As for the chroot thing...I have no idea how to do that, I've never chrooted.
using arch live cd:
mkdir /mnt mount /dev/<device-or-partition-name> /mnt/ mount /dev/<device-or-partition-name> /mnt/boot/ (if you have any other partitions like /boot,/var,/usr mount them also) cd /mnt mount -t proc proc proc/ mount -t sysfs sys sys/ mount -o bind /dev dev/ cp -L /etc/resolv.conf etc/resolv.conf chroot . pacman -Syyu
you get the point...
to exit chroot use exit
Hmm when I run "chroot ." it says it cannot find /bin/bash
Offline
Alright so I got a list of the packages I updated before this all happened:
Targets (29): glibc-2.13-4 alsa-lib-1.0.24.1-1 alsa-utils-1.0.24.2-1 binutils-multilib-2.21-4 curl-7.21.4-2 fftw-3.2.2-2 gegl-0.1.6-1
kernel26-2.6.37.1-1 kernel26-headers-2.6.37.1-1 lib32-glibc-2.13-3 libdrm-2.4.23-2 mesa-7.10.0.git20110215-1
lib32-mesa-7.10.0.git20110215-1 libldap-2.4.24-1 lsof-4.84-2 mpg123-1.13.2-1 mplayer-32792-2 protobuf-2.4.0a-1 mumble-1.2.3-3
nmap-5.51-1 openjdk6-6.b20_1.9.7-2 ppp-2.4.5-2 udev-166-2 vi-050325-4 vim-runtime-7.3.125-1 vim-7.3.125-1 vlc-1.1.7-3 wget-1.12-4
wine-1.3.14-1
I assume of all those things the kernel update is what most likely broke and caused this? The only reason I'm questioning that is because the Arch Fallback grub option doesn't work either and I was under the impression that it pointed to your previously installed kernel version (but I could be and probably am wrong).
My computer is still non-operational. I assume the chroot thing should let me access pacman and sort the mess out but as mentioned in my previous post, it's telling me it cannot find /bin/bash, even though /bin/bash is present both on the live CD and on my mounted disk that I'm trying to chroot.
Offline
Just a stab in the dark here, but is there a chance the volume is being mounted with the noexec flag?
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
I remember you should define shell somewhere when you chroot. Wiki says do this:
chroot . /bin/bash
Offline
I had the same issue with similar updates. I changed my grub boot from root=/dev/disk/by-uuid/X to root=/dev/sdX as well and had to add after that rootfstype=ext4 and it booted just fine. The question is why did I have to do that??
[EDIT]
Well I did a mkinitcpio -p kernel26 and rebooted and the problem went away for me. Everything is back to normal. I'm not sure what happened as my log said that the update was successful.
Last edited by fowler (2011-02-22 20:28:15)
Offline
I tried everything just posted. I see no "noexec" flag anywhere, manually specifying /bin/bash after chroot does the same thing, and adding rootfstype=ext4 to what I was trying before didn't seem to change anything.
Should I just re-install? I really can't be without my computer for any longer...
Offline
I'm having this exact same problem on my laptop! I don't use a UUID in GRUB, it is /dev/sda3, and adding "rootfstype=ext4" did not work.
I also tried using the Arch LiveCD just now but after hitting boot into Arch setup, screen is blank and it just hangs
Offline
I remember you should define shell somewhere when you chroot. Wiki says do this:
chroot . /bin/bash
it doesn't matter that much
I see no "noexec" flag anywhere
"anywhere" would be /etc/fstab
DWilliams - are you using [testing]? 'cause it seems to be some problems related to upgrading util-linux to 2.19
Last edited by JokerBoy (2011-02-23 06:28:40)
Arch64/DWM || My Dropbox referral link
Offline
should try to chroot with dir above. run '# mkinitcpio -p kernel26'
would be getting the /bin/bash error if using a 32bit live image with a 64bit system (or vice versa)
let me know if it helps
Offline
Nope, wasn't using the [testing] repo.
I just re-installed arch, still have no idea what went wrong and if it was an actual bug or something stupid I did.
Offline
Pages: 1