Hi, folks,
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?
mark
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
On Tue, Dec 29, 2015 at 2:43 PM, m.roth@5-cent.us wrote:
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"
You're writing the grub.cfg to the wrong location with the wrong name. It needs to go to /boot/grub2/grub.cfg - that's where the bootloader looks for it.
grubby looks for /etc/grub2.cfg which is a symlink to /boot/grub2/grub.cfg, because grubby.
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?
I'm willing to guess that something now causes this RAID device to report a logical sector size of 4096 bytes, rather than 512 bytes as is ordinarily the case for real hard drives, most of which are now 512e AF drives. It is true that 4096 byte logical sectors aren't supported by bootloaders on BIOS systems; in theory it could be supported on UEFI systems.
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.
I suggest added to /etc/default/grub
GRUB_DISABLE_OS_PROBER="true"
Since you only care about the current system being added to the boot menu, searching for other OS's is irrelevant anyway.
On Fri, Jan 01, 2016 at 11:59:05AM -0700, Chris Murphy wrote:
On Tue, Dec 29, 2015 at 2:43 PM, m.roth@5-cent.us wrote: You're writing the grub.cfg to the wrong location with the wrong name. It needs to go to /boot/grub2/grub.cfg - that's where the bootloader looks for it.
... or /boot/efi/EFI/centos/grub.cfg if you are booting from an EFI system. /etc/grub2-efi.cfg should point at it. I asked in #centos, and I think this isn't the location in earlier point releases of CentOS7. I don't have an EFI system handy to check.
grubby looks for /etc/grub2.cfg which is a symlink to /boot/grub2/grub.cfg, because grubby.
Grubby is smart about checking both symlinks, in case of EFI. I kinda wish it were just one link.
-
Chris Murphy -
Jonathan Billings -
m.roth＠5-cent.us