Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#25672 - [systemd-arch-units] booting with systemd fails with ext3 filesystems when forcing fsck.

Attached to Project: Community Packages
Opened by Nicola Bignami (_thebishop_) - Friday, 19 August 2011, 09:56 GMT
Last edited by Tom Gundersen (tomegun) - Tuesday, 01 November 2011, 10:52 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Dave Reisner (falconindy)
Tom Gundersen (tomegun)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

When an ext3 root partition exceeds the max mounts without fsck and thus fsck is forced boot-time, systemd doesn't wait for fsck to complete and tries to proceed with the boot. Obviously the boot can't proceed and the units provide tons of error messages as the fs is actually mounted ro and is still performing the fsck.

I'm not sure if the problem is here or in the initscripts-systemd package, but I think it's rather a configuration problem than a problem of systemd itself.

Additional info:
* package version(s)

initscripts-systemd v25-1
systemd 33-2
systemd-arch-units 20110807-2

Steps to reproduce:

-force the fsck at the next boot
-reboot
This task depends upon

Closed by  Tom Gundersen (tomegun)
Tuesday, 01 November 2011, 10:52 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Seems to have been resolved.
Comment by Dave Reisner (falconindy) - Friday, 19 August 2011, 13:26 GMT
I need to know more about your setup, because I can't reproduce this, nor does the behavior make sense (fsck@root.service will block local-fs.target until completion with a hard 'Wants' directive).

Please post the output of 'tree /etc/systemd/system', /etc/fstab and /proc/cmdline. You can find me on IRC as well (falconindy).

edit: attached bootlog of proper behavior
   boot (1.4 KiB)
Comment by Nicola Bignami (_thebishop_) - Friday, 19 August 2011, 19:22 GMT
Here are the files you requested.

I confirm that on my installation I can reproduce the problem: there must be some kind of mess in my configuration or something...
   etc-systemd (1.4 KiB)
   fstab (0.5 KiB)
   cmdline (0 KiB)
Comment by Dave Reisner (falconindy) - Friday, 19 August 2011, 19:26 GMT
What happens if you disable the readahead units?

If you could disable arch-daemons.target and arch-persistent-settings.service as well, that'd be great. I don't really condone usage of these for any longer than it takes to migrate your setup to systemd after booting up. We have a huge collection of native units in systemd-arch-units.
Comment by Dave Reisner (falconindy) - Friday, 19 August 2011, 19:47 GMT
Oh, and you should be getting rid of /dev/pts and /dev/shm fstab entries. You don't need those for sysvinit on Arch or for systemd.
Comment by Nicola Bignami (_thebishop_) - Friday, 19 August 2011, 20:20 GMT
Ok, without arch-daemons.target, arch-persistent-settings.service and readahead it works properly (I've still got to work out some little issues with the migration, but that's another thing).

BTW, it's better to warn about this in the wiki.

For the fstab, it's the one generated by the arch installer a couple of years ago.
Thanks for the tips.
Comment by Dave Reisner (falconindy) - Friday, 19 August 2011, 20:43 GMT
Well I'm really not sure what I'm supposed to be warning about here, unless you can pinpoint exactly what's causing this to blow up. I've dropped a large red warning on the wiki page and provided a migration path away from initscripts-systemd, as I suspect that's the likely candidate. I still can't reproduce this on my ext3 VM, though.
Comment by Tom Gundersen (tomegun) - Friday, 19 August 2011, 21:27 GMT
My guess is that arch-daemons.target is the culprit. It is my baby, and I love it dearly, so I will do my best to fix it. Any additional info would be appreciated. In particular, I'd like to see your DAEMONS array in rc.conf (my guess is that there is a corner case here that we have not thought about).

I will re-factor the persistent settings (again) and hopefully Dave will be convinced to pull it. It can now be greatly simplified due to changes to modprobe and initscripts.
Comment by Nicola Bignami (_thebishop_) - Friday, 19 August 2011, 21:42 GMT
That's my actual rc.conf
   rc.conf (3.2 KiB)
Comment by Nicola Bignami (_thebishop_) - Saturday, 20 August 2011, 14:31 GMT
I've also unsuccessfully tried to reproduce it in VM, so it must be related to the configuration of my real system.

The readahead units are not the problem: the collect unit complains that it can't write the fs, but this don't compromise the boot process.
Comment by Tom Gundersen (tomegun) - Monday, 22 August 2011, 16:15 GMT
@_thebishop_: I'm not able to reproduce either. Could you verify that it only enabling arch-daemons.target is what causes the problem? Could you paste the output of "systemctl --type service" after booting with arch-daemons.target enabled?
Comment by Nicola Bignami (_thebishop_) - Tuesday, 01 November 2011, 10:47 GMT
Sorry for the late reply.

I had to revert my notebook to the Redmond stuff for work-related reasons. Now I've performed a fresh install of ArchLinux on a new machine and configured Systemd as init system. I've forced the fsck a couple of times but now it seems to work just fine.
Thanks for the support.

Loading...