Please don't trim the messages to tidy them, include the entire thing, or post the rdsosreport.txt if one was generated.

Statistically speaking, the errors you post are probably due to a failed read on a critical sector that the system simply can't proceed without reading, so it waits for the drive to recover, and hits the kernel SCSI command timer limit which is 30 seconds. 

If that's true, you might be able to fix the problem by booting with parameter rd.break=cmdline which gets you to a command line before anything is mounted (not even read only). And then do:

# echo 120 > /sys/block/sda/device/timeout

This will change the command timer, allowing the drive to do a long recovery and possibly enabling the bad sector to be read. I would do an e2fsck -f (assuming it's an ext fs). If it's a bad sector, and if file system metadata is on it, there's a possibility it can be fixed. Any writes to this bad sector will solve the problem, either by refreshing the existing sector's data or by remapping it if it's persistently failing writes too. You'll see all of this in dmesg.

If there are no errors in dmesg or fsck, then it's not fs metadata that's affected, it's data (binaries most likely). And that's slightly more difficult to fix. But if you just use

# exit

 that will continue with the startup process from the break. And the command timer change might allow the drive to recover this data. If not, at the very least, again if it's a bad sector, you'll get something in dmesg that's explicitly a read error and will have an LBA associated with it. Now you can find out what file's data is on that LBA using debugfs and reinstall that binary (hopefully) which causes the problem to be fixed also.