You are not logged in.
My symptoms are similar to this article except that I am using plain ext3 file systems. No XFS, no LVM. Plain old ext3 in real partitions.
The hardware is a 1 yr old HP motherboard, dual-booting W7 and Arch. Separate /boot partition in sda1, with the Linux root in sda4. I followed the installation instructions for EFISTUB and Gummiboot.
That was a month ago. Everything was booting fine, and I even accomplished one pacman -Syu ok since then. but that did not upgrade 'linux'. But just this week I felt it was time for another Syu and this one included an upgrade to 'linux' itself. After that, it fails boot with that message "unable to find root device" and gives the UUID it was looking for. That UUID matches the one blkid shows. I am guessing that what gets laid down by the pacman -Syu is not getting synchronized between the /boot files and where the root actually is.
The EFISTUB instructions were a bit confusing and it was unclear to me what the part about mkinitcpio was about and whether it was needed for my configuration. (Section numbers in the Wiki would help follow the flow).
I restored from the partimage backup I took just before the upgrade so all is running again, but I need to keep up with the upgrades. Big lesson from experience, take image backups before running Syu.
Last edited by Daimusou (2013-12-02 13:03:44)
Offline
Was /boot mounted when you upgraded?
Also, you will be much better off updating daily, as opposed to monthly. Dealing with one or two small changes is much more manageable than a huge list of packages...
Offline
Pretty sure /boot was mounted. Its fstab entry looks like this:
/dev/sda1 /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-roI know about doing it more often. I finally got everything working like I wanted which took a month. And I have done other upgrades. But this is the first Syu that included a kernel upgrade and clearly something is not getting set right so pacman can find all the pieces.
What I could try is do it again (since I have the good backup), then when it fails to boot use the Installation CD poke around in /boot and see if anything looks wrong. Check modification dates, etc. That may provide a clue as to what step I am missing.
What is odd is that the UUID was correct. This was all so much simpler when you could just tell the booter that "The root is on /dev/sda4". Or maybe there still is a way to do that.
Last edited by Daimusou (2013-11-28 18:11:51)
Offline
Using UUIDs is much more reliable than /dev/sdx.
If your EFI is at /boot/EFI make sure the new files were successfully copied across (assuming you had automated that process).
Offline
Ah HA! "(assuming you had automated that process)". No, I did not automate that. Is that what mkinitcpio is all about?
I am always a little unclear about the difference between /boot and /boot/EFI. I have both directories.
Here is my gummiboot entry for Arch, if that helps.
title Arch Linux
linux /vmlinuz-arch.efi
initrd /initramfs-linux.img
options root=UUID=ccd8fb4f-9c80-4cf1-b41d-93933277351f rootfstype=ext3 add_efi_memmapAnd the /boot/EFI directory contains these subdirectories:
arch BOOT gummiboot Microsoft.
The vmlinuz-arch.efi file is in both places, just in case, but I bet pacman only updates one and not the other.
Offline
Yes, read the wiki page on gummiboot for the details. Or just move your EFI to /boot as gummiboot supports that now (and it obviates the need for a service file or other workaround).
Offline
I never could find what establishes where the "EFI" is located. How do I "move" it?
Offline
The EFI is where you initially set it up.
You really should spend some time reading up on this: start here https://wiki.archlinux.org/index.php/EF … _Partition
Offline
title Arch Linux linux /vmlinuz-arch.efi initrd /initramfs-linux.img options root=UUID=ccd8fb4f-9c80-4cf1-b41d-93933277351f rootfstype=ext3 add_efi_memmap
What is 'vmlinuz-arch.efi'? The file that Arch installs is 'vmlinuz-linux' and that is what you should use.
Offline
That was a another clue as to what I was doing wrong. The ".efi" came from the "Setting up EFISTUB" part of the EFISTUB wiki page, which had a step of copying files down into the EFI/arch/ directory and giving them different names. I have changed the gummiboot entry to point to the files up at the top /boot directory exactly as pacman puts them there, and now it all works. I also changed the boot options to identify the root by PARTUUID instead of UUID.
Offline
The ".efi" came from the "Setting up EFISTUB" part of the EFISTUB wiki page, which had a step of copying files down into the EFI/arch/ directory and giving them different names.
Whoever wrote that is an idiot. Any setup that needs manual intervention after each upgrade is a bad setup.
Offline
Or just move your EFI to /boot as gummiboot supports that now (and it obviates the need for a service file or other workaround).
Offline