m.roth at 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. > > 0. Did the grub2-mkconfig actually work correctly? > 1. Is it safe to ignore the errors and reboot? > 2. 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