You are not logged in.
I'm currently running Arch on 120GB SSD with /home, /var and swap on a 500GB HDD. I just bought a 240GB SSD with the intention of doing a fresh install of Arch on it (from my current system) and moving all my videos onto it as well, while keeping the HDD the same and putting the old SSD into my son's computer to give it a bit of a performance boost. The problem is, when I plug the new SSD into my computer, I get this:
:: running early hook [udev]
starting version 218
:: running hook [udev]
:: triggering uevents...
:: performing fsck on '/dev/sdb2'
:: mounting '/dev/sdb2' on real root
mount: unknown filesystem type 'swap'
You are now being dropped into an emergency shell
sh: can't access tty; job control turned off
/dev/sdb2 is my / partition, and my swap is /dev/sda2, so I was thinking it was screwing up the drives with the third one connected, but my /etc/fstab uses UUIDs, so that shouldn't happen. I'm booting directly into Arch from UEFI (no Grub) if that makes a difference. I've tried using a different SATA port, and same result. If the new drive is in, it won't work. If I take it out, everything is fine again.
Any clues?
Last edited by bertho (2015-03-05 02:51:18)
Offline
Try removing the swap entry from /etc/fstab -- systemd should mount swap partitions automatically.
Are you using gummiboot or have you written the NVRAM entries manually?
If you are using gummiboot, post the config files; also post the output of:
# efibootmgr -v
Offline
/dev/sdb2 is my / partition, and my swap is /dev/sda2, so I was thinking it was screwing up the drives with the third one connected, but my /etc/fstab uses UUIDs, so that shouldn't happen.
Any chance you have "root=/dev/sdb2" in your kernel commandline?
Offline
Commented out the swap entry and it made no difference.
Sorry, I meant to include the output of efibootmgr before.I wrote the entry manually.
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0002,000A,000B,0009,0000,0001
Boot0000* SATA: SSD2SC120G3LC709B121 BIOS(11,0,00)
Boot0001* SATA: HL-DT-ST BD-RE WH14 BIOS(10,0,00)
Boot0002* Arch Linux HD(1,800,100000,149aa1c7-ee8e-495a-932d-499cf6b158bd)File(\vmlinuz-linux)r.o.o.t.=./.d.e.v./.s.d.b.2. .r.w. .i.n.i.t.r.d.=./.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x...i.m.g.
Boot0009* UEFI: Built-in EFI Shell Vendor(5023b95c-db26-429b-a648-bd47664c8012,)AMBO
Boot000A* UEFI: IP4 Realtek PCIe GBE Family Controller ACPI(a0341d0,0)PCI(15,0)PCI(0,0)MAC(MAC(448a5b5da0c2,0)AMBO
Boot000B* UEFI: IP6 Realtek PCIe GBE Family Controller ACPI(a0341d0,0)PCI(15,0)PCI(0,0)MAC(MAC(448a5b5da0c2,0)030d3c000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000AMBO
Not sure what the deal is with all those periods, but I'm in the system right now, so obviously it's working right...
Offline
@Raynman is right -- you have "root=/dev/sdb2" in your NVRAM entry.
It would probably be simpler to use gummiboot and define the root partition using the PARTUUID in the Arch.conf configuration file:
# /boot/loader/entries/arch.conf
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options root=PARTUUID=blah rw
https://wiki.archlinux.org/index.php/Gummiboot
If you make the entries manually using efibootmgr I don't think it's possible to define the EFI system partition using a UUID.
https://wiki.archlinux.org/index.php/EF … bootmgr.29
Offline
Okay, that last link says I can use the UUID for root, at least. I'll try that after dinner and report back on whether I had to go with gummiboot or not. I don't think the EFI partition is a problem or I wouldn't have gotten to the point where it was trying to mount root, right? Thanks, guys!
Offline
Okay, so it didn't work using the PARTUUID , so I installed gummiboot, and that didn't work either (except for once - I'm not sure what happened but I realized after shutting down that the drive was already connected. Weird). I played around a little then it hit me - I was using the UUID from fstab, not the actual PARTUUID. Changed the entry in gummiboot and I'm good now. Would probably have worked straight through efibootmgr, but I had gummiboot installed already and I'm going to wipe that drive once I get my new one setup anyway... At least I have a head start on any EFI issues I run into this time around. ;-)
Thanks again.
Offline
One last note: Looking in GParted, the new drive assumed the /dev/sda position and bumped both of my other drives down a letter, so a quick and easy fix would've just been to change it to /dev/sdc2.
Offline