Bug#788050: systemd-fsck : Check disks at each reboot
Hi, On 29-11-15 01:28, Michael Biebl wrote: Can you boot with systemd.debug-shell on the kernel command line, and then switch to tty9 while the fsck is running and attach strace to the fsckd and fsck process? I want to try this, but for some reason, grub always boots, even if I keep SHIFT pressed... This used to work at some point, but now I can't edit the command line anymore :( Ah, I see, it's bug #768299... so many things stopping to work lately :( I changed timout to 1, so I should be able to test it next reboot again. Can you respond to my questions, please? -- Kind regards, Manuel ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#788050: systemd-fsck : Check disks at each reboot
On 29-11-15 01:28, Michael Biebl wrote: Am 29.11.2015 um 00:12 schrieb Manuel Bilderbeek: How can I help? Describe your setup in as much detail as possible. LVM, RAID, fstab etc. No RAID, no LVM. I've got a HDD and an SSD. I'm now booting from the SSD. $ cat /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # # / was on /dev/sdg1 during installation UUID=8efc387d-cdc0-496d-8f3c-03cc7f4ac8a5 / ext4 errors=remount-ro,noatime 0 1 # swap was on /dev/sdg5 during installation UUID=0a3f3e1b-1141-4033-b619-ec2f6d62b452 noneswapsw 0 0 /dev/sr0/media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/sr1/media/cdrom1 udf,iso9660 user,noauto 0 0 /dev/sda1 /media/olddisk1 ext4ro,noatime 0 2 /dev/sda6 /media/olddisk6 ext4rw,noatime 0 2 /media/olddisk6/manuel/Music /home/manuel/Music none defaults,bind,rw 0 0 /media/olddisk6/manuel/Pictures /home/manuel/Pictures none defaults,bind,rw 0 0 /media/olddisk6/manuel/photos /home/manuel/photos none defaults,bind,rw 0 0 /media/olddisk6/manuel/Documents /home/manuel/Documents none defaults,bind,rw 0 0 /media/olddisk6/manuel/Videos /home/manuel/Videos none defaults,bind,rw 0 0 /media/olddisk6/manuel/msx-soft /home/manuel/msx-soft none defaults,bind,rw 0 0 /media/olddisk6/manuel/docs /home/manuel/docs none defaults,bind,rw 0 0 As you can see I'm bind-mounting some dirs from my HDD (which is olddisk6) into my homedir. Can you reproduce the issue with arbitrary mounts? Um, not sure, how do I test that exactly? Can you reproduce the issue with a minimal setup? On a different system? I don't have another system to test with. I don't know how to go to a 'minimal setup'. Do you have any hints how we can reproduce it? I didn't do anything special for it, as I said, just dist-upgrading daily. But this was one of the first times the fsck was due for that disk after the reinstall on the SSD, I guess. Does the problem go away if you use "systemctl mask systemd-fsckd.service systemd-fsckd.socket" I'll report about that later. But first tell me: what does this do and how can I undo it if necessary? Does journalctl -u systemd-fsckd.service produce anything interesting? $ sudo journalctl -u systemd-fsckd.service -- Logs begin at zo 2015-11-29 11:11:00 CET, end at zo 2015-11-29 14:27:42 CET. -- nov 29 11:11:00 sonata systemd[1]: Started File System Check Daemon to report status. Can you boot with systemd.debug-shell on the kernel command line, and then switch to tty9 while the fsck is running and attach strace to the fsckd and fsck process? I'll try that next reboot. -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/ ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#788050: systemd-fsck : Check disks at each reboot
Hi again, On 15-11-15 10:06, Michael Biebl wrote: I saw some workaround and suggestions, but is there already a direction of a solution of this issue? I'm afraid not. Not being able to reproduce this issue (on my side) makes this harder. Can you reproduce the issue reliably? As I wrote before, I get this issue *each and every time* I boot my system at the moment. So, I'm having a 9.5 minute delay every time I start up my PC. (Which is daily.) This is getting quite annoying, but the plus side is: as I can 100% reliably reproduce the issue, I am very much wanting to help you to investigate it. But you need to tell me what I need to do to help you with this issue. Which output of which commands do you need? Which tests could we do? How can I help? If there's really nothing I can do (and you're sure about that!), I'd rather get rid of this long boot delay... I bought an SSD to be able to boot quickly and that joy is now totally destroyed! ;-) -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/ ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#804910: systemd: Invisible fsck, looked like a hanging system
Hi, On 14-11-15 14:09, Michael Biebl wrote: And alternative could be, to attach the output of systemd-analyze and "systemd-analyze blame" when such a long fsck happens. I thought I had already done that, but here it is again in full. $ systemd-analyze Startup finished in 3.802s (kernel) + 9min 50.031s (userspace) = 9min 53.833s and blame: 9min 32.488s systemd-fsck@dev-sda1.service 9min 31.695s systemd-fsck@dev-sda6.service 16.290s rc-local.service 1.528s apache2.service 1.065s nmbd.service 1.024s samba-ad-dc.service 649ms shorewall.service 544ms media-olddisk6.mount 331ms dev-sdg1.device 325ms ModemManager.service 271ms systemd-localed.service 252ms NetworkManager.service 201ms systemd-hostnamed.service 175ms smbd.service 171ms accounts-daemon.service 168ms home-manuel-photos.mount 149ms home-manuel-Documents.mount 116ms systemd-timesyncd.service 116ms home-manuel-Pictures.mount 109ms udisks2.service 107ms systemd-modules-load.service 98ms exim4.service 81ms iio-sensor-proxy.service 80ms console-setup.service 79ms keyboard-setup.service 68ms systemd-udevd.service 65ms polkitd.service 65ms rsyslog.service 64ms timidity.service 62ms alsa-restore.service 55ms minissdpd.service 53ms systemd-udev-trigger.service 47ms home-manuel-Music.mount 39ms networking.service 38ms wpa_supplicant.service 36ms home-manuel-Videos.mount 35ms systemd-journald.service 35ms packagekit.service 33ms irqbalance.service 31ms systemd-logind.service 30ms avahi-daemon.service 29ms systemd-tmpfiles-setup-dev.service 27ms media-olddisk1.mount 25ms user@1000.service 23ms kbd.service 21ms systemd-setup-dgram-qlen.service 21ms home-manuel-msx\x2dsoft.mount 20ms user@116.service 20ms speech-dispatcher.service 16ms pppd-dns.service 15ms systemd-user-sessions.service 15ms dev-hugepages.mount 15ms dev-mqueue.mount 14ms gdomap.service 13ms sys-kernel-debug.mount 12ms gdm.service 12ms upower.service 10ms systemd-tmpfiles-setup.service 10ms colord.service 9ms dev-disk-by\x2duuid-0a3f3e1b\x2d1141\x2d4033\x2db619\x2dec2f6d6 5ms rtkit-daemon.service 5ms systemd-random-seed.service 5ms systemd-journal-flush.service 5ms systemd-update-utmp.service 4ms home-manuel-docs.mount 4ms systemd-tmpfiles-clean.service 4ms kmod-static-nodes.service 4ms systemd-remount-fs.service 3ms systemd-sysctl.service 3ms systemd-update-utmp-runlevel.service See my first bug report where I already included the top of the blame output. My conclusion was that it was in systemd, so that's why I filed to bug against systemd. But I might be wrong :) Your opinion, please! :) -- Kind regards, Manuel ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#804910: systemd: Invisible fsck, looked like a hanging system
Hi, On 14-11-15 13:49, Michael Biebl wrote: Please keep in mind, that fsck for / and /usr is run in the initramfs nowadays and systemd is not yet involved. Can you boot and removing "quiet" from the kernel command line. This should give you more log messages from systemd. OK, I'll try that. If this is the cause, then please reassign the bug to the proper package. These kernel options were the defaults so the point is still valid: you don't have a clue what's going on as you get no feedback. This should not be the case in a default Debian install, IMHO. So, IMHO: either fsck progress info is NOT something that should be suppressed in 'quiet' mode, or mode should not be 'quiet'. -- Kind regards, Manuel ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
