You are not logged in.

#1 2012-09-23 18:46:18

padster
Member
Registered: 2012-03-14
Posts: 24
Website

"Started Recreate Volatile Files and Directories" times out

I'm using the testing repo, not sure if this is related to [testing]] or not, but I wasn't sure where to post this to.

My boot takes forever now. I'm using systemd, and when I boot the step for "Started recreate volatile files and directories" takes forever then it times out and finishes booting. It all works fine after that, but it takes over a minute for it to time out and complete, and it's really annoying.

Here's the part from systemctl:

Sep 23 08:57:38 lupus-arch systemd[1]: Started Recreate Volatile Files and Directories.
Sep 23 08:59:04 lupus-arch systemd[1]: Job dev-disk-by\x2duuid-b8697018\x2df76f\x2d4548\x2daa08\x2d
Sep 23 08:59:04 lupus-arch systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-b8697018\x2
Sep 23 08:59:04 lupus-arch systemd[1]: Dependency failed for /dev/disk/by-uuid/b8697018-f76f-4548-a
Sep 23 08:59:04 lupus-arch systemd[1]: Job dev-disk-by\x2duuid-b8697018\x2df76f\x2d4548\x2daa08\x2d
Sep 23 08:59:04 lupus-arch systemd[1]: Job dev-disk-by\x2duuid-b8697018\x2df76f\x2d4548\x2daa08\x2d

Any ideas what I can do to fix it?

Also, I recently tested Bridge Linux (pre-set-up Arch), and my GRUB2 install picks it up wrong. It uses the wrong UUID for root for some reason. I made a new entry with the right UUID and that works, but why would it use the wrong UUID?

Offline

#2 2012-09-23 19:13:36

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,094
Website

Re: "Started Recreate Volatile Files and Directories" times out

Your title and analysis are completely wrong. The device timeouts are unrelated to systemd-tmpfiles.

I suspect your complaints about grub2 using the "wrong" UUID are related. Check your /etc/fstab against the actual UUIDs listed by blkid.

Offline

#3 2012-09-23 19:29:09

padster
Member
Registered: 2012-03-14
Posts: 24
Website

Re: "Started Recreate Volatile Files and Directories" times out

Ok, I fixed it. Looks like when I was doing some partitioning it changed the UUID of my swap partition, so I had to update that in /etc/fstab.

The Bridge Linux is completely different, though. I have a regular Arch install, which had this problem that I just fixed, and Bridge Linux is on another partition.

The GRUB entry for Bridge is:

menuentry "Arch GNU/Linux, with Linux core repo kernel' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-core repo kernel-true-ad4103fa-d940-47ca-8506-301d8071d467 (on /dev/sda11)" --class gnu-linux --class gnu --class os {
	insmod part_msdos
	insmod ext2
	set root='(hd0,msdos11)'
	search --no-floppy --fs-uuid --set=root 8edd58e2-607d-42eb-9d4c-2fb5da7877d9
	linux /boot/vmlinuz-linux root=UUID=ad4103fa-d940-47ca-8506-301d8071d467 ro quiet
	initrd /boot/initramfs-linux.img
}

The first UUID (8edd...) is right, I don't know where it got the second one (ad410...) from. None of my partitions have that UUID.
My working menu entry I made just replaces the 2nd UUID with the first. But I don't get why update-grub makes it like that.

Offline

Board footer

Powered by FluxBB