[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: nasty bug in /usr/sbin/grub-probe



Hello Adrian and Dennis,

If this problem is expected to occur on an Ultra 5 or an Ultra 30,
please let me know and I'll be happy to help with a git bisect, using a
spare 9 GB disk for the installation.

-Stan

-----

On 4/3/22 5:57 AM, 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.
> 
> 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. If it doesn't, you mark the commit as bad. If it does, you
> mark the commit as good. You start from a good known working kernel such as
> 4.19.
> 
> 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.
> 
> Adrian
> 


Reply to: