> I'm trying to be helpful, but it could still be an issue with the systemd-fsck-root.service
> The initrd phase is typically very fast because it doesn't need to load many files.
> You might try booting from a live USB to boot. You can use the Gparted tool to check the root file system for errors.
we are booting a VM in openstack.
>
> I'm not clear about what you are saying, when you report "issue has disappeared" Try double checking the dracut logs.
>
> An error like "Failed to mount /dev/sda1" indicates there's a problem with the root files system.
There are no errors in the dracut logs.
> "Executing command '/sbin/fsck -C -f /dev/sda1'" would mean the fsck command is executing.
> Something like "Command '/sbin/fsck -C -f /dev/sda1' took 10 seconds to execute" might help you find the issue.
I tried [ the following actions ] from my end:
I have added fsck check in systemd-fsck-root.service and redirected
the output to console with StandardOutput= in the service file. There
are no [errors] in the file system. But [the] boot up [is] stuck after
sysroot.mount.
I have added TimeoutSec=30 in the systemd-fsck-root.service and
sysroot.mount , but bootup is still hung after sysroot.mount.
I have added one second sleep in systemd-fsck-root.service
"ExecStartPre=/usr/bin/sleep 1\n" , with a sleep of 1 second bootup
is not hung. To me it looks like a race condition where delay is
fixing the bootup hang problem.
If i add debug logs in systemd or enable dracut logs also issue is not
seen , i.e boot up is not hung.
>
> Benjamin Godfrey
In the unit file, TimeoutSec is different from TimeoutStartSec The default is 60s. Try changing the number to 61
