CentOS - Jan 2016 - Centos 7, grub2-mkconfig, unsupported sector [followup]

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 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

On Tue, Dec 29, 2015 at 2:43 PM,  <m.roth at 5-cent.us>
wrote:
> 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"
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.
>>
>>    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?
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.


-- 
Chris Murphy