You are not logged in.
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\x2dAny 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
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
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