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
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
