After some chat, I'm posting an answer summing up a few interesting leads to follow while facing such problems.
Booting safely on a USB image
As you can see here, it seems like your system went into some trouble when trying to boot from the USB drive:
ERROR: '/dev/disk/by-label/ARCH_201409' device did not show up after 30 seconds...
Falling back to interactive prompt
You can try to fix the problem manually, log out when you are finished
While your BIOS successfully detects a bootable medium and initiates a boot sequence, Arch does not boot correctly due to some kind of disk error. As you said in chat, your formatted and sent your images on your key quite a few times, which could lead to broken images or partition tables. When sending a bootable ISO image onto a USB drive, it's usually a good idea to make sure the drive is really clean before proceeding:
$ fdisk /dev/sdX # sdX being your USB drive (NOT partition!)
Command (m for help): d
Use d repeatedly until there is no partition left. Then, recreate a clean partition taking up the whole device:
$ fdisk /dev/sdbX
Command (m for help): n
Partition type:
p primary (1 primary, 0 extended, 3 free)
e extended
Select (default p): p
Partition number (1-4, default 1): 1
# ...
Then will follow some size-related options, just choose the default every time. When you're done, write the changes to disk using w. Now that the partition table is a little cleaner, you may format...
$ mkfs.ext4 /dev/sdX1
... and send your Arch ISO onto the drive:
$ dd if=/path/to/arch.iso of=/dev/sdX # Again, the device, NOT the partition.
Note: it is very important that both the Arch ISO and the hard system share the same architecture!
At this point, you may reboot your machine and get to the live system without too much trouble. Just make sure your USB drive comes first in your BIOS boot sequence.
Chrooting into the old/broken system
Now this is a little trickier, I'll mostly reuse the contents of the Arch Wiki. You have two options here:
- Use the Arch scripts (recommended).
- Chroot everything yourself, manually.
In the first case, all you have to do is mount your "homemade" partitions: those your created when you installed the system:
$ mount -o exec /mnt /dev/sda1 # / partition.
$ mount /mnt/boot /dev/sda2 # /boot partition.
$ mount /mnt/home /dev/sda3 # /home partition.
$ # ... and so on.
Once you're done, just use arch-chroot to get inside:
$ arch-chroot /mnt /bin/bash
Now, if you want to chroot everything yourself, you're going to have a little more work to do. First, mount the previous systems, then add:
$ mount -t proc proc /mnt/proc/ # procfs
$ mount --rbind /sys /mnt/sys/ # sysfs
$ mount --rbind /dev /mnt/dev/ # /dev
$ mount --rbind /run /mnt/run/ # /run
You might also want a working DNS resolver (yet it's unlikely to have been damaged):
$ cp /etc/resolv.conf /mnt/etc/resolv.conf
Finally, get inside:
$ chroot /mnt /bin/bash
Investigating
Basically, your system just went out of power. As you said, there was no significant task running (at least, no upgrade), so the loss must have been limited. First things first, check your logs. Have a look in /var/log and use journalctl to find information about what happened before the shutdown.
Reinstalling GRUB
In chat, you said that your system was no longer available in the boot menu, probably something related to the latest update you made. Let's reinstall it:
$ pacman -S grub # Should not do anything though.
$ grub-install --recheck /dev/sdX # Your hard drive.
$ grub-mkconfig -o /boot/grub/grub.cfg
Have same issue.
@fra-san: Thank you for the hint, how to get easily more information from logs, so here's what I got from that:
Apr 23 22:30:19 myhost systemd[1]: systemd-hostnamed.service: Failed to create cgroup /system.slice/systemd-hostnamed.service: No such file or directory
Apr 23 22:30:19 myhost systemd[1]: Starting Hostname Service...
Apr 23 22:30:19 myhost systemd[1]: systemd-hostnamed.service: Main process exited, code=exited, status=219/CGROUP
Apr 23 22:30:19 myhost systemd[1]: systemd-hostnamed.service: Failed with result 'exit-code'.
Apr 23 22:30:19 myhost systemd[1]: Failed to start Hostname Service.
On my system, after some warm reboots it was starting up again, so looks like timing or race condition issue.
This same issue has been posted on the Arch Linux Forums. It turned out to be a bug in dhcpcd 9.0.1 (for details: the report on Arch's bug tracker and the one on dhcpcd's mailing list).
A working temporary solution is to downgrade dhcpcd to a pre-9.0.1 version. The bug was fixed in version 9.0.2.
Best Answer
This is how I fixed this problem :
I've booted into an arch installation CD and mounted my root partition under /mnt/arch.
I then ran the following commands:
I then issued the chroot command and configured my network:
I'm not sure if all of these commands are required, but I didn't feel like continuously rebooting/chrooting, so I did them all at once and it fixed the issue we both were having:
Remove the CD or USB drive and ta-da! Now, I'll be honest and admit that I don't fully understand this fix. Some of the posts also suggested doing a “pacman -S linux”, however that was not necessary for me.