You are not logged in.
Hi!
I have an issue with my second HDD(sdb). Previously it was an Windows NTFS partition for Steam games. I decided to format it with ext4 and use as a backup device. But there is some issue. Every now and then I'm getting this:
lip 04 17:32:40 Iluvatar systemd[1]: systemd-fsck@dev-disk-by\x2duuid-990c5d4a\x2d7415\x2d4e34\x2db200\x2d451aab41469c.service: Bound to unit dev-disk-by\x2duuid-990c5d4a\x2d7415\x2d4e34\x2db200\x2d451aab41469c.device, but unit isn't active.
lip 04 17:32:40 Iluvatar systemd[1]: Dependency failed for File System Check on /dev/disk/by-uuid/990c5d4a-7415-4e34-b200-451aab41469c.
lip 04 17:32:40 Iluvatar systemd[1]: Dependency failed for /mnt/backup.
lip 04 17:32:40 Iluvatar systemd[1]: Dependency failed for Local File Systems.
lip 04 17:32:40 Iluvatar systemd[1]: local-fs.target: Job local-fs.target/start failed with result 'dependency'.
lip 04 17:32:40 Iluvatar systemd[1]: local-fs.target: Triggering OnFailure= dependencies.
lip 04 17:32:40 Iluvatar systemd[1]: mnt-backup.mount: Job mnt-backup.mount/start failed with result 'dependency'.
lip 04 17:32:40 Iluvatar systemd[1]: systemd-fsck@dev-disk-by\x2duuid-990c5d4a\x2d7415\x2d4e34\x2db200\x2d451aab41469c.service: Job systemd-fsck@dev-disk-by\x2duuid-990c5d4a\x2d7415\x2d4e34\x2db200\x2d451aab41469c.service/start failed with result 'dependency'.
I must press Ctrl+D to continue booting. And soon after that:
lip 04 17:32:42 Iluvatar systemd[1]: Mounted /mnt/backup.
lip 04 17:32:42 Iluvatar kernel: EXT4-fs (sdb1): mounted filesystem with journalled data mode. Opts: data=journal
Then partition is mounted and perfectly fine...
# Static information about the filesystems.
# See fstab(5) for details.
# <file system> <dir> <type> <options> <dump> <pass>
# /dev/sda5
UUID=5681746f-5f4e-4f89-b7f2-65183c1f0de3 / ext4 rw,relatime,data=journal 0 1
# /dev/sda7
UUID=e2979b11-33d8-452b-a452-aa47887367fb /home ext4 rw,relatime,data=journal 0 2
# /dev/sda6
UUID=83520e29-d809-4076-9dc8-3c2e1e7c58e0 none swap defaults,pri=-2 0 0
## BACKUP
# /dev/sdb1
UUID=990c5d4a-7415-4e34-b200-451aab41469c /mnt/backup ext4 rw,relatime,data=journal 0 2
##WINDOWS
# /dev/sda2
UUID=B20EA6060EA5C3A7 /mnt/windows-os ntfs-3g defaults 0 0
# /dev/sda3
UUID=58FCA24CFCA2246A /mnt/windows-gry ntfs-3g defaults 0 0
# /dev/sda1
UUID=847881C77881B906 /mnt/windows-rezerwa ntfs-3g defaults 0 0
lrwxrwxrwx 1 root root 10 07-04 17:32 990c5d4a-7415-4e34-b200-451aab41469c -> ../../sdb1
What is going on? Any idea?
Last edited by Pryka (2018-07-04 17:45:13)
Offline
Please post the full journal from that boot (from power on until "Reached target Multi-User System.")
Offline
Here - https://pastebin.com/3bz07QrB
EDIT: Changed first post to include ##WINDOWS section in my fstab.
EDIT: Ok... I'm lost now. I'm getting 2 different outputs, full random, can't find any pattern:
lip 04 20:09:31 Iluvatar systemd[1]: Requested transaction contradicts existing jobs: Resource deadlock avoided
lip 04 20:09:31 Iluvatar systemd[1]: systemd-fsck@dev-disk-by\x2duuid-990c5d4a\x2d7415\x2d4e34\x2db200\x2d451aab41469c.service: Main process exited, code=killed, status=15/TERM
lip 04 20:09:31 Iluvatar systemd[1]: systemd-fsck@dev-disk-by\x2duuid-990c5d4a\x2d7415\x2d4e34\x2db200\x2d451aab41469c.service: Failed with result 'signal'.
lip 04 20:09:31 Iluvatar systemd[1]: Stopped File System Check on /dev/disk/by-uuid/990c5d4a-7415-4e34-b200-451aab41469c.
Full log: - https://pastebin.com/2FYxuAqt
Last edited by Pryka (2018-07-04 18:37:58)
Offline
After doing a system update today, I do get exactly the same behavior.
Last edited by lev (2018-07-05 08:29:45)
Offline
What packages did you updated? Can you post pacman log from today?
I'm on testing and I was thinking that the culprit could be systemd 239.0-2. But it was last updated on 2018-06-22. And I didn't have this issue last week.
Offline
After doing a system update today, I do get exactly the same behavior.
I have to say me too, I've just found the culprit was lvm2, downgrading it solved the problem.
Last edited by fseek (2018-07-05 10:55:04)
Offline
As a workaround temporary solution if you don't need to mount the drive at the boot adding noauto to fstab can work.
x-systemd.automount is useful also. It will auto mount drive when you try to access it.
Last edited by Pryka (2018-07-05 11:02:21)
Offline
As a workaround temporary solution if you don't need to mount the drive at the boot adding noauto to fstab can work.
x-systemd.automount is useful also. It will auto mount drive when you try to access it.
that wouldn't work for me, as the issue blocks the booting process and I get an administration shell to fix things: systemd refuses to boot for a dependency failed on File System Check on the /home partition.
Offline
What packages did you updated? Can you post pacman log from today?
I'm on testing and I was thinking that the culprit could be systemd 239.0-2. But it was last updated on 2018-06-22. And I didn't have this issue last week.
I'm also on testing.
Here is the list with the upgraded packages:
[ALPM] transaction started
[ALPM] upgraded gdbm (1.14.1-1 -> 1.16-1)
[ALPM] upgraded perl (5.26.2-1 -> 5.26.2-2)
[ALPM] upgraded libsasl (2.1.26-12 -> 2.1.26-13)
[ALPM] upgraded apr-util (1.6.1-2 -> 1.6.1-3)
[ALPM] upgraded avahi (0.7+4+gd8d8c67-1 -> 0.7+16+g1cc2b8e-1)
[ALPM] upgraded device-mapper (2.02.177-5 -> 2.02.179-1)
[ALPM] installed aom (1.0.0-1)
[ALPM] upgraded harfbuzz (1.8.1-1 -> 1.8.2-1)
[ALPM] upgraded mesa (18.1.2-1 -> 18.1.3-1)
[ALPM] upgraded ffmpeg (1:4.0.1-1 -> 1:4.0.1-2)
[ALPM] upgraded guile (2.2.3-1 -> 2.2.4-1)
[ALPM] upgraded linux (4.17.3-1 -> 4.17.4-1)
[ALPM] upgraded linux-headers (4.17.3-1 -> 4.17.4-1)
[ALPM] upgraded linux-lts (4.14.52-1 -> 4.14.53-1)
[ALPM] upgraded lvm2 (2.02.177-5 -> 2.02.179-1)
[ALPM] upgraded man-db (2.8.3-1 -> 2.8.3-2)
[ALPM] upgraded python2 (2.7.15-1 -> 2.7.15-2)
[ALPM] upgraded ntop (5.0.1-11 -> 5.0.1-12)
[ALPM] upgraded python (3.6.5-3 -> 3.6.6-1)
[ALPM] transaction completed
How about disabling fsck in fstab?
Did you open new a bug report?
Offline
Nah I did not open a ticket. It's looks like its a upstream problem on LVM2. It should be reported on redhad bug tracker.
Dunno about fsck, you can try. For the time being I will stay with noauto + x-systemd.automount
PS. It looks that at least one of the issues is already reported - https://bugzilla.redhat.com/show_bug.cgi?id=1494014 https://github.com/systemd/systemd/issues/8596 (I'm getting this from time to time with my sdb drive)
I will try to post a ticked this weekend. Feel free to do it first as I don't have time to do it right now. Just post here if you are willing to do it, so we not duplicate issue on tracker.
Last edited by Pryka (2018-07-07 08:26:17)
Offline
Holy cow. I thought I had a network issue, when all along, it was lvm2. Downgrading has fixed my problem reported at https://bbs.archlinux.org/viewtopic.php?id=238539
Thank you.
Ryzen 5900X 12 core/24 thread - RTX 3090 FE 24 Gb, Asus Prime B450 Plus, 32Gb Corsair DDR4, Cooler Master N300 chassis, 5 HD (1 NvME PCI, 4SSD) + 1 x optical.
Linux user #545703
/ is the root of all problems.
Offline
Might consider opening a bug on the arch bug tracker to keep lvm2 2.02.179-1 in testing until the issue is resolved.
Could someone affected bisect between lvm2 2.02.177 and 2.02.179 and locate the commit that triggers the issue?
Offline
Opened bug on Arch buglist - https://bugs.archlinux.org/task/59266
Offline
It's probably not a bug, it's just that there's a new lvm.conf.pacnew located in /etc/lvm that needs to be updated from the old one. Give it a try.
Edit: Forget about that suggestion as I just tried it and still got the error on bootup.
Last edited by Pillgar (2018-07-11 00:39:23)
Offline
Just updated today as well (stable) and have the same issue.
Control-D allows the computer to continue to boot and the /boot partion is mounted like normal? Strange.
Offline
Had the exact same issue after updating, downgraded lvm2 and it fixed it.
Offline
Affected, downgrade fixed it.
This makes me questioning what is really going on for packages in testing repo, isn't it's existence is to help figuring out obvious bugs like this?
Offline
Affected, downgrade fixed it.
This makes me questioning what is really going on for packages in testing repo, isn't it's existence is to help figuring out obvious bugs like this?
It's not 100% bulletproof solution for every single bug. Actually there is no way to prevent this kind of situations to happen every now and then.
Last edited by Pryka (2018-07-11 09:36:43)
Offline
I'm affected by this as well; is there any solution without downgrading lvm2?
Offline
Not so far if someone could bisect between lvm2 2.02.177 and 2.02.179 and locate the commit that triggers the issue then one of the involved upstreams might look at the issue again.
Offline
Same issue here which started today after lvm2's update.
As mentioned earlier whenever you can, adding the noauto,x-systemd.automount options in the fstab file avoids the issue.
This usually speeds up the boot process and can be considered a permanent solution if it works for you.
This will fsck and mount the partition only when it is first accessed, and the kernel will buffer all file access to it until it is ready.
See wiki
Last edited by Kewl (2018-07-11 21:17:06)
Offline
Same here and only rebooted just now because my system, running awesomewm, locked up completely, could do nothing but reboot.
But my question to add here is: Since pressing CTRL-D and logging in as usual seems to (so far) work ok, >is it safe< to leave as is and wait for the fix, or am I risking something getting worse? Must I (also learn how to) downgrade lvm2?
Offline
I use testing, and so got caught early. Ctrl-D allows a normal boot, unless you have some odd mounts (NFS etc.) in which case, after boot, you may also need:
sudo mount -a
But after that, it worked a treat. For the moment, I've simply downgraded, but I guess it's up to you.
Ryzen 5900X 12 core/24 thread - RTX 3090 FE 24 Gb, Asus Prime B450 Plus, 32Gb Corsair DDR4, Cooler Master N300 chassis, 5 HD (1 NvME PCI, 4SSD) + 1 x optical.
Linux user #545703
/ is the root of all problems.
Offline
But my question to add here is: Since pressing CTRL-D and logging in as usual seems to (so far) work ok, >is it safe< to leave as is and wait for the fix, or am I risking something getting worse?
How can anyone answer that without knowing the root cause? There is not acceptance by upstream lvm or systemd that the bug is caused by that projects code so there is no work on a fix.
Edit:
systemd not system
Last edited by loqs (2018-07-11 21:20:58)
Offline
I'm affected by same issue.
Adding fsck.mode=skip kernel parameter works for me as temporary solution.
Offline