m.roth@5-cent.us wrote:
Well, I get back from vacation, and three CentOS 7 boxes didn't come up this morning (my manager and the other admin did the update & reboot). On these three - but *not* another one or two, and I don't think those others are Dells, they're supermicro's - the 327 kernel fell into the rdosshell, I guess. I finally got one the three up by going back to the 228.14 kernel.
Now, after googling and finding the CentOS bugzilla, 0009860, that referenced the upstream bugzilla, I applied the workaround discussed in it, Adding initcall_blacklist=clocksource_done_booting to GRUB_CMDLINE_LINUX in /etc/default/grub and then grub2-mkconfig -o /etc/grub2.cfg"
On one. On the other, that's got a *large* RAID appliance (a JetStor w/ 42 4TB drives...), it seemed to work... then gave me a dozen or so ERROR: unsupported sector size 4096 on /dev/sdd. ERROR: unsupported sector size 4096 on /dev/sde.
- Did the grub2-mkconfig actually work correctly?
- Is it safe to ignore the errors and reboot?
- This seems to be an old bug in os-prober, that was fixed years ago - has it slipped back in?
No joy. I followed the workaround instructions... and by late afternoon, the system was in distress, with the time *far* off among other things (like an hour off).
Interesting notes: this morning, from the rsdosshell with the new kernel, I had to power cycle, and tried to boot the ...20 kernel, and it failed, as well. This time, rebooting from a running system, I was able to boot that kernel with no problem.
When I went to choose this kernel, I also one-time deleted the workaround.
At least on these servers, I've removed the current 327 kernel, and we're staying on the 20 kernel. We'll see what happens with the next kernel.
I also removed the workaround from grub,
There's still the question of why os-probe, which was supposedly fixed almost five years ago, according to what I google, is back to complaining at 4k sectors.
mark