Re: nasty bug in /usr/sbin/grub-probe
On 4/3/22 07:57, John Paul Adrian Glaubitz wrote:
Hello!
On 4/3/22 13:42, Dennis Clarke wrote:
But since you seem to have a reliable reproducer, you can start trying to bisect
the kernel to find the commit that introduced this regression.
That will be nearly impossible. I can not even recall when the bug first
appeared or when was the last time that I could run update-grub without
the machine locking up. At least two years now. Maybe three.
What do you mean is impossible? Bisecting the bug or the fact that it is
a kernel bug? I know very well it's a kernel bug because it does not occur
when using the 4.19 kernel on any of the affected SPARCs and it does not
occur on any of the newer SPARCs with a current kernel.
Are you sure of 4.19 ? I see that 4.19.237 exists but I will guess the
same bug exists there also. I was going to begin with 4.19.114 which was
released 02-Apr-2020. A solid two years ago seems like as good a place
to start as any. However building the kernel will require that I create
an initrd and also update grub etc etc. I can do that manually and then
bypass the "update-grub" process entirely.
The SPARC T2 and T5 we are using don't have the problem at all, for example.
Also this is an even older UltraSparc IIi type machine. Really I should
have tossed it out long ago but the next machine I have handy is a
Fujitsu M3000 unit and I thought I had heard it was impossible to get
Linux on such a beast for unknown reasons. Could be myth or rumour but I
thought the M3000 was somehow "special". The larger M4000 seems to be
fine but those are just nasty large beasts to run in a home lab.
Dragging the deep waters looking for that kernel bug will take a lot of
time. Possibly even some luck.
Not really. You cross-build the kernel, transfer it to the machine and see if
update-grub works.
Hold on. This sounds like a chicken and egg scenario. The update-grub
will fail every time. I will need to do the process by hand with an edit
to grub.cfg and with the files needed dropped into /boot with the few
kernel modules needed in /lib/modules/foo. That should be enough to at
least boot.
But I can do it myself if I find the time, I have an Ultra 45 that can be used
for that. Thought it would just be nice if I can get a helping hand, especially
since cross-compiling and bisecting the kernel isn't really hard, it just takes
time.
Right. The one thing that no one can save or store or get more. Time.
I have already started the process but I am starting with 4.19.114.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
Reply to: