Hi all,
Has anyone seen this issue before? This afternoon, I tried updating a bare metal CentOS 6 box, and got some odd error messages on the console during booting kernel 2.6.32-754.11.1. (These aren't exact, I forgot to try to get a photo of the console.)
sd 0:0:4:0 timed out resetting card 3w-sas timed out resetting card
Then the boot would simply hang, with no obvious disk activity on the drives and no other messages on the console. Reverting back to an earlier kernel (2.6.32-431.17.1) was perfectly fine. (Obviously this is quite old hardware, but until today had never had problems.)
I noticed in the CentOS 6.10 changelog that 3w-sas has been deprecated, but that it should still be supported. And even if 3w-sas had been removed, I don't think that wouldn't explain timeouts on sd.
I have done a bunch of searches on the CentOS forums and on the web, but didn't find anything specific to this issue with various combinations of the error message keywords. If you have any pointers for me I would greatly appreciate it!
--keith
Hi Keith,
Is this a VM running on top of Hyper-V by chance? There seems to be an issue with the combination of: - Windows 10 1708 or newer. - Hyper-V config version 8.2 - 9.0. - Microsoft's Fix for Spectre and Meltdown. - Newer Intel Hardware (Sandy Lake/Kaby Lake, etc.)
The workaround seems to be to remove "rhgb" and "quiet" from the kernel line in the GRUB config (you may need to edit the command line from the grub menu before booting).
Greg
-----Original Message----- From: CentOS centos-bounces@centos.org On Behalf Of Keith Keller Sent: March 13, 2019 7:43 PM To: centos@centos.org Subject: [CentOS] boot issue with latest kernel
Hi all,
Has anyone seen this issue before? This afternoon, I tried updating a bare metal CentOS 6 box, and got some odd error messages on the console during booting kernel 2.6.32-754.11.1. (These aren't exact, I forgot to try to get a photo of the console.)
sd 0:0:4:0 timed out resetting card 3w-sas timed out resetting card
Then the boot would simply hang, with no obvious disk activity on the drives and no other messages on the console. Reverting back to an earlier kernel (2.6.32-431.17.1) was perfectly fine. (Obviously this is quite old hardware, but until today had never had problems.)
I noticed in the CentOS 6.10 changelog that 3w-sas has been deprecated, but that it should still be supported. And even if 3w-sas had been removed, I don't think that wouldn't explain timeouts on sd.
I have done a bunch of searches on the CentOS forums and on the web, but didn't find anything specific to this issue with various combinations of the error message keywords. If you have any pointers for me I would greatly appreciate it!
--keith
-- kkeller@wombat.san-francisco.ca.us
_______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Young, Gregory wrote:
Is this a VM running on top of Hyper-V by chance? There seems to be an issue with the combination of: - Windows 10 1708 or newer.
- Hyper-V config version 8.2 - 9.0.
- Microsoft's Fix for Spectre and Meltdown.
- Newer Intel Hardware (Sandy Lake/Kaby Lake, etc.)
The workaround seems to be to remove "rhgb" and "quiet" from the kernel line in the GRUB config (you may need to edit the command line from the grub menu before booting).
<snip> Haven't been following this, but if this is a server, rather than a workstation, there is *zero* reason to have rhgb and quiet on a server. I take it off ours. If I'm standing there during boot, I always want to see what's happening.
mark
On 3/20/19 10:42 AM, mark wrote:
Young, Gregory wrote:
Is this a VM running on top of Hyper-V by chance? There seems to be an issue with the combination of: - Windows 10 1708 or newer.
- Hyper-V config version 8.2 - 9.0.
- Microsoft's Fix for Spectre and Meltdown.
- Newer Intel Hardware (Sandy Lake/Kaby Lake, etc.)
The workaround seems to be to remove "rhgb" and "quiet" from the kernel line in the GRUB config (you may need to edit the command line from the grub menu before booting).
<snip> Haven't been following this, but if this is a server, rather than a workstation, there is *zero* reason to have rhgb and quiet on a server. I take it off ours. If I'm standing there during boot, I always want to see what's happening.
Good Plan :)
On Mar 20, 2019, at 11:42 AM, mark m.roth@5-cent.us wrote:
Haven't been following this, but if this is a server, rather than a workstation, there is *zero* reason to have rhgb and quiet on a server. I take it off ours. If I'm standing there during boot, I always want to see what's happening.
I agree with you, except for systems with a slow serial console. I leave ‘quiet’ there unless I’m debugging issues, because otherwise it *slows down the boot*, patiently waiting for the serial line to catch up as it prints a bunch of stuff I’ll see in dmesg anyway.
-- Jonathan Billings billings@negate.org
On 2019-03-20, Young, Gregory gregory.young@solarwinds.com wrote:
Is this a VM running on top of Hyper-V by chance?
It is not; as I mentioned in my original post, it's bare metal.
--keith