> 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
