Seriously, Arch is the only one of my distros that cannot do this. Boot halts because the mount of my btrfs filesystem fails.
[ 7.620036] Adding 8105464k swap on /dev/sda3. Priority:-1 extents:1 across:8105464k [ 8.068963] device label TimBTRFS devid 1 transid 1140 /dev/sda4 [ 8.158492] device label TimBTRFS devid 1 transid 1140 /dev/sda4 [ 8.192647] scsi 4:0:0:0: Direct-Access Seagate FA GoFlex Desk 0155 PQ: 0 ANSI: 4 [ 8.193407] sd 4:0:0:0: [sdb] 3907029167 512-byte logical blocks: (2.00 TB/1.81 TiB) [ 8.193867] sd 4:0:0:0: [sdb] Write Protect is off [ 8.193868] sd 4:0:0:0: [sdb] Mode Sense: 1c 00 00 00 [ 8.194367] sd 4:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 8.209511] sdb: sdb1 sdb2 [ 8.215242] sd 4:0:0:0: [sdb] Attached SCSI disk [ 8.285827] EXT4-fs (sda8): mounted filesystem with ordered data mode. Opts: (null) [ 8.289498] scsi 5:0:0:0: Direct-Access Generic USB SD Reader 1.00 PQ: 0 ANSI: 0 [ 8.290745] scsi 5:0:0:1: Direct-Access Generic USB CF Reader 1.01 PQ: 0 ANSI: 0 [ 8.292500] scsi 5:0:0:2: Direct-Access Generic USB SM Reader 1.02 PQ: 0 ANSI: 0 [ 8.294869] scsi 5:0:0:3: Direct-Access Generic USB MS Reader 1.03 PQ: 0 ANSI: 0 [ 8.297550] systemd: Job ntpd.service/start failed with result 'dependency'. [ 8.297554] systemd: Job basic.target/start failed with result 'dependency'. [ 8.297565] systemd: Job systemd-tmpfiles-clean.timer/start failed with result 'dependency'. [ 8.297573] systemd: Job cups.socket/start failed with result 'dependency'. [ 8.298124] sd 5:0:0:0: [sdc] Attached SCSI removable disk [ 8.299235] systemd: Starting Emergency Shell... [ 8.300623] sd 5:0:0:1: [sdd] Attached SCSI removable disk [ 8.302870] sd 5:0:0:2: [sde] Attached SCSI removable disk [ 8.304370] sd 5:0:0:3: [sdf] Attached SCSI removable disk [ 8.312223] systemd: Started Emergency Shell. [ 8.312260] systemd: Starting Emergency Mode. [ 8.312266] systemd: Reached target Emergency Mode.
The only thing I do in the emergency shell is "mount -a -t btrfs". Then I exit the emergency shell and bootup completes, successfully. Why does the automated mount fail, then the manual mount using the same fstab entry succeeds?
Here is the fstab line for the filesystem:
UUID=317460bc-5b6a-4dac-acb8-7139dcbcff8b /btrfs btrfs compress=lzo,device=/dev/sda4,device=/dev/sdb1 0 0
Last edited by ratcheer (2012-10-03 00:53:30)
There has long been a problem with multi-device btrfs. This should be fixed with linux 3.6, which is currently in testing.
FWIW, the problem is that systemd did not use to know when all the necessary devices were ready. The kernel now keeps track of it and the udev rule /usr/lib/udev/rules.d/64-btrfs.rules informs systemd about the status.
@graysky, yes that hook is being called and it is always successful.
@tomegun, thank you. I understand. The same filesystem is mounted successfully during boot up by my other three distros: Ubuntu on 3.2, Sabayon on 3.5, and Siduction which was on 3.5 until this morning (but it's now on 3.6). I will just comment the filesystem out in my Arch fstab and mount it manually after the system is up. I will try it again after Arch gets 3.6.
I often hear a lot of "Well it works in other distros, wtf is wrong with Arch?" But I never see any of those particular users actually taking the time to figure out *why* it works in other distros. I would imagine, in some cases they have to make some serious changes to get certain things to work.
So if one of the core principles of Arch is simplicity by way of near vanilla packages, why would you expect these changes to have already been made for you. Isn't part of being an Arch user knowing enough to be able to implement what you need? Or at the very least knowing how to google well enough to implement what you need.
@ratcheer - You can try now if it's a major pain in the balls by enabling [testing] and using the updated linux package.
If you do enable testing make sure you aren't like myself: I'm not competent enough to enable testing..
To elaborate a bit. If you enable testing and then just do a "pacman -Syu" then you are going to pull in all sorts of packages you may not want and it may be complicated to get rid of later. To avoid this I would enable testing, do this:
sudo pacman -Syy sudo pacman -S testing/linux
So it would pull in the absolute minimum that I wanted from testing. Then I would disable the testing repository and pacman -Syy again. That would convert the new linux package and packages it requires to manual packages. E.g. they would be shown under "pacman -Qm"
Because once you start pulling packages in from testing it is almost a one-way street. As I instructed above, that is my gross understanding. I don't use testing at all, it is supposed to be used if you are actively testing Arch and providing feedback while doing so.
Last edited by headkase (2012-10-03 01:51:51)
We all make choices, but in the end, our choices make us.
Actually, I was booting Arch this morning knowing that I had to comment out the btrfs filesystem in fstab. But, boot up ran to completion and the filesystem was properly mounted. Maybe it's just a fluke; time will tell.
PS - I never said, "wtf's wrong with Arch?" and tomegun pointed out that I was simply struggling with a problem known to the Arch developers.
Last edited by ratcheer (2012-10-03 11:02:40)
@headkase - Not good advice... [testing] is an all or nothing proposition. However, pulling the linux package from it is probably the safest one-time pull you can do. Also, for that, you don't need to enable it at all, just use the -U switch and point directly to the target(s).
% sudo pacman -U http://mirror.rit.edu/archlinux/testing/os/x86_64/linux-3.6-1-x86_64.pkg.tar.xz http://mirror.rit.edu/archlinux/testing/os/x86_64/linux-headers-3.6-1-x86_64.pkg.tar.xz
Last edited by graysky (2012-10-03 11:50:36)