[systemd-devel] no fsck at boot

[Alexander E. Patrakov]

10.06.2014 00:57, Reindl Harald wrote:
>
> Am 09.06.2014 20:45, schrieb Alexander E. Patrakov:
>> 10.06.2014 00:04, Reindl Harald wrote:
>>>
>>> Am 09.06.2014 17:05, schrieb Colin Guthrie:
>>>> 'Twas brillig, and Reindl Harald at 08/06/14 13:59 did gyre and gimble:
>>>>> "touch /forcefsck" leads in deprecated warnings but in fact at least
>>>>> on Fedora 19 *you need it* because the fsck don't happen otherwise
>>>>>
>>>>> for sure, the last reboot of the machine below complaind too
>>>>> so why don't it happen at boot?
>>>>
>>>> Via what mechanism did you trigger the fsck at boot (other than
>>>> /forcefsck)? e.g. did you pass fsck.mode=force on the kernel command
>>>> line (as the deprecated warning suggests)? Did this not trigger things
>>>> correctly?
>>>
>>> uhm you stripped the relevant part of my message
>>>
>>> * the filesystem has reached the time for next fsck
>>> * the kernel says it's time
>>> * before systemd did happended automatically
>>> * that is why ext4 defines the fsck interval at all
>>
>> Please paste your /etc/fstab file. If it has "0 0" as the last two fields, then, of course, systemd will not call
>> fsck. If there are different numbers there, sure, let's debug.
>>
>> Also, now the entity that is supposed to check your root filesystem is dracut. Are you using it? Does the problem
>> go away if you regenerate your initramfs?
>
> i know how to deal with fstab and column 6 is not zero as well
> as the initramfs is regenrated all the time because kernel
> updates which are *the reason* for reboots on servers at all
>
> what disturbs me is they warning about "touch /forcefsck" while
> it's currently the *only* option to trigger a recommended fsck
> at boot on a remote-server (and no add kernel params for that
> in the grub-config and remove them after is not a sane way for
> sysadmins maintaining 10,20,30 remote servers)
>
> UUID=209aeed4-95bd-4eb0-bdfa-fb346b603ce9 /boot ext4 defaults 0 1
> UUID=22f62744-8fd7-4090-aff8-b35ef38b4b74 / ext4
> defaults,commit=5,inode_readahead_blks=128,noatime,nodiratime,noquota 0 1
> UUID=0b95905b-02c5-444b-af9e-7615cabebb38 /mnt/data ext4
> defaults,commit=5,inode_readahead_blks=128,noatime,nodiratime,noquota,nosuid  0 2
>

OK.

Let's try eliminating some more reasons why fsck can be skipped.

1. The root filesystem is mounted read-write at boot [but note that this 
doesn't explain failures to check other filesystems]
2. The generator did not run for some unknown reason.
3. Some other error that got hopefully logged.

Could you please attach the output of:

ls -lR /run/systemd/generator
journalctl -b

Also, could you please try replacing some non-critical UUID=... lines 
(e.g. for /boot) in your fstab by direct device references of the form 
/dev/disk/by-uuid/209aeed4-95bd-4eb0-bdfa-fb346b603ce9 or even /dev/mdX, 
just to see if that's UUID who triggers the bug for you? To avoid 
getting an inaccessible server if that misfires, you can also append 
nofail to the options for /boot.

-- 
Alexander E. Patrakov