The system is an Asus X202E. It does UEFI and has a GPT partition system. I've gotten through that part. And it is clear to me that the kernel loads.
It's the next step that's giving me grief. I've tried this with two bootloaders: gummiboot and rEFInd.
With gummiboot, the kernel panics because it can't mount the root file system. With rEFInd, it gets to the intial ramdisk and then drops me to a shell, apparently because the root file system is set to null, and it obviously can't mount that as "real root".
Here is what I posted on the Arch mailing list, documenting that I have indeed specified the correct root (I'm copying this from the email, eliding the unfortunate line wraps):
bridge-live# cat /boot/loader/entries/arch.conf Title Arch Linux linux /vmlinuz-linux initrc /initramfs-linux.img options root=PARTUUID=d5bb2ad1-9e7d-4c75-b9b6-04865dd77782 bridge-live# ls -l /dev/disk/by-partuuid total 0 lrwxrwxrwx 1 root root 10 Apr 15 19:26 0ab4d458-cd09-4bfb-a447-5f5fa66332e2 -> ../../sda6 lrwxrwxrwx 1 root root 10 Apr 15 19:26 3e12caeb-1424-451c-898e-a4ff05eab48d -> ../../sda7 lrwxrwxrwx 1 root root 10 Apr 15 19:26 432a977b-f26d-4e75-b9ee-bf610ee6f4a4 -> ../../sda3 lrwxrwxrwx 1 root root 10 Apr 15 19:26 95a1d2c2-393a-4150-bbd2-d8e7179e7f8a -> ../../sda2 lrwxrwxrwx 1 root root 10 Apr 15 19:26 a4b797d9-0868-4bd1-a92d-f244639039f5 -> ../../sda4 lrwxrwxrwx 1 root root 10 Apr 15 19:26 d5bb2ad1-9e7d-4c75-b9b6-04865dd77782 -> ../../sda8 lrwxrwxrwx 1 root root 10 Apr 15 19:26 ed04135b-bd79-4c7c-b3b5-b0f9c2fe6826 -> ../../sda1 lrwxrwxrwx 1 root root 10 Apr 15 19:26 f64f82a7-8f2b-4748-88b1-7b0c61e71c70 -> ../../sda5
The root partition is supposed to be /dev/sda8, that is:
lrwxrwxrwx 1 root root 10 Apr 15 19:26 d5bb2ad1-9e7d-4c75-b9b6-04865dd77782 -> ../../sda8
So the correct PARTUUID followed by the one I have specified in
I'm guessing that this is really the same problem with both gummiboot and with rEFInd, but don't really know. It's clear to me that the initrd is not being correctly constructed. So I removed /etc/mkinitcpio.conf and did, as per the Arch wiki,
pacman -Syyu mkinitcpio linux udev
I don't even know which way to go at this point. If I even knew how to tell it where the real disk is in the initial ram disk shell, that would help. Better of course, would be actually solving the problem.
Last edited by n4rky (2013-04-17 21:41:36)
n4rky, welcome to the forums.
please use [code ] tags when pasting snippets. It uses a monospace font which makes it easier to read the post and distinguish the code from your post content. Please edit your post and make the necessary changes.
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
I have made extremely limited progress on this issue.
My previous attempt to specify the root partition in mkinitcpio.conf was insufficient. Furthermore, this is no place--despite the documentation--for the orthodoxy about using UUIDs rather than the straight /dev/sdx. In my case:
mkinitcpio -p linux
It still drops me into the shell at boot. I can do
mount /dev/sda8 /new_root/
and exit the shell. It still won't believe it has the root device and drops me back in. I just exit.
At this point, for a very brief moment, things look promising. It appears to be starting normally. Then, gdm.service, NetworkManager.service, and dbus.service all fail to start. There may be others but the screen goes by too quickly. At this point, it hangs trying to initialize the pacman keyring and all I can do is CTRL-ALT-DEL.
It occurred to me that this might extend to the rEFInd configuration and so I modified it to also use /dev/sda8 rather than the UUID, but this made no difference. Trying to boot via gummiboot still yields the previously specified kernel panic.
Should that not be initrd ??
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Like you, I have no idea what you are doing, but I am pretty sure it is wrong...Jasonwryan
How to Ask Questions the Smart Way
gummiboot now works correctly (rEFInd is still screwed up). Now, if I could sort out the other problems with gdm.service, dbus.service, and NetworkManager.service, and with pacman keyring initialization hanging, this would be a win. I will start a new thread for this.
This is about Bridge, right - not Arch?
Last edited by senorsmile (2013-06-08 18:17:55)