subject:"grub"

On 4/3/22 23:54, Dennis Clarke wrote:
> No, I am not. I am going with whatever is in the Makefile.
> 
> https://github.com/torvalds/linux/commit/fc7c028dcdbfe981bca75d2a7b95f363eb691ef3
> 
> So this was seen before regardless.

Please just follow my advise and use Linus' tree and don't use any LTS kernels
which may have some changes from the latest kernels backported.

I know that cross-compiling and bisecting works 100%, so we really don't need to
argue about this. You didn't find some hidden bug that the daily CI hasn't 
caught.

The kernel developers are regularly rebuilding the kernel for most targets with
all the various standard kernel configuration presets, so it's extremely 
unlikely
that you run a kernel that won't compile due to a bug.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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


On 4/3/22 12:13, John Paul Adrian Glaubitz wrote:

On 4/3/22 17:19, Dennis Clarke wrote:

I am curious if you can get the linux-4.19.114 kernel to compile.  For me it 
just blows up with :

.
.
.
arch/sparc/kernel/mdesc.c: In function 'mdesc_node_by_name':
arch/sparc/kernel/mdesc.c:648:22: error: 'strcmp' reading 1 or more bytes from 
a region of size 0 [-Werror=stringop-overread]
   648 | if (!strcmp(names + ep[ret].name_offset, name))
   |  ^
arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object 'mdesc' 
of size 16
78 | struct mdesc_hdrmdesc;
   | ^
arch/sparc/kernel/mdesc.c: In function 'mdesc_get_property':
arch/sparc/kernel/mdesc.c:693:22: error: 'strcmp' reading 1 or more bytes from 
a region of size 0 [-Werror=stringop-overread]
   693 | if (!strcmp(names + ep->name_offset, name)) {
   |  ^
arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object 'mdesc' 
of size 16
78 | struct mdesc_hdrmdesc;
   | ^
arch/sparc/kernel/mdesc.c: In function 'mdesc_next_arc':
arch/sparc/kernel/mdesc.c:720:21: error: 'strcmp' reading 1 or more bytes from 
a region of size 0 [-Werror=stringop-overread]
   720 | if (strcmp(names + ep->name_offset, arc_type))
   | ^
arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object 'mdesc' 
of size 16
78 | struct mdesc_hdrmdesc;
   | ^
cc1: all warnings being treated as errors
make[2]: *** [scripts/Makefile.build:304: arch/sparc/kernel/mdesc.o] Error 1
make[1]: *** [scripts/Makefile.build:544: arch/sparc/kernel] Error 2
make: *** [Makefile:1053: arch/sparc] Error 2


Not sure what to make of that.


Well, it's up right there, you are building with -Werror enabled. You have to 
disable that.



No, I am not. I am going with whatever is in the Makefile.

https://github.com/torvalds/linux/commit/fc7c028dcdbfe981bca75d2a7b95f363eb691ef3

So this was seen before regardless.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

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

Hi Stan!

On 4/3/22 16:39, Stan Johnson wrote:
> 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.

I think you should see the issue on both the Ultra 5 and Ultra 30.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

On 4/3/22 14:23, Dennis Clarke wrote:
> 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.

Of course, there is a kernel 4.19 tag:

> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/refs/tags

4.19.114 an LTS release of the 4.19.x series, you don't need it. Just use Linus'
tree and start bisecting between 4.19 and HEAD.

# git bisect start
# git bisect good 4.19
# git bisect bad HEAD

then compile and test. Mark good commits with "git bisect good", bad ones with
"git bisect bad".

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

Well, that depends where update-grub fails. If it leaves a broken GRUB 
configuration
behind, it will be a bit tricky. But if it already fails before writing 
anything to
disk, you should be safe.

> I have already started the process but I am starting with 4.19.114.

That makes no sense. You're not on Linus' tree but on the stable tree.

Stable: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

Linus' tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/

It makes no sense to test the stable tree since the different stable versions
lie on different branches, so you will never see the regression in the first
place.

You must Linus' tree since that's the only tree with a linear history.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

On 4/3/22 17:19, Dennis Clarke wrote:
> I am curious if you can get the linux-4.19.114 kernel to compile.  For me it 
> just blows up with :
> 
> .
> .
> .
> arch/sparc/kernel/mdesc.c: In function 'mdesc_node_by_name':
> arch/sparc/kernel/mdesc.c:648:22: error: 'strcmp' reading 1 or more bytes 
> from a region of size 0 [-Werror=stringop-overread]
>   648 | if (!strcmp(names + ep[ret].name_offset, name))
>   |  ^
> arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object 
> 'mdesc' of size 16
>78 | struct mdesc_hdrmdesc;
>   | ^
> arch/sparc/kernel/mdesc.c: In function 'mdesc_get_property':
> arch/sparc/kernel/mdesc.c:693:22: error: 'strcmp' reading 1 or more bytes 
> from a region of size 0 [-Werror=stringop-overread]
>   693 | if (!strcmp(names + ep->name_offset, name)) {
>   |  ^
> arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object 
> 'mdesc' of size 16
>78 | struct mdesc_hdrmdesc;
>   | ^
> arch/sparc/kernel/mdesc.c: In function 'mdesc_next_arc':
> arch/sparc/kernel/mdesc.c:720:21: error: 'strcmp' reading 1 or more bytes 
> from a region of size 0 [-Werror=stringop-overread]
>   720 | if (strcmp(names + ep->name_offset, arc_type))
>   | ^
> arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object 
> 'mdesc' of size 16
>78 | struct mdesc_hdrmdesc;
>   | ^
> cc1: all warnings being treated as errors
> make[2]: *** [scripts/Makefile.build:304: arch/sparc/kernel/mdesc.o] Error 1
> make[1]: *** [scripts/Makefile.build:544: arch/sparc/kernel] Error 2
> make: *** [Makefile:1053: arch/sparc] Error 2
> 
> 
> Not sure what to make of that.

Well, it's up right there, you are building with -Werror enabled. You have to 
disable that.

> My intuition here tells me the bug is likely in arch/sparc/kernel/syscalls.S
> which changed slightly since the 4.19.114 days. Looking
> previous I see no change in that source file. Regardless, this is just a
> hunch without a shred of proof. Yet.

There is no bug. Just your compiler set to treat warning as errors as can be 
seen
from the error message above. You have to disable CONFIG_WERROR.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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




I am curious if you can get the linux-4.19.114 kernel to compile.  For 
me it just blows up with :


.
.
.
arch/sparc/kernel/mdesc.c: In function 'mdesc_node_by_name':
arch/sparc/kernel/mdesc.c:648:22: error: 'strcmp' reading 1 or more 
bytes from a region of size 0 [-Werror=stringop-overread]

   648 | if (!strcmp(names + ep[ret].name_offset, name))
   |  ^
arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object 
'mdesc' of size 16

    78 | struct mdesc_hdr    mdesc;
   | ^
arch/sparc/kernel/mdesc.c: In function 'mdesc_get_property':
arch/sparc/kernel/mdesc.c:693:22: error: 'strcmp' reading 1 or more 
bytes from a region of size 0 [-Werror=stringop-overread]

   693 | if (!strcmp(names + ep->name_offset, name)) {
   |  ^
arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object 
'mdesc' of size 16

    78 | struct mdesc_hdr    mdesc;
   | ^
arch/sparc/kernel/mdesc.c: In function 'mdesc_next_arc':
arch/sparc/kernel/mdesc.c:720:21: error: 'strcmp' reading 1 or more 
bytes from a region of size 0 [-Werror=stringop-overread]

   720 | if (strcmp(names + ep->name_offset, arc_type))
   | ^
arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object 
'mdesc' of size 16

    78 | struct mdesc_hdr    mdesc;
   | ^
cc1: all warnings being treated as errors
make[2]: *** [scripts/Makefile.build:304: arch/sparc/kernel/mdesc.o] 
Error 1

make[1]: *** [scripts/Makefile.build:544: arch/sparc/kernel] Error 2
make: *** [Makefile:1053: arch/sparc] Error 2


Not sure what to make of that.



Drat :

https://github.com/torvalds/linux/commit/fc7c028dcdbfe981bca75d2a7b95f363eb691ef3


So something after 4.19.114 may work.



--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

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


On 4/3/22 10:39, Stan Johnson wrote:

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.



The Ultra 5 is even older. At least I think so. There were two flavours
of those bizarre PC style machines where one was a tower looking thing
called the Ultra 10 and it could have a Creator3D OpenGL hardware frame
buffer whereas the Ultra 5 was a modified weird pizza box thing. Both
are from well before the UltraSparc III existed.

Please feel free to jump in.

I am curious if you can get the linux-4.19.114 kernel to compile.  For 
me it just blows up with :


.
.
.
arch/sparc/kernel/mdesc.c: In function 'mdesc_node_by_name':
arch/sparc/kernel/mdesc.c:648:22: error: 'strcmp' reading 1 or more 
bytes from a region of size 0 [-Werror=stringop-overread]

  648 | if (!strcmp(names + ep[ret].name_offset, name))
  |  ^
arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object 
'mdesc' of size 16

   78 | struct mdesc_hdrmdesc;
  | ^
arch/sparc/kernel/mdesc.c: In function 'mdesc_get_property':
arch/sparc/kernel/mdesc.c:693:22: error: 'strcmp' reading 1 or more 
bytes from a region of size 0 [-Werror=stringop-overread]

  693 | if (!strcmp(names + ep->name_offset, name)) {
  |  ^
arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object 
'mdesc' of size 16

   78 | struct mdesc_hdrmdesc;
  | ^
arch/sparc/kernel/mdesc.c: In function 'mdesc_next_arc':
arch/sparc/kernel/mdesc.c:720:21: error: 'strcmp' reading 1 or more 
bytes from a region of size 0 [-Werror=stringop-overread]

  720 | if (strcmp(names + ep->name_offset, arc_type))
  | ^
arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object 
'mdesc' of size 16

   78 | struct mdesc_hdrmdesc;
  | ^
cc1: all warnings being treated as errors
make[2]: *** [scripts/Makefile.build:304: arch/sparc/kernel/mdesc.o] Error 1
make[1]: *** [scripts/Makefile.build:544: arch/sparc/kernel] Error 2
make: *** [Makefile:1053: arch/sparc] Error 2


Not sure what to make of that.

My intuition here tells me the bug is likely in 
arch/sparc/kernel/syscalls.S which changed slightly since the 4.19.114 
days. Looking

previous I see no change in that source file. Regardless, this is just a
hunch without a shred of proof. Yet.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

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

2022-04-03 Thread Stan Johnson

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
>

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

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

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

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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


On 4/2/22 03:30, John Paul Adrian Glaubitz wrote:

Hello Dennis!

On 4/2/22 03:34, Dennis Clarke wrote:

I am not so sure about this yet until I can rebuild the required grub
binaries with full debug info. For at least a year ( or more ) I have
seen "really bad things"(tm) happen when I try to make a new initrd on
sparc64. Generally the machine seems to pack up and go away with nary a
single packet out to the world. To look into this problem I use a serial
attached good old 9600 baud console and watch what happens when I try to
do a make install from within the Linux source tree :
(...)
So therefore I think that there is a bug in /usr/sbin/grub-probe and it
really kills the whole "make install" process from within the Linux
kernel source tree or any other way you choose to run it.

Has anyone else seen this ?


This isn't a bug in GRUB but a kernel bug that affects older SPARC machines
like your UltraSPARC IIIi. Unfortunately, no one has had the time yet to bisect
this issue.

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.

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.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

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

2022-04-02 Thread John Paul Adrian Glaubitz

Hello Dennis!

On 4/2/22 03:34, Dennis Clarke wrote:
> I am not so sure about this yet until I can rebuild the required grub
> binaries with full debug info. For at least a year ( or more ) I have
> seen "really bad things"(tm) happen when I try to make a new initrd on
> sparc64. Generally the machine seems to pack up and go away with nary a
> single packet out to the world. To look into this problem I use a serial
> attached good old 9600 baud console and watch what happens when I try to
> do a make install from within the Linux source tree :
> (...)
> So therefore I think that there is a bug in /usr/sbin/grub-probe and it
> really kills the whole "make install" process from within the Linux
> kernel source tree or any other way you choose to run it.
> 
> Has anyone else seen this ?

This isn't a bug in GRUB but a kernel bug that affects older SPARC machines
like your UltraSPARC IIIi. Unfortunately, no one has had the time yet to bisect
this issue.

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.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

2022-04-01 Thread Dennis Clarke


On 4/1/22 22:03, Stan Johnson wrote:

Hi Dennis,

Unless you already know that your system's memory is ok...



Sparc machines generally have ECC memory and the diagnostics are quite
well trusted.

However ... just for giggles ( yes the battery is crap ) :


root@hades:~#
root@hades:~# shutdown -h 'now'
root@hades:~# [  OK  ] Removed slic Stopping Rescue Shell...
 Stopping Load/Save Random Seed...
[  OK  ] Stopped Rescue Shell.
[  OK  ] Stopped target System Initialization.
[  OK  ] Unset automount Arbitrary b&s File System Automount Point.
[  OK  ] Stopped target Local Encrypted Volumes.
[  OK  ] Stopped Dispatch Password b&ts to Console Directory Watch.
[  OK  ] Stopped target Local Integrity Protected Volumes.
[  OK  ] Stopped target Swaps.
[  OK  ] Stopped target Local Verity Protected Volumes.
 Deactivating swap /dev/disb&_3CD0ZHE27120K5BC-part2...
 Stopping Record System Boot/Shutdown in UTMP...
[  OK  ] Deactivated swap /dev/diskb&00:01:02.0-scsi-0:0:0:0-part2.
[  OK  ] Deactivated swap /dev/diskb&6G_3CD0ZHE27120K5BC-part2.
[  OK  ] Deactivated swap /dev/sda2.
[  OK  ] Stopped ifup for eth0.
[  OK  ] Stopped Load/Save Random Seed.
[  OK  ] Deactivated swap /dev/diskb&2-e35a-4ff4-b7f5-f7d028c4ca2c.
[  OK  ] Stopped Record System Boot/Shutdown in UTMP.
[  OK  ] Stopped Apply Kernel Variables.
[  OK  ] Stopped Load Kernel Modules.
[  OK  ] Stopped Create Volatile Files and Directories.
[  OK  ] Stopped target Local File Systems.
 Unmounting /boot...
 Unmounting /home...
 Unmounting /run/credentials/systemd-sysusers.service...
 Unmounting /usr/local...
[  OK  ] Unmounted /boot.
[  OK  ] Unmounted /home.
[  OK  ] Unmounted /run/credentials/systemd-sysusers.service.
[  OK  ] Unmounted /usr/local.
[  OK  ] Reached target Unmount All Filesystems.
[  OK  ] Stopped File System Check b&6-88fb-4134-88c5-485c34d4614c.
[  OK  ] Stopped File System Check b&f-421e-477d-b5e3-830365a86b19.
[  OK  ] Stopped File System Check b&9-00f1-497b-8b83-d726e914d044.
[  OK  ] Removed slice Slice /system/systemd-fsck.
[  OK  ] Stopped target Preparation for Local File Systems.
[  OK  ] Stopped Create Static Device Nodes in /dev.
[  OK  ] Stopped Create System Users.
[  OK  ] Stopped Remount Root and Kernel File Systems.
[  OK  ] Reached target System Shutdown.
[  OK  ] Reached target Late Shutdown Services.
[  OK  ] Finished System Power Off.
[  OK  ] Reached target System Power Off.
[ 4732.049137] systemd-shutdown[1]: Syncing filesystems and block devices.
[ 4732.541119] systemd-shutdown[1]: Sending SIGTERM to remaining 
processes...
[ 4732.650924] systemd-journald[183]: Received SIGTERM from PID 1 
(systemd-shutdow).
[ 4732.886493] systemd-shutdown[1]: Sending SIGKILL to remaining 
processes...

[ 4732.995664] systemd-shutdown[1]: Unmounting file systems.
[ 4733.075318] [308]: Remounting '/' read-only with options 
'errors=remount-ro'.
[ 4733.223777] EXT4-fs (sda4): re-mounted. Opts: errors=remount-ro. 
Quota mode: none.

[ 4733.335759] systemd-shutdown[1]: All filesystems unmounted.
[ 4733.409207] systemd-shutdown[1]: Deactivating swaps.
[ 4733.474932] systemd-shutdown[1]: All swaps deactivated.
[ 4733.543741] systemd-shutdown[1]: Detaching loop devices.
[ 4733.614459] systemd-shutdown[1]: All loop devices detached.
[ 4733.687858] systemd-shutdown[1]: Stopping MD devices.
[ 4733.755436] systemd-shutdown[1]: All MD devices stopped.
[ 4733.825318] systemd-shutdown[1]: Detaching DM devices.
[ 4733.893652] systemd-shutdown[1]: All DM devices detached.
[ 4733.964778] systemd-shutdown[1]: All filesystems, swaps, loop 
devices, MD devices and DM devices detached.

[ 4734.136742] systemd-shutdown[1]: Syncing filesystems and block devices.
[ 4734.227936] systemd-shutdown[1]: Powering off.
[ 4734.286653] sd 0:0:1:0: [sdb] Synchronizing SCSI cache
[ 4734.354622] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 4734.423032] reboot: Power down
lom>
LOM event: power off
lom>

Get a coffee or whiskey or both and let the electrons settle...


lom>
LOM event: power on

ps/2 kbd check: ...00fe
Checking Sun KB Done
%o0 = ..0055.4001

Executing Power On SelfTest


SPARCengine(tm)Ultra CP 1500 POST 1.17 ME created 03/06/00
 WARRNING: NVRAM battery is either bad or just replaced!
Time Stamp [hour:min:sec] 33:30:02

Init POST BSS
Init System BSS

Probing system keyboard : Done
DMMU TLB Tags
DMMU TLB Tag Access Test
DMMU TLB RAM
DMMU TLB RAM Access Test
Ecache Tests
Probe Ecache
ecache_size = 0x0020
Ecache RAM Addr Test
Ecache Tag Addr Test
Ecache RAM Test
Ecache Tag Test
Invalidate Ecache Tags
All CPU Basic Tests
V9 Instruction Test
CPU Tick and Tick Compare Reg Test
CPU Soft Trap Test
CPU Softint Reg and Int Test
All Basic MMU Tests
DMMU Primary Context Reg Test
DMMU Secondary Context Reg Test
DMMU TSB Reg Test
DMM

nasty bug in /usr/sbin/grub-probe

2022-04-01 Thread Dennis Clarke




I am not so sure about this yet until I can rebuild the required grub
binaries with full debug info. For at least a year ( or more ) I have
seen "really bad things"(tm) happen when I try to make a new initrd on
sparc64. Generally the machine seems to pack up and go away with nary a
single packet out to the world. To look into this problem I use a serial
attached good old 9600 baud console and watch what happens when I try to
do a make install from within the Linux source tree :


root@hades:~# [80684.783560] watchdog: BUG: soft lockup - CPU#0 stuck 
for 26s! [grub-probe:47798]
[80684.880888] Modules linked in: sg(E) envctrl(E) display7seg(E) 
flash(E) fuse(E) drm(E) drm_panel_orientation_quirks(E) i2c_core(E) 
configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) 
mbcache(E) jbd2(E) crc32c_generic(E) sd_mod(E) t10_pi(E) crc_t10dif(E) 
crct10dif_generic(E) crct10dif_common(E) sym53c8xx(E) 
scsi_transport_spi(E) scsi_mod(E) scsi_common(E) sunhme(E)
[80685.320414] CPU: 0 PID: 47798 Comm: grub-probe Tainted: G 
E 5.16.0-6-sparc64 #1  Debian 5.16.18-1
[80685.454308] TSTATE: 11001607 TPC: 009555d0 TNPC: 
009555d4 Y: Tainted: GE

[80685.601952] TPC: 
[80685.652373] g0:  g1: 0098 g2: 
 g3: 0714ebe0
[80685.766856] g4: f8000137ae40 g5: 62462570 g6: 
f800097a8000 g7: 00a88958
[80685.881335] o0: 00fa7a08 o1: f800097ab8ec o2: 
f82f72d0 o3: 0001
[80685.995814] o4: f887f968 o5:  sp: 
f800097aaf81 ret_pc: 009555a0

[80686.114867] RPC: 
[80686.165292] l0: f81b9800 l1: 00fa7800 l2: 
00685d20 l3: 0006dc08077e
[80686.279793] l4: 0470 l5: ff9c l6: 
f800097a8000 l7: 0067e1a0
[80686.394261] i0: f887f968 i1: f80001121960 i2: 
00fa7800 i3: 00fa7a20
[80686.508740] i4: 00ec i5: 10074830 i6: 
f800097ab031 i7: 00686958

[80686.623218] I7: 
[80686.674783] Call Trace:
[80686.706910] [<00686958>] chrdev_open+0x98/0x1c0
[80686.775642] [<0067bef0>] do_dentry_open+0x170/0x420
[80686.848946] [<0067da08>] vfs_open+0x28/0x40
[80686.913099] [<00693500>] path_openat+0xb20/0x10e0
[80686.984115] [<006948c0>] do_filp_open+0x60/0x100
[80687.053986] [<0067dcf0>] do_sys_openat2+0x70/0x180
[80687.126146] [<0067e1e8>] sys_openat+0x48/0xc0
[80687.192588] [<00406174>] linux_sparc_syscall+0x34/0x44
[80708.777890] watchdog: BUG: soft lockup - CPU#0 stuck for 48s! 
[grub-probe:47798]
[80708.875209] Modules linked in: sg(E) envctrl(E) display7seg(E) 
flash(E) fuse(E) drm(E) drm_panel_orientation_quirks(E) i2c_core(E) 
configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) 
mbcache(E) jbd2(E) crc32c_generic(E) sd_mod(E) t10_pi(E) crc_t10dif(E) 
crct10dif_generic(E) crct10dif_common(E) sym53c8xx(E) 
scsi_transport_spi(E) scsi_mod(E) scsi_common(E) sunhme(E)
[80709.314756] CPU: 0 PID: 47798 Comm: grub-probe Tainted: G 
EL5.16.0-6-sparc64 #1  Debian 5.16.18-1
[80709.448637] TSTATE: 11001607 TPC: 009555d0 TNPC: 
009555d4 Y: Tainted: GEL

[80709.596283] TPC: 
[80709.646701] g0:  g1: 0098 g2: 
 g3: 0714ebe0
[80709.761187] g4: f8000137ae40 g5: 62462570 g6: 
f800097a8000 g7: 00a88958
[80709.875665] o0: 00fa7a08 o1: f800097ab8ec o2: 
f82f72d0 o3: 0001
[80709.990145] o4: f887f968 o5:  sp: 
f800097aaf81 ret_pc: 009555a0

[80710.109199] RPC: 
[80710.159618] l0: f81b9800 l1: 00fa7800 l2: 
00685d20 l3: 0006dc08077e
[80710.274105] l4: 0470 l5: ff9c l6: 
f800097a8000 l7: 0067e1a0
[80710.388583] i0: f887f968 i1: f80001121960 i2: 
00fa7800 i3: 00fa7a20
[80710.503061] i4: 00ec i5: 10074830 i6: 
f800097ab031 i7: 00686958

[80710.617539] I7: 
[80710.669104] Call Trace:
[80710.701126] [<00686958>] chrdev_open+0x98/0x1c0
[80710.769859] [<0067bef0>] do_dentry_open+0x170/0x420
[80710.843164] [<0067da08>] vfs_open+0x28/0x40
[80710.907316] [<00693500>] path_openat+0xb20/0x10e0
[80710.978333] [<006948c0>] do_filp_open+0x60/0x100
[80711.048204] [<0067dcf0>] do_sys_openat2+0x70/0x180
[80711.120364] [<0067e1e8>] sys_openat+0x48/0xc0
[80711.186805] [<00406174>] linux_sparc_syscall+0x34/0x44
[80732.772223] watchdog: BUG: soft lockup - CPU#0 stuck for 71s! 
[grub-probe:47798]
[80732.869531] Modules linked in: sg(E) envctrl(E) display7seg(E) 
flash(E) fuse(E) drm(E) drm_panel_orientation_quirks(E) i2c_core

Re: Bug#610490: grub-ieee1275: runs out of memory on UltraSPARC 10

2022-02-08 Thread John Paul Adrian Glaubitz

Hi!

On 4/25/20 08:33, John Paul Adrian Glaubitz wrote:
> Could you please retest with the latest ISO image for sparc64 [1] and
> check whether this issue has been resolved for you now?
> 
> We have fixed a lot of issues around GRUB on sparc64, both upstream and
> in Debian and I'm confident that GRUB should work now out of the box
> even on your UltraSPARC 10.
> 
> FWIW, there are currently some issues with 5.x on older UltraSPARC machines
> but these should not affect this bug report.
> 
> If GRUB works for you on sparc64 after testing the image, please consider
> closing this bug report.

I'm closing this now since GRUB has been known to work on most UltraSPARC
machines without any problems. There are some issues with machines where
the OpenFirmware version is too old but this isn't something that can be
fixed in GRUB itself.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Kernel Panics / Re: GRUB testers on SPARC needed

2021-05-25 Thread Robin Cremer

thanks for the information. I'm still battling a few issues, but the 
most prominent problem on my way to netboot-install is that I can't seem 
to get the apt/sources.list right for fetching sources (?):

You just have to build the debian-installer package on sparc64 using sbuild and 
as a result, you will get
the tarball containing the netboot and cdrom images.
...trying to get the build-deps for debian-installer complains, that I 
should at least specify one deb-src line in my sources.list...
I have the settings the installer configured ("deb-src 
http://deb.debian.org/debian-ports/ sid main"), but sid doesn't have a 
/main/source on debian-ports... "unreleased" does have a source folder,
but apt seems to ignore the "unreleased" distribution for sources (maybe 
that's what the comment "unreleased does not support sources yet" means?)


Well... long story short: Can you point me in the right direction to get 
the sources the debian-ports use? Or is the normal way to pull sources 
from "normal" debian repositories?


Thanks,
Robin

Re: Kernel Panics / Re: GRUB testers on SPARC needed

2021-05-17 Thread Frank Scheiner


Hi Robin,

On 17.05.21 12:36, Robin Cremer wrote:

[...]
On a not entirely unrelated note:
Are there any news on functioning netboot images? The last post I could
find points to images from April '17 on your webspace, which were,
according to the ML, not bootable because of the size.
At least I can't boot them either.


Can't help you with any netboot images, though I assume the existing
ones in the archives ([1], images are in
`./installer-sparc64/20210415/images/netboot/netboot.tar.gz`) could
actually work if they are loaded from GRUB and not from the OBP.

[1]:
http://ftp.ports.debian.org/debian-ports/pool-sparc64/main/d/debian-installer/


If there is no more recent version, I'll try to build something myself -
are there any pointers on how to go about this? Minimal OS or the
netinstaller in an .img would be preferred.


I described a possible setup to netboot with GRUB on [2]. My used
version of GRUB is old (`sparc64-ieee1275-2.02+dfsg1-18`) but works.
This setup works similarly to identically for most of my machinery
(ia64, amd64, powerpc, ppc64, sparc64) and for me GRUB is able to load
"large" images (> 100 MiB, tested during my investigation on [3]) over
network w/o an issue. With a working sparc64 Debian installation it's
even easier to setup. You can host everything needed (I recommend:
dnsmasq (only for DNS), tftpd-hpa, isc-dhcp-server and possibly rarpd)
on a Raspberry Pi for example. I assume you're already familiar with
these services but just ask if you need some help in configuration.

[2]: https://wiki.debian.org/Sparc64#Netbooting_with_GRUB2

[3]: https://lists.debian.org/debian-sparc/2021/03/msg00045.html


I think that would help in quick testing, as I have multiple other
systems with Cheetah (UltraSPARC III, III CU and IIIi) I'd like to try
provoking the panics on.
Also, some older (UltraSPARC IIi and IIe+) systems are waiting for
recent Debian :-)


For testing multiple systems for anomalies I'd recommend to netboot with
a Debian root FS provided by NFS which saves you the time to install
Debian on every machine. There were two posts on the debian-sparc list
recently ([4]) by Anatoly that mentioned the `stress-ng` tool, which
might be helpful in provoking panics and possibly identifying the source
of a panic.

[4]:
https://lists.debian.org/cgi-bin/search?P=stress-ng&DEFAULTOP=or&B=Gdebian-sparc&SORT=&HITSPERPAGE=10

Cheers,
Frank

Re: Kernel Panics / Re: GRUB testers on SPARC needed

2021-05-17 Thread John Paul Adrian Glaubitz

On 5/17/21 12:36 PM, Robin Cremer wrote:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/sparc?id=e5e8b80d352ec999d2bba3ea584f541c83f4ca3f
> I'm using the latest version from the repositories:
>> 5.10.0-6-sparc64-smp #1 SMP Debian 5.10.28-1 (2021-04-09) sparc64 GNU/Linux
> The commit you mention seems to be in 5.12 and 5.13-rc2?
> Is there a pre-built SMP-image for this or do I have to set up building 
> myself?

The commit has been backported to the 5.10.x series which is an LTS kernel:

> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/sparc?h=linux-5.10.y&id=f2b38f03a3f71c30c77a4516b26c8bea13cc08ce

> Running on the v215 was a real nightmare yesterday. They will be stable for 
> hours, but
> certain actions (in one occurence executing dmesg (!), apt-get installing 
> nfs-common,
> some mounts systemd tries) crashed both of the boxes with various errors, 
> most of them the
> dreaded line with "p

Try to use a 4.19 kernel from snapshot.debian.org, these are known to run more 
stable on the
older machines. Any machine older than T2 seem to have some issues with the 
more recent kernels.

If you have the possibility to bisect the issue, that would be great. I do have 
such older machines
myself but currently no possibility to set them up for bisecting.

On the newer CPUs (>= SPARC T2), the kernel runs stable. Dave Miller (the Linux 
SPARC maintainer)
uses a T5 himself for testing.

> Retrying the dpkg-reconfigure as well. After the systemd-unit for - I think - 
> rpcbind was activated
> during package configuration, both boxes crashed about 4-6 times, I had to 
> reset from OBP.
> After a few tries, installation went through, then. Now I can mount nfs...
> The hours I spent in the rescue mode of the current installation CD without 
> any trouble made me suspect
> that non-SMP-kernels are "more stable". I'm currently running the SMP variant 
> with "maxcpus=1", that
> seems stable so far... But as with any other sporadic issue, that's hard to 
> tell with a way to reliably
> trigger the errors...

I think these issues have started to show up sometime after 4.19 but only on 
the older machines. So, chances
are you can bisect the issue.

> On a not entirely unrelated note:
> Are there any news on functioning netboot images? The last post I could find 
> points to images from April '17
> on your webspace, which were, according to the ML, not bootable because of 
> the size.

I don't have the time and resources at the moment to work on netboot. I'm not 
just maintaining the sparc64
port in Debian but also many of the other unofficial ports such as 32-bit 
PowerPC. So far, netboot has not
been a top priority so I haven't worked on it yet.

Additional support is always welcome.

> At least I can't boot them either.
> If there is no more recent version, I'll try to build something myself - are 
> there any pointers on how to go
> about this? Minimal OS or the netinstaller in an .img would be preferred.

You just have to build the debian-installer package on sparc64 using sbuild and 
as a result, you will get
the tarball containing the netboot and cdrom images.

> I think that would help in quick testing, as I have multiple other systems 
> with Cheetah (UltraSPARC III, III CU
> and IIIi) I'd like to try provoking the panics on. Also, some older 
> (UltraSPARC IIi and IIe+) systems are waiting
> for recent Debian :-)
For these machines, I would recommend installing a regular release, then 
downgrading the kernel to 4.19, then
bi-sect using a cross-compiled kernel if you have a working reproducer.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Kernel Panics / Re: GRUB testers on SPARC needed

2021-05-17 Thread Robin Cremer


Hi Adrian,
for the sake of visibility, here the response to the kernel-trouble:

Am 17.05.2021 um 10:23 schrieb John Paul Adrian Glaubitz:

Installing on two SunFire v215 went reasonably well

/- (apart from recurring Kernel Panics with "Unable to handle kernel paging request 
in mna handler",
most often triggered on boot immediately after the systemd binfmt service tries 
to start. This seems
to have been mentioned in /2020/04/msg00020.html but never pinpointed and 
fixed?) -/

What kernel version are you running. There have actually been some fixes in 
this regard, in particular
this fix:


https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/sparc?id=e5e8b80d352ec999d2bba3ea584f541c83f4ca3f

I'm using the latest version from the repositories:
5.10.0-6-sparc64-smp #1 SMP Debian 5.10.28-1 (2021-04-09) sparc64 
GNU/Linux

The commit you mention seems to be in 5.12 and 5.13-rc2?
Is there a pre-built SMP-image for this or do I have to set up building 
myself?



Running on the v215 was a real nightmare yesterday. They will be stable 
for hours, but certain actions (in one occurence executing dmesg (!), 
apt-get installing nfs-common, some mounts systemd tries) crashed both 
of the boxes with various errors, most of them the dreaded line with "p
Retrying the dpkg-reconfigure as well. After the systemd-unit for - I 
think - rpcbind was activated during package configuration, both boxes 
crashed about 4-6 times, I had to reset from OBP.

After a few tries, installation went through, then. Now I can mount nfs...
The hours I spent in the rescue mode of the current installation CD 
without any trouble made me suspect that non-SMP-kernels are "more 
stable". I'm currently running the SMP variant with "maxcpus=1", that 
seems stable so far... But as with any other sporadic issue, that's hard 
to tell with a way to reliably trigger the errors...


The worst offender so far seems to be xfs, though...
I initially installed both v215 with ext3 /boot and xfs for /.
I'm not sure if the problem is related, but xfs seems to frequently 
encounter
[   35.325122] XFS (md1): Metadata corruption detected at 
xfs_dinode_verify.part.0+0x358/0x6c0 [xfs], inode 0x402c4d0 dinode

[   35.469639] XFS (md1): Unmount and run xfs_repair
on both machines. xfs_repair doesn't do anything, though. Either, these 
inodes were the last ones written during kernel panics, or the 
underlying issue of the panics
leads to checksum-mismatches in-memory? The latter seems more likely, 
because during dpkg-installs the following popped up a few times as well:
[  195.360257] XFS (md1): Corruption of in-memory data detected.  
Shutting down filesystem
(after that, obviously, the system is unusable despite not panicking, as 
root is missing entirely...)


Some faults:
[  281.304119] WARNING: CPU: 1 PID: 11 at kernel/smp.c:633 
smp_call_function_many_cond+0x3bc/0x3e0
[  281.418696] Modules linked in: ext4(E) crc16(E) mbcache(E) jbd2(E) 
sr_mod(E) cdrom(E) ata_generic(E) tg3(E) libphy(E) ptp(E) ohci_pci(E) 
sg(E) pata_ali(E) ehci_pci(E) ohci_hcd(E) ehci_hcd(E) libata(E) 
pps_core(E) usbcore(E) usb_common(E) flash(E) drm(E) 
drm_panel_orientation_quirks(E) i2c_core(E) fuse(E) configfs(E) 
ip_tables(E) x_tables(E) autofs4(E) xfs(E) raid10(E) raid456(E) 
async_raid6_recov(E) async_memcpy(E) async_pq(E) raid6_pq(E) 
async_xor(E) xor(E) async_tx(E) libcrc32c(E) crc32c_generic(E) 
raid0(E) multipath(E) linear(E) raid1(E) md_mod(E) sd_mod(E) t10_pi(E) 
crc_t10dif(E) crct10dif_generic(E) crct10dif_common(E) mptsas(E) 
scsi_transport_sas(E) mptscsih(E) mptbase(E) scsi_mod(E)
[  282.224447] CPU: 1 PID: 11 Comm: ksoftirqd/1 Tainted: G D E 
5.10.0-6-sparc64-smp #1 Debian 5.10.28-1

[  282.359710] Call Trace:
[  282.391788] [<0046c67c>] __warn+0xbc/0x120
[  282.454810] [<00c450f8>] warn_slowpath_fmt+0x34/0x74
[  282.529285] [<00517b5c>] 
smp_call_function_many_cond+0x3bc/0x3e0

[  282.617512] [<00517be4>] smp_call_function+0x24/0x40
[  282.691989] [<00441828>] smp_send_stop+0x28/0x120
[  282.763028] [<00c44e84>] panic+0x110/0x350
[  282.826047] [<00472ad0>] do_exit+0xad0/0xb20
[  282.891357] [<00c43ab0>] die_if_kernel+0x1f4/0x260
[  282.963543] [<00c5501c>] unhandled_fault+0x88/0xac
[  283.035728] [<00c553c8>] do_sparc64_fault+0x388/0xa80
[  283.111354] [<00407714>] sparc64_realfault_common+0x10/0x20
[  283.193850] [<005a1e64>] __bpf_prog_put_rcu+0x24/0x60
[  283.269470] [<004f5c20>] rcu_core+0x240/0x620
[  283.335926] [<004f600c>] rcu_core_si+0xc/0x20
[  283.402383] [<00c5602c>] __do_softirq+0x10c/0x3a0
[  283.473423] [<00473b14>] run_ksoftirqd+0x34/0x60
[  283.543315] ---[ end trace 9f0a29fcdf85be47 ]---


[  124.914048] CPU[1]: Cheetah+ D-cache parity error at 
TPC[005bc2b0]

[  125.004638] TPC
nfs-utils.service is a disabled or a static unit, not starting it.
[  125.528183] Kernel unaligned access at

Re: GRUB testers on SPARC needed

2021-05-17 Thread Robin Cremer

Hi Adrian,

thanks for the response!

First things first: I got GRUB to work yesterday :-)
The last bit of magic missing in the picture was what you expected: The
blocklist was "shifted" because GRUB-install didn't correctly determine
the relation of physical disk vs. MDraid-Volume block positions.

Not sure if it does when installing on x86 with blocklists?
I found it hard to find usable documentation about the actual physical
on-disk-layout of MDraid RAID-1.
SuperBlocks are well documented, the "complex" RAID-levels reasonably
well also, but I found no mention that building the volume with
metadata-version 1.2
(metadata 4k from beginning of disk, which shouldn't be a problem, as
only the first 2 512-Byte sectors (->~1k) are in use for label & GRUB
boot.img) actually shifts the start of Data in the mdraid to the end of
the first 1MB block - so blocklist numbers are off by 1MB.
I noticed that by trial & error: I opened a "normally installed" disk
and the RAID member disk I tried to build in a hexeditor ;-)
metadata=0.9 does not do this. I thought the metadata-settings only
affected the position and "type" of the mdraid metadata blocks, not the
actual on-disk-layout of the mirror.

So, long story short:
My old setup with SILO was exactly like this: metadata=0.9 for the /boot
partition. With this, the ext3 blocks are on the same position on the
physical disk AND on the md-volume.
I might have set it up like this for the same reason back then, but
forgot... It's been quite a while.

The second (although minor) trouble was, that grub-mkconfig generates an
unusable grub.cfg for this setup. It refuses to set the "root=" variable
to (mduuid/UUID), which was in turn necessary to install the bootblocks,
instead using settings that lead to GRUB being unable to open the
partition label and failing back to OBP.

The best solution I found was to edit the
/usr/lib/grub/grub-mkconfig_lib shellscript to not set root at all.
In my case, that works flawlessly, as GRUB actually starts with "root="
already set to the disk that loaded it, so it even works with one disk
pulled from the server, simulating failure - which was exactly what I
wanted.

So, long story short:
- Patching util/setup.c to correctly handle (virtual) block devices
without partition tables.

- Use metadata=0.9 to build the mirror (!)
- Add device.map entry for MDraid-Device to work around the "diskfilter
writes not supported"-issue (from grub-probe -t ieee1275_hints -d /dev/md0):

(mduuid/66bf8873932144cf2d6a74e4a05e67d3) /dev/md0

- Strip the lines in /usr/lib/grub/grub-mkconfig_lib between

# otherwise set root as per value in device.map.

and

IFS="$old_ifs"

to make boot entries that do not try to re-set "root"

After this fight, I achieved my boot mirror setup on GRUB/SPARC :-)

I'll respond to the kernel-stuff separately.

Thanks!

- Robin

Am 17.05.2021 um 10:23 schrieb John Paul Adrian Glaubitz:

Hi Robin!

On 5/15/21 7:25 PM, Robin Cremer wrote:

7. Report back to the list and include your hardware and partition setup

A bit late to the party, as SILO already appears to be gone (including the
repos) and
all install images use GRUB now, but I'm having trouble and wanted to report
this - and
maybe get some ideas, in case this is the best address to do so:

You can still install SILO from snapshot.debian.org. However, I would recommend
building
the latest version from source as there have been some bugfixes in the meantime.

I'm in the process of migrating most of our SPARC servers running Solaris 10 &
the old Debian
with 32bit SPARC userland to the SPARC64 debport. Some servers running Solaris
11 will follow.

Good to hear.

Installing on two SunFire v215 went reasonably well

/- (apart from recurring Kernel Panics with "Unable to handle kernel paging request
in mna handler",
most often triggered on boot immediately after the systemd binfmt service tries
to start. This seems
to have been mentioned in /2020/04/msg00020.html but never pinpointed and
fixed?) -/

What kernel version are you running. There have actually been some fixes in
this regard, in particular
this fix:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/sparc?id=e5e8b80d352ec999d2bba3ea584f541c83f4ca3f
but I can't seem to be able to configure GRUB on these servers as I did in the
past with SILO (a 2-disk
mdraid with mirrored /boot, / and swap). I'm currently stuck with /boot on only
one disk and the rest of
the system mirrored as I can't figure out how to install grub for a mirrored
/boot partition:

Please keep in mind that GRUB is installed using blocklists on these older
machines which means it's not
aware of the filesystem being used. The bootloader will just remember the
location of the data blocks
and the physical disk. So it has no m

Re: GRUB testers on SPARC needed

2021-05-17 Thread John Paul Adrian Glaubitz

On 5/16/21 2:03 AM, Robin Cremer wrote:
> Responding to myself:
> 
> Some progress:
> I put additional informational output between all commands in the suspect 
> area in GRUBs util/setup.c and pinpointed the bug:
> 
>> #ifdef GRUB_SETUP_SPARC64
>>   {
>>     grub_partition_t container = root_dev->disk->partition;
>>
>>     if (grub_strstr (container->partmap->name, "gpt"))
>>   bl.gpt_offset = grub_partition_get_start (container);
>>   }
>> #endif
> 
> When installing on an md-device - or other special devices - it will never 
> have a partition table, thus "container" is null.

It might be trying to read the partition table from a fixed position where it 
wouldn't be when using
a software RAID, not sure. In any case, this definitely needs to be moved 
upstream and you should
put Eric Snowberg from Oracle in the loop as he is the expert on GRUB for SPARC.

> After that, access to struct members is tried without checking if it even 
> exists, leading to the segfault.
>> if (container && grub_strstr (container->partmap->name, "gpt"))
> actually works & installs on LVM if I put a hint for GRUB into the device.map 
> pointing to the UUID of the MDRAID.
> 
> I'll try to get a patch for that submitted or discussed (I'm new to this and 
> not exactly sure if the change has other implications).
> 
> 
> It still won't boot, though. The first "stage" in the 2nd partition block is 
> executed by OBP and something along the lines
> of "GRUB FAIL - trap: Illegal Instruction" and on a second attempt "Unaligned 
> Memory Access" was encountered...

Most likely because the block numbers reported back by the software RAID don't 
map to the block numbers on the
physical device which is why the first stage is just loading random garbage and 
executing it which leads to
SIGILL.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: GRUB testers on SPARC needed

2021-05-17 Thread John Paul Adrian Glaubitz

Hi Robin!

On 5/15/21 7:25 PM, Robin Cremer wrote:
>> 7. Report back to the list and include your hardware and partition setup
> 
> A bit late to the party, as SILO already appears to be gone (including the 
> repos) and
> all install images use GRUB now, but I'm having trouble and wanted to report 
> this - and
> maybe get some ideas, in case this is the best address to do so:

You can still install SILO from snapshot.debian.org. However, I would recommend 
building
the latest version from source as there have been some bugfixes in the meantime.

> I'm in the process of migrating most of our SPARC servers running Solaris 10 
> & the old Debian
> with 32bit SPARC userland to the SPARC64 debport. Some servers running 
> Solaris 11 will follow.

Good to hear.

> Installing on two SunFire v215 went reasonably well
> 
> /- (apart from recurring Kernel Panics with "Unable to handle kernel paging 
> request in mna handler",
> most often triggered on boot immediately after the systemd binfmt service 
> tries to start. This seems
> to have been mentioned in /2020/04/msg00020.html but never pinpointed and 
> fixed?) -/

What kernel version are you running. There have actually been some fixes in 
this regard, in particular
this fix:

> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/sparc?id=e5e8b80d352ec999d2bba3ea584f541c83f4ca3f

> but I can't seem to be able to configure GRUB on these servers as I did in 
> the past with SILO (a 2-disk
> mdraid with mirrored /boot, / and swap). I'm currently stuck with /boot on 
> only one disk and the rest of
> the system mirrored as I can't figure out how to install grub for a mirrored 
> /boot partition:

Please keep in mind that GRUB is installed using blocklists on these older 
machines which means it's not
aware of the filesystem being used. The bootloader will just remember the 
location of the data blocks
and the physical disk. So it has no means to deal with something sophisticated 
as a software RAID.

Not sure how it worked with SILO which didn't use anything else than blocklists 
either (which is why
the /boot partition couldn't be too large and the filesystem used couldn't be 
too fancy).

> 1) Installing to the mirror device always yields a Segmentation Fault. I was 
> unable to get any clue with
> my limited gdb experience as to why - (with loaded debug symbols etc.: 
> "Backtrace stopped: previous frame
> identical to this frame (corrupt stack?)"):
>> # grub-install --skip-fs-probe --force --debug /dev/md0
>> [...]
>> grub-install: info: setting the root device to 
>> `mduuid/1ae243c1e2445aef777f4d32b671f41c'.
>> grub-install: warning: File system `ext2' doesn't support embedding.
>> grub-install: warning: Embedding is not possible.  GRUB can only be 
>> installed in this setup by using blocklists.  However, blocklists are 
>> UNRELIABLE and their use is discouraged..
>> grub-install: info: will leave the core image on the filesystem.
>> Segmentation fault

As I said above, I don't expect this to work, really. That doesn't mean that 
grub-install should crash
here. I will try to reproduce the issue when I find some time. Ideally, 
grub-install should just abort
the installation in this case.

But we could also find out how SILO worked in this case.

> 2) Trying to install to the individual disk partitions or the raw disk itself:
>> grub-install: warning: File system `ext2' doesn't support embedding.
>> grub-install: error: embedding is not possible, but this is required for 
>> RAID and LVM install.
> [...]
>> grub-install: warning: Partition style `sun' doesn't support embedding.
>> grub-install: error: embedding is not possible, but this is required for 
>> RAID and LVM install.
> 
> Neither different filesystems (ext2, xfs, ...) nor different mdraid metadata 
> formats made any difference.
> I can't test other disk labels, as the old OBP doesn't handle GPT AFAIR.
> Also, GRUB built from the most recent official sources from their git 
> segfaults as well.

Thanks for testing the git version, I was about to ask that.

> Any pointers how to achieve this setup? What can I test or does someone else 
> have a similar setup
> working? Am I doing something horribly wrong? I don't think mdraid-mirrored 
> bootdisks should be too
> uncommon on this hardware.

>From my statements above, I wouldn't expect GRUB with blocklists to work on a 
>software RAID, so I
think you probably have no choice but to use a single disk for booting. In any 
case, I think the
the GRUB-specific discussion should be moved to the GRUB mailing list as this 
really concerns the
low-level functionality of GRUB.

> Thanks and cheers to the community keeping SPARC alive :-)

Sure. Glad it's being useful.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: GRUB testers on SPARC needed

2021-05-15 Thread Robin Cremer


Responding to myself:

Some progress:
I put additional informational output between all commands in the 
suspect area in GRUBs util/setup.c and pinpointed the bug:



#ifdef GRUB_SETUP_SPARC64
  {
    grub_partition_t container = root_dev->disk->partition;

    if (grub_strstr (container->partmap->name, "gpt"))
  bl.gpt_offset = grub_partition_get_start (container);
  }
#endif


When installing on an md-device - or other special devices - it will 
never have a partition table, thus "container" is null.
After that, access to struct members is tried without checking if it 
even exists, leading to the segfault.

if (container && grub_strstr (container->partmap->name, "gpt"))
actually works & installs on LVM if I put a hint for GRUB into the 
device.map pointing to the UUID of the MDRAID.


I'll try to get a patch for that submitted or discussed (I'm new to this 
and not exactly sure if the change has other implications).



It still won't boot, though. The first "stage" in the 2nd partition 
block is executed by OBP and something along the lines of "GRUB FAIL - 
trap: Illegal Instruction" and on a second attempt "Unaligned Memory 
Access" was encountered...



I'll post back,

Greetings,
Robin

Re: GRUB testers on SPARC needed

2021-05-15 Thread Robin Cremer


Hi,

We're in the process of migrating Debian for sparc64 from SILO to GRUB
as GRUB upstream is adding support for modern SPARC machines thanks to
the work of Eric Snowberg from Oracle.

In order to make sure GRUB works on all machines supported by the sparc64
port, we need your help to test GRUB on your particular hardware, the older
your machine, the better.
[...]

7. Report back to the list and include your hardware and partition setup


A bit late to the party, as SILO already appears to be gone (including 
the repos) and all install images use GRUB now, but I'm having trouble 
and wanted to report this - and maybe get some ideas, in case this is 
the best address to do so:


I'm in the process of migrating most of our SPARC servers running 
Solaris 10 & the old Debian with 32bit SPARC userland to the SPARC64 
debport.

Some servers running Solaris 11 will follow.

Installing on two SunFire v215 went reasonably well

/- (apart from recurring Kernel Panics with "Unable to handle kernel 
paging request in mna handler", most often triggered on boot immediately 
after the systemd binfmt service tries to start. This seems to have been 
mentioned in /2020/04/msg00020.html but never pinpointed and fixed?) -/


but I can't seem to be able to configure GRUB on these servers as I did 
in the past with SILO (a 2-disk mdraid with mirrored /boot, / and swap).
I'm currently stuck with /boot on only one disk and the rest of the 
system mirrored as I can't figure out how to install grub for a mirrored 
/boot partition:


1) Installing to the mirror device always yields a Segmentation Fault. I 
was unable to get any clue with my limited gdb experience as to why - 
(with loaded debug symbols etc.: "Backtrace stopped: previous frame 
identical to this frame (corrupt stack?)"):

# grub-install --skip-fs-probe --force --debug /dev/md0
[...]
grub-install: info: setting the root device to 
`mduuid/1ae243c1e2445aef777f4d32b671f41c'.

grub-install: warning: File system `ext2' doesn't support embedding.
grub-install: warning: Embedding is not possible.  GRUB can only be 
installed in this setup by using blocklists.  However, blocklists are 
UNRELIABLE and their use is discouraged..

grub-install: info: will leave the core image on the filesystem.
Segmentation fault


2) Trying to install to the individual disk partitions or the raw disk 
itself:

grub-install: warning: File system `ext2' doesn't support embedding.
grub-install: error: embedding is not possible, but this is required 
for RAID and LVM install.

[...]

grub-install: warning: Partition style `sun' doesn't support embedding.
grub-install: error: embedding is not possible, but this is required 
for RAID and LVM install.


Neither different filesystems (ext2, xfs, ...) nor different mdraid 
metadata formats made any difference.

I can't test other disk labels, as the old OBP doesn't handle GPT AFAIR.
Also, GRUB built from the most recent official sources from their git 
segfaults as well.


Any pointers how to achieve this setup? What can I test or does someone 
else have a similar setup working? Am I doing something horribly wrong?
I don't think mdraid-mirrored bootdisks should be too uncommon on this 
hardware.


Thanks and cheers to the community keeping SPARC alive :-)
Robin

Re: update-grub and then grub-mkconfig leads to the watchdog: BUG: soft lockup

2021-03-15 Thread Dennis Clarke

On 3/15/21 9:38 AM, John Paul Adrian Glaubitz wrote:
> Hello!
> 
> On 3/15/21 10:34 AM, Anatoly Pugachev wrote:
>>> + /usr/sbin/grub-probe --target=device /
>>> + GRUB_DEVICE=/dev/sda2
>>> + /usr/sbin/grub-probe --device /dev/sda2 --target=fs_uuid
>>> [ 1330.951329] watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
>>> [grub-probe:443]
>>> [ 1331.046350] Modules linked in: drm(E) drm_panel_orientation_quirks(E)
>>> i2c_core(E) sg(E) envctrl(E) display7seg(E) flash(E) fuse(E) configfs(E)
>>> ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E)
>>> crc32c_generic(E) sd_mod(E) t10_pi(E) crc_t10dif(E) st(E)
>>> crct10dif_generic(E) crct10dif_common(E) sym53c8xx(E)
>>> scsi_transport_spi(E) scsi_mod(E) sunhme(E)
>>> [ 1331.475596] CPU: 0 PID: 443 Comm: grub-probe Tainted: GE
>>> 5.10.0-4-sparc64 #1 Debian 5.10.19-1
>>> [ 1331.606055] TSTATE: 009911001601 TPC: 00950920 TNPC:
>>> 00950924 Y: Tainted: GE
>>> [ 1331.753728] TPC: 
>>> [ 1331.804124] g0: f800065e3140 g1: 1005a830 g2:
>>>  g3: 0149fa90
>>> [ 1331.918504] g4: f80009bde780 g5: 604a4edc g6:
>>> f8000a1ac000 g7: 0fa664c8
>>> [ 1332.032984] o0: 00f2c960 o1: f8000a1af8ec o2:
>>> f80004275b50 o3: 
>>> [ 1332.147464] o4:  o5:  sp:
>>> f8000a1aef81 ret_pc: 00950900
>>> [ 1332.266539] RPC: 
>>> [ 1332.316950] l0: 00f2c800 l1:  l2:
>>> 00668200 l3: 00064b73605f
>>> [ 1332.431439] l4: 0002 l5: f8000a1af8f0 l6:
>>> 00e1a000 l7: 0001
>>> [ 1332.545917] i0: f8000b813d90 i1: f80009bad100 i2:
>>> 00f2c800 i3: 00f2c978
>>> [ 1332.660398] i4: 00ec i5: 1005a818 i6:
>>> f8000a1af031 i7: 00668e38
>>> [ 1332.774892] I7: 
>>> [ 1332.826436] Call Trace:
>>> [ 1332.858473] [<00668e38>] chrdev_open+0x98/0x1e0
>>> [ 1332.927215] [<0065e430>] do_dentry_open+0x170/0x420
>>> [ 1333.000505] [<00660068>] vfs_open+0x28/0x40
>>> [ 1333.064670] [<00674948>] path_openat+0x988/0x1100
>>> [ 1333.135679] [<006773d0>] do_filp_open+0x50/0x100
>>> [ 1333.205549] [<00660330>] do_sys_openat2+0x70/0x180
>>> [ 1333.277710] [<00660868>] sys_openat+0x48/0xc0
>>> [ 1333.344164] [<00406174>] linux_sparc_syscall+0x34/0x44
>>> ~
>>> Type  'go' to resume
>>> ok
>>
>>
>> This kernel OOPS (backtrace) should be reported to sparclinux@ ,
>> linux-kernel@ (lkml) and linux-fsdevel@ (vfs) linux kernel mailing
>> lists.
> 
> It should be verified that this issue is 100% reproducible using the upstream
> kernel. If, yes, Dennis should bisect the problem to find which commit intro-
> duced the problem.
> 
> Anything else won't really get us any further.
> 

yup.

This will take a pile of time.


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Re: update-grub and then grub-mkconfig leads to the watchdog: BUG: soft lockup

2021-03-15 Thread John Paul Adrian Glaubitz

Hello!

On 3/15/21 10:34 AM, Anatoly Pugachev wrote:
>> + /usr/sbin/grub-probe --target=device /
>> + GRUB_DEVICE=/dev/sda2
>> + /usr/sbin/grub-probe --device /dev/sda2 --target=fs_uuid
>> [ 1330.951329] watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
>> [grub-probe:443]
>> [ 1331.046350] Modules linked in: drm(E) drm_panel_orientation_quirks(E)
>> i2c_core(E) sg(E) envctrl(E) display7seg(E) flash(E) fuse(E) configfs(E)
>> ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E)
>> crc32c_generic(E) sd_mod(E) t10_pi(E) crc_t10dif(E) st(E)
>> crct10dif_generic(E) crct10dif_common(E) sym53c8xx(E)
>> scsi_transport_spi(E) scsi_mod(E) sunhme(E)
>> [ 1331.475596] CPU: 0 PID: 443 Comm: grub-probe Tainted: GE
>> 5.10.0-4-sparc64 #1 Debian 5.10.19-1
>> [ 1331.606055] TSTATE: 009911001601 TPC: 00950920 TNPC:
>> 00950924 Y: Tainted: GE
>> [ 1331.753728] TPC: 
>> [ 1331.804124] g0: f800065e3140 g1: 1005a830 g2:
>>  g3: 0149fa90
>> [ 1331.918504] g4: f80009bde780 g5: 604a4edc g6:
>> f8000a1ac000 g7: 0fa664c8
>> [ 1332.032984] o0: 00f2c960 o1: f8000a1af8ec o2:
>> f80004275b50 o3: 
>> [ 1332.147464] o4:  o5:  sp:
>> f8000a1aef81 ret_pc: 00950900
>> [ 1332.266539] RPC: 
>> [ 1332.316950] l0: 00f2c800 l1:  l2:
>> 00668200 l3: 00064b73605f
>> [ 1332.431439] l4: 0002 l5: f8000a1af8f0 l6:
>> 00e1a000 l7: 0001
>> [ 1332.545917] i0: f8000b813d90 i1: f80009bad100 i2:
>> 00f2c800 i3: 00f2c978
>> [ 1332.660398] i4: 00ec i5: 1005a818 i6:
>> f8000a1af031 i7: 00668e38
>> [ 1332.774892] I7: 
>> [ 1332.826436] Call Trace:
>> [ 1332.858473] [<00668e38>] chrdev_open+0x98/0x1e0
>> [ 1332.927215] [<0065e430>] do_dentry_open+0x170/0x420
>> [ 1333.000505] [<00660068>] vfs_open+0x28/0x40
>> [ 1333.064670] [<00674948>] path_openat+0x988/0x1100
>> [ 1333.135679] [<006773d0>] do_filp_open+0x50/0x100
>> [ 1333.205549] [<00660330>] do_sys_openat2+0x70/0x180
>> [ 1333.277710] [<00660868>] sys_openat+0x48/0xc0
>> [ 1333.344164] [<00406174>] linux_sparc_syscall+0x34/0x44
>> ~
>> Type  'go' to resume
>> ok
> 
> 
> This kernel OOPS (backtrace) should be reported to sparclinux@ ,
> linux-kernel@ (lkml) and linux-fsdevel@ (vfs) linux kernel mailing
> lists.

It should be verified that this issue is 100% reproducible using the upstream
kernel. If, yes, Dennis should bisect the problem to find which commit intro-
duced the problem.

Anything else won't really get us any further.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: update-grub and then grub-mkconfig leads to the watchdog: BUG: soft lockup

2021-03-15 Thread Anatoly Pugachev

On Mon, Mar 15, 2021 at 4:59 AM Dennis Clarke  wrote:
>
>
> While digging around here I saw that update-grub will lead to a lockup
> every time. So I simply changed  /usr/sbin/grub-mkconfig  script to
> allow me to see everything that happens.
>
> That gets me to :
>
>  /usr/sbin/grub-probe --device /dev/sda2 --target=fs_uuid
>
> which falls to pieces perfectly :
>
> root@eros:~#
> root@eros:~# uptime
>  01:09:40 up 20 min,  2 users,  load average: 0.07, 0.14, 0.48
> root@eros:~# /usr/sbin/grub-mkconfig -o /boot/grub/grub.cfg
> + prefix=/usr
> + exec_prefix=/usr
> + datarootdir=/usr/share
> + prefix=/usr
> + exec_prefix=/usr
> + sbindir=/usr/sbin
> + bindir=/usr/bin
> + sysconfdir=/etc
> + PACKAGE_NAME=GRUB
> + PACKAGE_VERSION=2.04-16
> + host_os=linux-gnu
> + datadir=/usr/share
> + [ x = x ]
> + pkgdatadir=/usr/share/grub
> + export pkgdatadir
> + grub_cfg=
> + grub_mkconfig_dir=/etc/grub.d
> + basename /usr/sbin/grub-mkconfig
> + self=grub-mkconfig
> + grub_probe=/usr/sbin/grub-probe
> + grub_file=/usr/bin/grub-file
> + grub_editenv=/usr/bin/grub-editenv
> + grub_script_check=/usr/bin/grub-script-check
> + export TEXTDOMAIN=grub
> + export TEXTDOMAINDIR=/usr/share/locale
> + . /usr/share/grub/grub-mkconfig_lib
> + prefix=/usr
> + exec_prefix=/usr
> + datarootdir=/usr/share
> + datadir=/usr/share
> + bindir=/usr/bin
> + sbindir=/usr/sbin
> + [ x/usr/share/grub = x ]
> + test x/usr/sbin/grub-probe = x
> + test x/usr/bin/grub-file = x
> + test x = x
> + grub_mkrelpath=/usr/bin/grub-mkrelpath
> + which gettext
> + :
> + grub_tab=
> + test 2 -gt 0
> + option=-o
> + shift
> + argument -o /boot/grub/grub.cfg
> + opt=-o
> + shift
> + test 1 -eq 0
> + echo /boot/grub/grub.cfg
> + grub_cfg=/boot/grub/grub.cfg
> + shift
> + test 0 -gt 0
> + [ x = x ]
> + id -u
> + EUID=0
> + [ 0 != 0 ]
> + set /usr/sbin/grub-probe dummy
> + test -f /usr/sbin/grub-probe
> + :
> + /usr/sbin/grub-probe --target=device /
> + GRUB_DEVICE=/dev/sda2
> + /usr/sbin/grub-probe --device /dev/sda2 --target=fs_uuid
> [ 1330.951329] watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
> [grub-probe:443]
> [ 1331.046350] Modules linked in: drm(E) drm_panel_orientation_quirks(E)
> i2c_core(E) sg(E) envctrl(E) display7seg(E) flash(E) fuse(E) configfs(E)
> ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E)
> crc32c_generic(E) sd_mod(E) t10_pi(E) crc_t10dif(E) st(E)
> crct10dif_generic(E) crct10dif_common(E) sym53c8xx(E)
> scsi_transport_spi(E) scsi_mod(E) sunhme(E)
> [ 1331.475596] CPU: 0 PID: 443 Comm: grub-probe Tainted: GE
> 5.10.0-4-sparc64 #1 Debian 5.10.19-1
> [ 1331.606055] TSTATE: 009911001601 TPC: 00950920 TNPC:
> 00950924 Y: Tainted: GE
> [ 1331.753728] TPC: 
> [ 1331.804124] g0: f800065e3140 g1: 1005a830 g2:
>  g3: 0149fa90
> [ 1331.918504] g4: f80009bde780 g5: 604a4edc g6:
> f8000a1ac000 g7: 0fa664c8
> [ 1332.032984] o0: 00f2c960 o1: f8000a1af8ec o2:
> f80004275b50 o3: 
> [ 1332.147464] o4:  o5:  sp:
> f8000a1aef81 ret_pc: 00950900
> [ 1332.266539] RPC: 
> [ 1332.316950] l0: 00f2c800 l1:  l2:
> 00668200 l3: 00064b73605f
> [ 1332.431439] l4: 0002 l5: f8000a1af8f0 l6:
> 00e1a000 l7: 0001
> [ 1332.545917] i0: f8000b813d90 i1: f80009bad100 i2:
> 00f2c800 i3: 00f2c978
> [ 1332.660398] i4: 00ec i5: 1005a818 i6:
> f8000a1af031 i7: 00668e38
> [ 1332.774892] I7: 
> [ 1332.826436] Call Trace:
> [ 1332.858473] [<00668e38>] chrdev_open+0x98/0x1e0
> [ 1332.927215] [<0065e430>] do_dentry_open+0x170/0x420
> [ 1333.000505] [<00660068>] vfs_open+0x28/0x40
> [ 1333.064670] [<00674948>] path_openat+0x988/0x1100
> [ 1333.135679] [<006773d0>] do_filp_open+0x50/0x100
> [ 1333.205549] [<00660330>] do_sys_openat2+0x70/0x180
> [ 1333.277710] [<00660868>] sys_openat+0x48/0xc0
> [ 1333.344164] [<00406174>] linux_sparc_syscall+0x34/0x44
> ~
> Type  'go' to resume
> ok


This kernel OOPS (backtrace) should be reported to sparclinux@ ,
linux-kernel@ (lkml) and linux-fsdevel@ (vfs) linux kernel mailing
lists.
Thanks.

update-grub and then grub-mkconfig leads to the watchdog: BUG: soft lockup

2021-03-14 Thread Dennis Clarke



While digging around here I saw that update-grub will lead to a lockup
every time. So I simply changed  /usr/sbin/grub-mkconfig  script to
allow me to see everything that happens.

That gets me to :

 /usr/sbin/grub-probe --device /dev/sda2 --target=fs_uuid

which falls to pieces perfectly :

root@eros:~#
root@eros:~# uptime
 01:09:40 up 20 min,  2 users,  load average: 0.07, 0.14, 0.48
root@eros:~# /usr/sbin/grub-mkconfig -o /boot/grub/grub.cfg
+ prefix=/usr
+ exec_prefix=/usr
+ datarootdir=/usr/share
+ prefix=/usr
+ exec_prefix=/usr
+ sbindir=/usr/sbin
+ bindir=/usr/bin
+ sysconfdir=/etc
+ PACKAGE_NAME=GRUB
+ PACKAGE_VERSION=2.04-16
+ host_os=linux-gnu
+ datadir=/usr/share
+ [ x = x ]
+ pkgdatadir=/usr/share/grub
+ export pkgdatadir
+ grub_cfg=
+ grub_mkconfig_dir=/etc/grub.d
+ basename /usr/sbin/grub-mkconfig
+ self=grub-mkconfig
+ grub_probe=/usr/sbin/grub-probe
+ grub_file=/usr/bin/grub-file
+ grub_editenv=/usr/bin/grub-editenv
+ grub_script_check=/usr/bin/grub-script-check
+ export TEXTDOMAIN=grub
+ export TEXTDOMAINDIR=/usr/share/locale
+ . /usr/share/grub/grub-mkconfig_lib
+ prefix=/usr
+ exec_prefix=/usr
+ datarootdir=/usr/share
+ datadir=/usr/share
+ bindir=/usr/bin
+ sbindir=/usr/sbin
+ [ x/usr/share/grub = x ]
+ test x/usr/sbin/grub-probe = x
+ test x/usr/bin/grub-file = x
+ test x = x
+ grub_mkrelpath=/usr/bin/grub-mkrelpath
+ which gettext
+ :
+ grub_tab=
+ test 2 -gt 0
+ option=-o
+ shift
+ argument -o /boot/grub/grub.cfg
+ opt=-o
+ shift
+ test 1 -eq 0
+ echo /boot/grub/grub.cfg
+ grub_cfg=/boot/grub/grub.cfg
+ shift
+ test 0 -gt 0
+ [ x = x ]
+ id -u
+ EUID=0
+ [ 0 != 0 ]
+ set /usr/sbin/grub-probe dummy
+ test -f /usr/sbin/grub-probe
+ :
+ /usr/sbin/grub-probe --target=device /
+ GRUB_DEVICE=/dev/sda2
+ /usr/sbin/grub-probe --device /dev/sda2 --target=fs_uuid
[ 1330.951329] watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
[grub-probe:443]
[ 1331.046350] Modules linked in: drm(E) drm_panel_orientation_quirks(E)
i2c_core(E) sg(E) envctrl(E) display7seg(E) flash(E) fuse(E) configfs(E)
ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E)
crc32c_generic(E) sd_mod(E) t10_pi(E) crc_t10dif(E) st(E)
crct10dif_generic(E) crct10dif_common(E) sym53c8xx(E)
scsi_transport_spi(E) scsi_mod(E) sunhme(E)
[ 1331.475596] CPU: 0 PID: 443 Comm: grub-probe Tainted: GE
5.10.0-4-sparc64 #1 Debian 5.10.19-1
[ 1331.606055] TSTATE: 009911001601 TPC: 00950920 TNPC:
00950924 Y: Tainted: GE
[ 1331.753728] TPC: 
[ 1331.804124] g0: f800065e3140 g1: 1005a830 g2:
 g3: 0149fa90
[ 1331.918504] g4: f80009bde780 g5: 604a4edc g6:
f8000a1ac000 g7: 0fa664c8
[ 1332.032984] o0: 00f2c960 o1: f8000a1af8ec o2:
f80004275b50 o3: 
[ 1332.147464] o4:  o5:  sp:
f8000a1aef81 ret_pc: 00950900
[ 1332.266539] RPC: 
[ 1332.316950] l0: 00f2c800 l1:  l2:
00668200 l3: 00064b73605f
[ 1332.431439] l4: 0002 l5: f8000a1af8f0 l6:
00e1a000 l7: 0001
[ 1332.545917] i0: f8000b813d90 i1: f80009bad100 i2:
00f2c800 i3: 00f2c978
[ 1332.660398] i4: 00ec i5: 1005a818 i6:
f8000a1af031 i7: 00668e38
[ 1332.774892] I7: 
[ 1332.826436] Call Trace:
[ 1332.858473] [<00668e38>] chrdev_open+0x98/0x1e0
[ 1332.927215] [<0065e430>] do_dentry_open+0x170/0x420
[ 1333.000505] [<00660068>] vfs_open+0x28/0x40
[ 1333.064670] [<00674948>] path_openat+0x988/0x1100
[ 1333.135679] [<006773d0>] do_filp_open+0x50/0x100
[ 1333.205549] [<00660330>] do_sys_openat2+0x70/0x180
[ 1333.277710] [<00660868>] sys_openat+0x48/0xc0
[ 1333.344164] [<00406174>] linux_sparc_syscall+0x34/0x44
~
Type  'go' to resume
ok

If I could install gdb then perhaps ... maybe ... I can see what is
happening here.  However that will have to wait until tomorrow or
so :

eros# apt-get install gdb
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 gdb : Depends: libpython3.8 (>= 3.8.2) but it is not installable
   Recommends: libc-dbg
E: Unable to correct problems, you have held broken packages.
eros#

I would compile my own grub-probe but at the moment I can not get a
compiler installed.  So I will look into this tomorrow.


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Re: update-grub causes a system lockup

2021-01-19 Thread John Paul Adrian Glaubitz

Hi Dennis!

On 1/12/21 5:58 PM, Dennis Clarke wrote:
> I was thinking that the architecture may be the issue. The age I mean.
> So I dragged out a newer Oracle T4 unit to try. I have no idea what will
> happen with the newer unit and have never tried to run the installer via
> the new SP/console serial interface but will give it a try.

There are known issues with older CPUs which are a bug in the kernel.

However, currently I don't know how to reproduce the crash. If you have 
something
the reproducibly causes the kernel to crash on the old SPARC CPUs that I can 
use,
it would be very helpful for fixing the problem.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: update-grub causes a system lockup

2021-01-12 Thread John Paul Adrian Glaubitz

On 1/12/21 6:18 PM, John Paul Adrian Glaubitz wrote:
> If you could fine a reliable reproducer to trigger the crash, I can later use
> that to bisect the problem to find which particular commit introduced the
> regression.
> 
> So, if you want to help with the SPARC port, this would be an excellent 
> opportunity.

Alternatively, could you just send me your grub.conf which causes the crash when
running update-grub?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: update-grub causes a system lockup

2021-01-12 Thread John Paul Adrian Glaubitz

On 1/12/21 5:58 PM, Dennis Clarke wrote:
>> Either way, it's good to have something which allows to reproduce the bug.
>>
> 
> I was thinking that the architecture may be the issue. The age I mean.
> So I dragged out a newer Oracle T4 unit to try. I have no idea what will
> happen with the newer unit and have never tried to run the installer via
> the new SP/console serial interface but will give it a try.

There are known issues with kernel stability on older SPARC CPUs which have
not been resolved yet.

If you could fine a reliable reproducer to trigger the crash, I can later use
that to bisect the problem to find which particular commit introduced the
regression.

So, if you want to help with the SPARC port, this would be an excellent 
opportunity.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: update-grub causes a system lockup

2021-01-12 Thread Dennis Clarke

On 1/12/21 12:47 AM, John Paul Adrian Glaubitz wrote:
> On 1/12/21 1:39 AM, Dennis Clarke wrote:
>>
>> I made a few minor edits to /etc/default/grub and then :
>>
>> root@ceres:~# update-grub
>> [  303.211729] watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
>> [grub-probe:261]
>> [  303.306793] Modules linked in: sg(E) envctrl(E) display7seg(E)
>> flash(E) fuse(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E)
>> crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sd_mod(E) t10_pi(E)
>> crc_t10dif(E) crct10dif_generic(E) crct10dif_common(E) ata_generic(E)
>> pata_cmd64x(E) sym53c8xx(E) libata(E) scsi_transport_spi(E) scsi_mod(E)
>> sunhme(E)
>> (...)
>> Also this has been happening for months.
> 
> I would suggest installing a 4.x kernel and see if that helps. I know that
> 5.x kernels can be a bit unstable on certain older SPARC machines.
> 
> If the issue goes away with an older kernel, try bisecting to find the commit
> that introduced the issue.
> 
> Either way, it's good to have something which allows to reproduce the bug.
> 

I was thinking that the architecture may be the issue. The age I mean.
So I dragged out a newer Oracle T4 unit to try. I have no idea what will
happen with the newer unit and have never tried to run the installer via
the new SP/console serial interface but will give it a try.

Dennis

Re: update-grub causes a system lockup

2021-01-11 Thread John Paul Adrian Glaubitz

On 1/12/21 1:39 AM, Dennis Clarke wrote:
> 
> I made a few minor edits to /etc/default/grub and then :
> 
> root@ceres:~# update-grub
> [  303.211729] watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
> [grub-probe:261]
> [  303.306793] Modules linked in: sg(E) envctrl(E) display7seg(E)
> flash(E) fuse(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E)
> crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sd_mod(E) t10_pi(E)
> crc_t10dif(E) crct10dif_generic(E) crct10dif_common(E) ata_generic(E)
> pata_cmd64x(E) sym53c8xx(E) libata(E) scsi_transport_spi(E) scsi_mod(E)
> sunhme(E)
> (...)
> Also this has been happening for months.

I would suggest installing a 4.x kernel and see if that helps. I know that
5.x kernels can be a bit unstable on certain older SPARC machines.

If the issue goes away with an older kernel, try bisecting to find the commit
that introduced the issue.

Either way, it's good to have something which allows to reproduce the bug.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

update-grub causes a system lockup

2021-01-11 Thread Dennis Clarke



I made a few minor edits to /etc/default/grub and then :

root@ceres:~# update-grub
[  303.211729] watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
[grub-probe:261]
[  303.306793] Modules linked in: sg(E) envctrl(E) display7seg(E)
flash(E) fuse(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E)
crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sd_mod(E) t10_pi(E)
crc_t10dif(E) crct10dif_generic(E) crct10dif_common(E) ata_generic(E)
pata_cmd64x(E) sym53c8xx(E) libata(E) scsi_transport_spi(E) scsi_mod(E)
sunhme(E)
[  303.716582] CPU: 0 PID: 261 Comm: grub-probe Tainted: GE
5.10.0-1-sparc64 #1 Debian 5.10.5-1
[  303.845889] TSTATE: 11001606 TPC: 0094c4f0 TNPC:
0094c4f4 Y: Tainted: GE
[  303.993559] TPC: 
[  304.043951] g0: f800068f5ec0 g1: 0098 g2:
 g3: 0196df50
[  304.158439] g4: f8000ac388a0 g5: 5ff099f6 g6:
f8000b6fc000 g7: 0ef10180
[  304.272918] o0: 00f24960 o1: f8000b6ff8ec o2:
f800042833d0 o3: 
[  304.387399] o4:  o5:  sp:
f8000b6fef81 ret_pc: 0094c4c0
[  304.506456] RPC: 
[  304.556875] l0: 00f24800 l1:  l2:
00664c00 l3: 000661c58e90
[  304.671360] l4: 0002 l5: f8000b6ff8f0 l6:
00e12000 l7: 0001
[  304.785838] i0: f8000ad93048 i1: f8000b47b600 i2:
00f24800 i3: 00f24978
[  304.900318] i4: 00ec i5: 10076818 i6:
f8000b6ff031 i7: 00665838
[  305.014814] I7: 
[  305.066356] Call Trace:
[  305.098501] [<00665838>] chrdev_open+0x98/0x1e0
[  305.167245] [<0065ae30>] do_dentry_open+0x170/0x420
[  305.240529] [<0065ca68>] vfs_open+0x28/0x40
[  305.304691] [<00671348>] path_openat+0x988/0x1100
[  305.375707] [<00673dd0>] do_filp_open+0x50/0x100
[  305.445573] [<0065cd30>] do_sys_openat2+0x70/0x180
[  305.517732] [<0065d268>] sys_openat+0x48/0xc0
[  305.584186] [<00406174>] linux_sparc_syscall+0x34/0x44
~

At this point I have to signal a break to the console.

I am not yet sure exactly which binary causes this problem but I
am going with a wild guess that somewhere in /usr/sbin/grub-mkconfig
we end up with a show stopping fault.  I am walking through it line
by line and trying to find the culprit.

Also this has been happening for months.



-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Re: grub-installer: info: Calling 'apt-install grub-ieee1275' failed

2021-01-11 Thread John Paul Adrian Glaubitz

Hello!

On 1/11/21 2:53 PM, Dennis Clarke wrote:
> I am doing a re-install with the "default" installer and I choose the
> most trivial config options. Which is to say the partition options were
> whatever seems most trivial. Full disk. New partition table. Everything
> in one partition.  The default seems to be 512MB ext2 bootable /boot and
> then a large slice and 1G of swap.
> 
> Eventually I see a big red box :
> 
> [!!] Configure the package manager
> apt configuration problem
> An attempt to configure apt to install additional packages from the
> media failed.
> 
> Here I select "continue" and things seem to move along.

You should have checked what's in the log in the other terminal so you know
the actual problem was.

> I guess there is something oddball in the expert level menu option but
> we don't really test for that. OKay, this works in the easy mode option.

I alone simply don't have the capacity to test (and fix!) all possible
paths in the installer.

If you run into such problem, try to reproduce it with a daily snapshot
of the installer on one of the officially supported architectures and
then file a bug against debian-installer.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: grub-installer: info: Calling 'apt-install grub-ieee1275' failed

2021-01-11 Thread Dennis Clarke

On 1/9/21 1:12 AM, John Paul Adrian Glaubitz wrote:
> On 1/9/21 1:53 AM, Dennis Clarke wrote:
>>
>> I think this is pretty much well known but I will report it here
>> regardless. From the latest sparc64 installer images I eventually
>> see grub-ieee1275 fails.
>> (...)
>> Jan  4 19:00:02 in-target: Get:1 http://deb.debian.org/debian-ports
>> sid/main sparc64 grub2-common sparc64 2.04-11 [719 kB]
>> Jan  4 19:00:04 in-target: Err:2 http://deb.debian.org/debian-ports
>> sid/main sparc64 grub-ieee1275-bin sparc64 2.04-11
>> Jan  4 19:00:04 in-target:   503  Backend unavailable, connection
>> timeout [IP: 2a04:4e42:58::644 80]
>> Jan  4 19:00:04 in-target: Get:3 http://deb.debian.org/debian-ports
>> sid/main sparc64 grub-ieee1275 sparc64 2.04-11 [542 kB]
>> Jan  4 19:00:05 in-target: Fetched 1261 kB in 4s (316 kB/s)
>> Jan  4 19:00:05 in-target: E
>> Jan  4 19:00:05 in-target: :
>> Jan  4 19:00:05 in-target: Failed to fetch
>> http://deb.debian.org/debian-ports/pool-sparc64/main/g/grub2/grub-ieee1275-bin_2.04-11_sparc64.deb
>>  503  Backend unavailable, connection timeout [IP: 2a04:4e42:58::644 80]
>> Jan  4 19:00:05 in-target:
>> Jan  4 19:00:05 in-target: E
>> Jan  4 19:00:05 in-target: :
>> Jan  4 19:00:05 in-target: Unable to fetch some archives, maybe run
>> apt-get update or try with --fix-missing?
>> Jan  4 19:00:05 in-target:
>> Jan  4 19:00:05 grub-installer: info: Calling 'apt-install
>> grub-ieee1275' failed
> 
> I have no clue which image you used and I'm not sure what you did to end up 
> in a situation
> where the installer would try to download the grub2 packages over the net 
> which are actually
> on the installation ISO, so they don't have to be downloaded.
> 
> I also just verified that by installing the latest sparc64 ISO inside an LDOM 
> in offline mode
> and grub2 was installed without any issues with no package mirror being set 
> up.


I am doing a re-install with the "default" installer and I choose the
most trivial config options. Which is to say the partition options were
whatever seems most trivial. Full disk. New partition table. Everything
in one partition.  The default seems to be 512MB ext2 bootable /boot and
then a large slice and 1G of swap.

Eventually I see a big red box :

[!!] Configure the package manager
apt configuration problem
An attempt to configure apt to install additional packages from the
media failed.

Here I select "continue" and things seem to move along.

Then, after a little while everything seems to just work neatly.

I guess there is something oddball in the expert level menu option but
we don't really test for that. OKay, this works in the easy mode option.


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Re: grub-installer: info: Calling 'apt-install grub-ieee1275' failed

2021-01-09 Thread John Paul Adrian Glaubitz

On 1/9/21 2:33 PM, Dennis Clarke wrote:
> May be possibly because I always use the "expert mode" option in the
> installer. That allows me to setup the network without DHCP.

Manual networking setup also works in normal mode. It will try DHCP first,
then fail and then offer manual configuration.

> I will try again with the default trivial installer.

Yes, please try to avoid the expert installer. It's an untested code path.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: grub-installer: info: Calling 'apt-install grub-ieee1275' failed

2021-01-09 Thread Dennis Clarke

On 1/9/21 1:12 AM, John Paul Adrian Glaubitz wrote:
> On 1/9/21 1:53 AM, Dennis Clarke wrote:
>>
>> I think this is pretty much well known but I will report it here
>> regardless. From the latest sparc64 installer images I eventually
>> see grub-ieee1275 fails.
>> (...)
>> Jan  4 19:00:02 in-target: Get:1 http://deb.debian.org/debian-ports
>> sid/main sparc64 grub2-common sparc64 2.04-11 [719 kB]
>> Jan  4 19:00:04 in-target: Err:2 http://deb.debian.org/debian-ports
>> sid/main sparc64 grub-ieee1275-bin sparc64 2.04-11
>> Jan  4 19:00:04 in-target:   503  Backend unavailable, connection
>> timeout [IP: 2a04:4e42:58::644 80]
>> Jan  4 19:00:04 in-target: Get:3 http://deb.debian.org/debian-ports
>> sid/main sparc64 grub-ieee1275 sparc64 2.04-11 [542 kB]
>> Jan  4 19:00:05 in-target: Fetched 1261 kB in 4s (316 kB/s)
>> Jan  4 19:00:05 in-target: E
>> Jan  4 19:00:05 in-target: :
>> Jan  4 19:00:05 in-target: Failed to fetch
>> http://deb.debian.org/debian-ports/pool-sparc64/main/g/grub2/grub-ieee1275-bin_2.04-11_sparc64.deb
>>  503  Backend unavailable, connection timeout [IP: 2a04:4e42:58::644 80]
>> Jan  4 19:00:05 in-target:
>> Jan  4 19:00:05 in-target: E
>> Jan  4 19:00:05 in-target: :
>> Jan  4 19:00:05 in-target: Unable to fetch some archives, maybe run
>> apt-get update or try with --fix-missing?
>> Jan  4 19:00:05 in-target:
>> Jan  4 19:00:05 grub-installer: info: Calling 'apt-install
>> grub-ieee1275' failed
> 
> I have no clue which image you used and I'm not sure what you did to end up 
> in a situation
> where the installer would try to download the grub2 packages over the net 
> which are actually
> on the installation ISO, so they don't have to be downloaded.
> 

I used the sparc64 netinst from
https://cdimage.debian.org/cdimage/ports/snapshots/2021-01-03/ and did
veridy the SHA512 hash.

> I also just verified that by installing the latest sparc64 ISO inside an LDOM 
> in offline mode
> and grub2 was installed without any issues with no package mirror being set 
> up.
>


May be possibly because I always use the "expert mode" option in the
installer. That allows me to setup the network without DHCP.

I will try again with the default trivial installer.

Dennis

Re: grub-installer: info: Calling 'apt-install grub-ieee1275' failed

2021-01-09 Thread John Paul Adrian Glaubitz

On 1/9/21 2:03 PM, Gregor Riepl wrote:
> The only situation where I can imagine this would happen is when the
> repositories have a newer version of the package than the installer
> image, and update to the latest version during installation is enabled
> (probably the default).

I have never run into this situation but I know that a lot of users choose
the weirdest configuration settings in debian-installer without understanding
the ramifications and then wonder why it doesn't work.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: grub-installer: info: Calling 'apt-install grub-ieee1275' failed

2021-01-09 Thread Gregor Riepl

> I have no clue which image you used and I'm not sure what you did to end up 
> in a situation
> where the installer would try to download the grub2 packages over the net 
> which are actually
> on the installation ISO, so they don't have to be downloaded.

The only situation where I can imagine this would happen is when the
repositories have a newer version of the package than the installer
image, and update to the latest version during installation is enabled
(probably the default).

Maybe try again, or with a different mirror?
This sounds very much like a temporary issue with the repo, not the
installer:

Jan  4 19:00:04 in-target:   503  Backend unavailable, connection
timeout [IP: 2a04:4e42:58::644 80]

grub-installer: info: Calling 'apt-install grub-ieee1275' failed

2021-01-08 Thread Dennis Clarke



I think this is pretty much well known but I will report it here
regardless. From the latest sparc64 installer images I eventually
see grub-ieee1275 fails.

>From the end of the syslog :

Jan  4 19:00:00 in-target: The following additional packages will be
installed:
Jan  4 19:00:00 in-target:   grub-ieee1275-bin grub2-common
Jan  4 19:00:00 in-target: The following NEW packages will be installed:
Jan  4 19:00:00 in-target:   grub-ieee1275 grub-ieee1275-bin grub2-common
Jan  4 19:00:02 in-target: 0 upgraded, 3 newly installed, 0 to remove
and 0 not upgraded.
Jan  4 19:00:02 in-target: Need to get 2031 kB of archives.
Jan  4 19:00:02 in-target: After this operation, 5943 kB of additional
disk space will be used.
Jan  4 19:00:02 in-target: Get:1 http://deb.debian.org/debian-ports
sid/main sparc64 grub2-common sparc64 2.04-11 [719 kB]
Jan  4 19:00:04 in-target: Err:2 http://deb.debian.org/debian-ports
sid/main sparc64 grub-ieee1275-bin sparc64 2.04-11
Jan  4 19:00:04 in-target:   503  Backend unavailable, connection
timeout [IP: 2a04:4e42:58::644 80]
Jan  4 19:00:04 in-target: Get:3 http://deb.debian.org/debian-ports
sid/main sparc64 grub-ieee1275 sparc64 2.04-11 [542 kB]
Jan  4 19:00:05 in-target: Fetched 1261 kB in 4s (316 kB/s)
Jan  4 19:00:05 in-target: E
Jan  4 19:00:05 in-target: :
Jan  4 19:00:05 in-target: Failed to fetch
http://deb.debian.org/debian-ports/pool-sparc64/main/g/grub2/grub-ieee1275-bin_2.04-11_sparc64.deb
 503  Backend unavailable, connection timeout [IP: 2a04:4e42:58::644 80]
Jan  4 19:00:05 in-target:
Jan  4 19:00:05 in-target: E
Jan  4 19:00:05 in-target: :
Jan  4 19:00:05 in-target: Unable to fetch some archives, maybe run
apt-get update or try with --fix-missing?
Jan  4 19:00:05 in-target:
Jan  4 19:00:05 grub-installer: info: Calling 'apt-install
grub-ieee1275' failed

The entire log is at
https://beta.genunix.com/debian_boot/sparc64/syslog_2021-01-03.txt

I think, for the moment, the ppc64 installer is a higher priority.

-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Re: grub-installer: info: Calling 'apt-install grub-ieee1275' failed

2021-01-08 Thread John Paul Adrian Glaubitz

On 1/9/21 1:53 AM, Dennis Clarke wrote:
> 
> I think this is pretty much well known but I will report it here
> regardless. From the latest sparc64 installer images I eventually
> see grub-ieee1275 fails.
> (...)
> Jan  4 19:00:02 in-target: Get:1 http://deb.debian.org/debian-ports
> sid/main sparc64 grub2-common sparc64 2.04-11 [719 kB]
> Jan  4 19:00:04 in-target: Err:2 http://deb.debian.org/debian-ports
> sid/main sparc64 grub-ieee1275-bin sparc64 2.04-11
> Jan  4 19:00:04 in-target:   503  Backend unavailable, connection
> timeout [IP: 2a04:4e42:58::644 80]
> Jan  4 19:00:04 in-target: Get:3 http://deb.debian.org/debian-ports
> sid/main sparc64 grub-ieee1275 sparc64 2.04-11 [542 kB]
> Jan  4 19:00:05 in-target: Fetched 1261 kB in 4s (316 kB/s)
> Jan  4 19:00:05 in-target: E
> Jan  4 19:00:05 in-target: :
> Jan  4 19:00:05 in-target: Failed to fetch
> http://deb.debian.org/debian-ports/pool-sparc64/main/g/grub2/grub-ieee1275-bin_2.04-11_sparc64.deb
>  503  Backend unavailable, connection timeout [IP: 2a04:4e42:58::644 80]
> Jan  4 19:00:05 in-target:
> Jan  4 19:00:05 in-target: E
> Jan  4 19:00:05 in-target: :
> Jan  4 19:00:05 in-target: Unable to fetch some archives, maybe run
> apt-get update or try with --fix-missing?
> Jan  4 19:00:05 in-target:
> Jan  4 19:00:05 grub-installer: info: Calling 'apt-install
> grub-ieee1275' failed

I have no clue which image you used and I'm not sure what you did to end up in 
a situation
where the installer would try to download the grub2 packages over the net which 
are actually
on the installation ISO, so they don't have to be downloaded.

I also just verified that by installing the latest sparc64 ISO inside an LDOM 
in offline mode
and grub2 was installed without any issues with no package mirror being set up.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: grub-ieee1275 fails to install bootblock

2020-04-24 Thread John Paul Adrian Glaubitz

Hi Alexander!

Could you please retest with the latest ISO image for sparc64 [1] and
check whether this issue has been resolved for you now?

We have fixed a lot of issues around GRUB on sparc64, both upstream and
in Debian and I'm confident that GRUB should work now out of the box
on your UltraSPARC 45.

FWIW, there are currently some issues with 5.x on older UltraSPARC machines
but these should not affect this bug report.

If GRUB works for you on sparc64 after testing the image, please consider
closing this bug report.

Adrian

> [1] 
> https://cdimage.debian.org/cdimage/ports/2020-04-19/debian-10.0-sparc64-NETINST-1.iso

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#610490: grub-ieee1275: runs out of memory on UltraSPARC 10

2020-04-24 Thread John Paul Adrian Glaubitz

Hi Axel!

Could you please retest with the latest ISO image for sparc64 [1] and
check whether this issue has been resolved for you now?

We have fixed a lot of issues around GRUB on sparc64, both upstream and
in Debian and I'm confident that GRUB should work now out of the box
even on your UltraSPARC 10.

FWIW, there are currently some issues with 5.x on older UltraSPARC machines
but these should not affect this bug report.

If GRUB works for you on sparc64 after testing the image, please consider
closing this bug report.

Adrian

> [1] 
> https://cdimage.debian.org/cdimage/ports/2020-04-19/debian-10.0-sparc64-NETINST-1.iso

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Issues with GRUB 2.04 from experimental with GPT labels

2019-07-08 Thread John Paul Adrian Glaubitz

On 7/8/19 2:33 PM, John Paul Adrian Glaubitz wrote:
> The issues shows as follows:
> 
> Loading Linux 5.2.0 ...
> Loading initial ramdisk ...
> ERROR: Last Trap: Data Access Exception   
>   
>   
> {0} ok

Correction: What I am seeing is:

{0} ok boot
Boot device: disk  File and args: 
WARNING: Unsupported bootblk image, can not extract fcode

WARNING: Bootblk fcode extraction failed
GRUB 
ERROR: Last Trap: Illegal Instruction

{0} ok

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Issues with GRUB 2.04 from experimental with GPT labels

2019-07-08 Thread John Paul Adrian Glaubitz

Hello!

Just as a heads-up: I have noticed problems with GRUB 2.04 from experimental
on SPARC machines with GPT partition tables (but not with Sun partition
tables). So, please don't update to GRUB 2.04 yet until we have figured
out what the problem is.

The issues shows as follows:

Loading Linux 5.2.0 ...
Loading initial ramdisk ...
ERROR: Last Trap: Data Access Exception 

  
{0} ok

The problem does not show with GRUB from upstream, so I'm not sure yet
what the problem is.

In case you already broke your system, you need to boot with the installation
CD [1] into rescue mode and re-install the older version of GRUB (2.02).

Adrian

> [1] 
> https://cdimage.debian.org/cdimage/ports/2019-07-07/debian-10.0-sparc64-NETINST-1.iso

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Will try debian-10.0-sparc64-grub-NETINST-1.iso

2019-05-06 Thread Dennis Clarke


On 5/5/19 8:56 PM, Chris Ross wrote:

On Sun, May 05, 2019 at 07:40:20PM -0400, Dennis Clarke wrote:

I see https://cdimage.debian.org/cdimage/ports/grub-test/ and
have fetched debian-10.0-sparc64-grub-NETINST-1.iso which may
work on a very very old netra test unit. A Netra X1 in fact.
However it has enough memory and a basic serial port for a
console.

Can I serve up this iso image via TFTP/NFS or is it better to
mess around with a physical CDROM ?


I don't have any answers or advice for you, but would be very
interested to hear more about it.  I also have old Sparc's, including
(if it's still around somewhere) an X1.  It would be a lovely low-power
server if I could get it running a reasonable OS.



Well I think any tests that I do will need to be via tftp/nfs as there
is no way that I can attach an old IDE CDROM to this artifact.  I was
able to install Solaris 10 into it just fine.  However that was via a
netboot process as old as the hills.

The other fine fun here is that the NVRAM is toast as is the battery.

I think I should just scrap this test and move on to more modern server
types like the M3000 or Netra T2 line.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Re: Will try debian-10.0-sparc64-grub-NETINST-1.iso

2019-05-05 Thread Chris Ross

On Sun, May 05, 2019 at 07:40:20PM -0400, Dennis Clarke wrote:
> I see https://cdimage.debian.org/cdimage/ports/grub-test/ and
> have fetched debian-10.0-sparc64-grub-NETINST-1.iso which may
> work on a very very old netra test unit. A Netra X1 in fact.
> However it has enough memory and a basic serial port for a
> console.
> 
> Can I serve up this iso image via TFTP/NFS or is it better to
> mess around with a physical CDROM ?

I don't have any answers or advice for you, but would be very 
interested to hear more about it.  I also have old Sparc's, including
(if it's still around somewhere) an X1.  It would be a lovely low-power
server if I could get it running a reasonable OS.

I've attached IDE CD-ROM drives to it in the past to load things, and
while it's possible, it's not fun.  Info on how to load from the
debian distributions over the network would be appreciated.

  - Chris

Will try debian-10.0-sparc64-grub-NETINST-1.iso

2019-05-05 Thread Dennis Clarke





I see https://cdimage.debian.org/cdimage/ports/grub-test/ and
have fetched debian-10.0-sparc64-grub-NETINST-1.iso which may
work on a very very old netra test unit. A Netra X1 in fact.
However it has enough memory and a basic serial port for a
console.

Can I serve up this iso image via TFTP/NFS or is it better to
mess around with a physical CDROM ?



--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

2019-04-29 Thread Gregor Riepl

>> How can the installation system eat so much memory?
> 
> It shouldn't. There is even a lowmem udeb which reduces the memory footprint 
> [1].
> 
> I could even install with debian-installer on my Amiga 1200 with 64 MiB.
> 
> Please don't necessarily take tests on qemu as a reference. Rather test on 
> real
> hardware.

Ah, cool.

I probably need to reinstall soon, so should be able to test the new CD.

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

On 28/04/2019 13:35, John Paul Adrian Glaubitz wrote:

> On 4/28/19 11:13 AM, Mark Cave-Ayland wrote:
>>> I'm not sure this is actually required. debian-installer does actually have 
>>> a low-mem
>>> installation mode with which I could the system even on 64 MiB.
>>
>> Oh I didn't know that! From memory when you first started the ports images 
>> the
>> minimum memory required under qemu-system-sparc64 for the ISOs was 128M, 
>> then about
>> 18 months ago it jumped to 256M and in the most recent it seems to be 512M.
> 
> I will re-test on my Amiga 1200 once time permits. I also have two Pegasus II 
> here
> which also could be useful for that test.

I should add that I suspect some of this comes from the kernel/initrd. IIRC the 
jump
from 128M to 256M occurred around the time when there were discussions on some 
of the
kernel mailing lists related to alignment of various memory areas, but it wasn't
something I really looked into at the time.

Out of interest how do you enable the low memory mode during installation?

>>>> One other slight annoyance is that when the grub menu loads it seems to 
>>>> hammer the
>>>> CPU for the first 60s or so which makes selection almost impossible. I'll 
>>>> see if I
>>>> can find some time to look at this later.
>>>
>>> I have not seen this on real hardware. Worked just fine.
>>
>> My guess is that this is related to the way in which the keyboard/screen are 
>> being
>> polled trigging something in the emulation, so I see this as being a
>> qemu-system-sparc64 issue and not something to block the GRUB work.
> 
> Okay, good to know.
> 
>>>> I remember there being issues translating OF
>>>> pathnames for the OS, but was there progress using grub for HD 
>>>> installation and also
>>>> the installation media?
>>> The pathname translation issue was for grub-installer, i.e. the part where 
>>> the installer
>>> installs GRUB to the target hard disk.
>>
>> (goes and looks)
>>
>> Wow there's a huge backlog of grub-related messages there :/  Do you have a 
>> link to
>> the latest summary update? I can start poking at the outstanding tasks as 
>> time allows.
> 
> The main issue we have is still the bug in ofpathname. We haven't really 
> agreed on
> which utility to use. Currently we're ripping ofpath out of Yaboot which works
> fine on PowerMacs.

Okay thanks, in that case let's continue the discussion over on the debian-ppc 
lists.


ATB,

Mark.

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

On 4/28/19 11:13 AM, Mark Cave-Ayland wrote:
>> I'm not sure this is actually required. debian-installer does actually have 
>> a low-mem
>> installation mode with which I could the system even on 64 MiB.
> 
> Oh I didn't know that! From memory when you first started the ports images the
> minimum memory required under qemu-system-sparc64 for the ISOs was 128M, then 
> about
> 18 months ago it jumped to 256M and in the most recent it seems to be 512M.

I will re-test on my Amiga 1200 once time permits. I also have two Pegasus II 
here
which also could be useful for that test.

>>> One other slight annoyance is that when the grub menu loads it seems to 
>>> hammer the
>>> CPU for the first 60s or so which makes selection almost impossible. I'll 
>>> see if I
>>> can find some time to look at this later.
>>
>> I have not seen this on real hardware. Worked just fine.
> 
> My guess is that this is related to the way in which the keyboard/screen are 
> being
> polled trigging something in the emulation, so I see this as being a
> qemu-system-sparc64 issue and not something to block the GRUB work.

Okay, good to know.

>>> I remember there being issues translating OF
>>> pathnames for the OS, but was there progress using grub for HD installation 
>>> and also
>>> the installation media?
>> The pathname translation issue was for grub-installer, i.e. the part where 
>> the installer
>> installs GRUB to the target hard disk.
> 
> (goes and looks)
> 
> Wow there's a huge backlog of grub-related messages there :/  Do you have a 
> link to
> the latest summary update? I can start poking at the outstanding tasks as 
> time allows.

The main issue we have is still the bug in ofpathname. We haven't really agreed 
on
which utility to use. Currently we're ripping ofpath out of Yaboot which works
fine on PowerMacs.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

On 4/28/19 11:10 AM, Thomas Schmitt wrote:
> John Paul Adrian Glaubitz wrote:
>> You are very welcome to create a guest account for Debian Salsa
> 
> I already have one for xorriso related package preparation.

Ok, great!

>> and open
>> merge requests for the debian-installer and debian-cd projects [1].
> 
> It is more about weighing the options and their consequences. Showing
> shell command results. Convincing the maintainer.
> The proposed changes themselves are quite artless.

How about starting a discussion on the debian-boot mailing list then? I'm
also subscribed there :).

>> Note: The ia64 stuff for debian-cd was copied verbatim from arm64 (boot-ia64
>> is copied from boot-arm64 in debian-cd).
> 
> UEFI: Five CPU architectures in one specification.
> 
> Maybe if i convince you of my proposal i can use the result as lure for
> the other four EFI arches of debian-cd. :))

Sounds good :). The more unification and simplification, the better.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

On 28/04/2019 09:49, John Paul Adrian Glaubitz wrote:

> On 4/28/19 10:33 AM, Mark Cave-Ayland wrote:
>>>> https://cdimage.debian.org/cdimage/ports/grub-test/
>>
>> I grabbed the test image from the above URL to test under 
>> qemu-system-sparc64 and
>> initially got the error below:
> 
> Please note: This image is not particularly tested with regards the installer 
> itself,
> so please let's not start a discussion regarding other issues. The images are 
> solely
> for testing the GRUB boot itself.
> 
>> After some further poking it looks like the latest images bump the minimum 
>> memory
>> requirements from 256M to 512M so qemu-system-sparc64 needs to run with -m 
>> 512.
> 
> I'm not sure this is actually required. debian-installer does actually have a 
> low-mem
> installation mode with which I could the system even on 64 MiB.

Oh I didn't know that! From memory when you first started the ports images the
minimum memory required under qemu-system-sparc64 for the ISOs was 128M, then 
about
18 months ago it jumped to 256M and in the most recent it seems to be 512M.

Certainly let's not mix this with the grub discussion: sadly I don't have 
access to
real SPARC hardware but in a separate thread I'd be interested if you had a 
moment to
test the ISOs in a lower memory LDOM so I can determine whether 
qemu-system-sparc64
behaviour matches that of real hardware. If it isn't then my job is to fix 
that. And
of course don't let this stop you going ahead with merging the GRUB patches :)

>> One other slight annoyance is that when the grub menu loads it seems to 
>> hammer the
>> CPU for the first 60s or so which makes selection almost impossible. I'll 
>> see if I
>> can find some time to look at this later.
> 
> I have not seen this on real hardware. Worked just fine.

My guess is that this is related to the way in which the keyboard/screen are 
being
polled trigging something in the emulation, so I see this as being a
qemu-system-sparc64 issue and not something to block the GRUB work.

>>>> Patches look good, although the second patch still uses 
>>>> /boot/grub/sparc64.elf
>>>> instead of /boot/grub/core.img for the grub-mkimage output parameter - is 
>>>> that correct?
>>> Good catch. Probably forgot a "git commit -a -amend" here.
>>>
>>> Btw, any suggestions for powerpc/ppc64? We are still using Yaboot here. I 
>>> assume this
>>> case will be a bit more complicated due to the fact we also need to support 
>>> PowerMacs.
>>
>> What's the current status? Sorry I had to drop out of that thread but I've 
>> recently
>> had a break because I got married :)
> 
> Congrats!
> 
>> I remember there being issues translating OF
>> pathnames for the OS, but was there progress using grub for HD installation 
>> and also
>> the installation media?
> The pathname translation issue was for grub-installer, i.e. the part where 
> the installer
> installs GRUB to the target hard disk.

(goes and looks)

Wow there's a huge backlog of grub-related messages there :/  Do you have a 
link to
the latest summary update? I can start poking at the outstanding tasks as time 
allows.

ATB,

Mark.

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

2019-04-28 Thread Thomas Schmitt

Hi,

John Paul Adrian Glaubitz wrote:
> You are very welcome to create a guest account for Debian Salsa

I already have one for xorriso related package preparation.

> and open
> merge requests for the debian-installer and debian-cd projects [1].

It is more about weighing the options and their consequences. Showing
shell command results. Convincing the maintainer.
The proposed changes themselves are quite artless.

> Note: The ia64 stuff for debian-cd was copied verbatim from arm64 (boot-ia64
> is copied from boot-arm64 in debian-cd).

UEFI: Five CPU architectures in one specification.

Maybe if i convince you of my proposal i can use the result as lure for
the other four EFI arches of debian-cd. :))

In another mail, Mark Cave-Ayland wrote:
> I've had a break because I got married :)

Congratulations !

Have a nice day :)

Thomas

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

On 4/28/19 10:40 AM, Gregor Riepl wrote:
> That's pretty bad!
> 
> I stuffed my old Ultra 10 with 512MB, but the machine originally came with
> only 256MB.
> 
> How can the installation system eat so much memory?

It shouldn't. There is even a lowmem udeb which reduces the memory footprint 
[1].

I could even install with debian-installer on my Amiga 1200 with 64 MiB.

Please don't necessarily take tests on qemu as a reference. Rather test on real
hardware.

Adrian

> [1] https://packages.qa.debian.org/l/lowmem.html

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

On 4/28/19 10:33 AM, Mark Cave-Ayland wrote:
>>> https://cdimage.debian.org/cdimage/ports/grub-test/
> 
> I grabbed the test image from the above URL to test under qemu-system-sparc64 
> and
> initially got the error below:

Please note: This image is not particularly tested with regards the installer 
itself,
so please let's not start a discussion regarding other issues. The images are 
solely
for testing the GRUB boot itself.

> After some further poking it looks like the latest images bump the minimum 
> memory
> requirements from 256M to 512M so qemu-system-sparc64 needs to run with -m 
> 512.

I'm not sure this is actually required. debian-installer does actually have a 
low-mem
installation mode with which I could the system even on 64 MiB.

> One other slight annoyance is that when the grub menu loads it seems to 
> hammer the
> CPU for the first 60s or so which makes selection almost impossible. I'll see 
> if I
> can find some time to look at this later.

I have not seen this on real hardware. Worked just fine.

>>> Patches look good, although the second patch still uses 
>>> /boot/grub/sparc64.elf
>>> instead of /boot/grub/core.img for the grub-mkimage output parameter - is 
>>> that correct?
>> Good catch. Probably forgot a "git commit -a -amend" here.
>>
>> Btw, any suggestions for powerpc/ppc64? We are still using Yaboot here. I 
>> assume this
>> case will be a bit more complicated due to the fact we also need to support 
>> PowerMacs.
> 
> What's the current status? Sorry I had to drop out of that thread but I've 
> recently
> had a break because I got married :)

Congrats!

> I remember there being issues translating OF
> pathnames for the OS, but was there progress using grub for HD installation 
> and also
> the installation media?
The pathname translation issue was for grub-installer, i.e. the part where the 
installer
installs GRUB to the target hard disk.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

2019-04-28 Thread Gregor Riepl

> Apr 28 08:11:44 debconf: Setting debconf/priority to medium
> Apr 28 08:11:44 kernel: [  135.647875] main-menu[242]: segfault at 8 ip
> 0100298c (rpc f80100128e08) sp 07feff83ead1 error 1 in
> main-menu[100+4000]
> 
> After some further poking it looks like the latest images bump the minimum 
> memory
> requirements from 256M to 512M so qemu-system-sparc64 needs to run with -m 
> 512.

That's pretty bad!

I stuffed my old Ultra 10 with 512MB, but the machine originally came with
only 256MB.

How can the installation system eat so much memory?

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

On 28/04/2019 08:44, John Paul Adrian Glaubitz wrote:

> On 4/28/19 9:25 AM, Mark Cave-Ayland wrote:
>>>> Thanks everyone for the help!
>>>
>>> Attaching the two patches for debian-installer and debian-cd for reference,
>>> will commit them next week after cleaning them up and also switching ia64
>>> to GRUB as well.
>>
>> Amazing - thank you for all the hard work you've put into this! I've just 
>> had a look
>> in your home directory on people.debian.org for the GRUB test ISO but I 
>> can't see it
>> - have you removed it pending application of your patches?
> 
> I moved the images to the cdimage server (there is also a test image for ia64 
> with
> GRUB), as the space on people.debian.org is limited:
> 
>> https://cdimage.debian.org/cdimage/ports/grub-test/

I grabbed the test image from the above URL to test under qemu-system-sparc64 
and
initially got the error below:

Apr 28 08:11:31 debconf: Setting debconf/language to en
Apr 28 08:11:32 main-menu[237]: INFO: Menu item 'localechooser' selected
Apr 28 08:11:32 main-menu[242]: INFO: Falling back to the package description 
for
brltty-udeb
Apr 28 08:11:33 main-menu[242]: INFO: Menu item 'localechooser' selected
Apr 28 08:11:34 main-menu[242]: /var/lib/dpkg/status: No such file or directory
Apr 28 08:11:34 main-menu[242]: /var/lib/dpkg/status: No such file or directory
Apr 28 08:11:34 main-menu[242]: WARNING **: Configuring 
'libdebian-installer4-udeb'
failed with error code 1
Apr 28 08:11:34 main-menu[242]: WARNING **: Menu item 'localechooser' failed.
Apr 28 08:11:34 main-menu[237]: /var/lib/dpkg/status: No such file or directory
Apr 28 08:11:34 main-menu[237]: /var/lib/dpkg/status: No such file or directory
Apr 28 08:11:34 main-menu[237]: WARNING **: Configuring 'cdebconf-udeb' failed 
with
error code 1
Apr 28 08:11:34 main-menu[237]: WARNING **: Menu item 'localechooser' failed.
Apr 28 08:11:44 main-menu[242]: INFO: Modifying debconf priority limit from 
'high' to
'medium'
Apr 28 08:11:44 debconf: Setting debconf/priority to medium
Apr 28 08:11:44 kernel: [  135.647875] main-menu[242]: segfault at 8 ip
0100298c (rpc f80100128e08) sp 07feff83ead1 error 1 in
main-menu[100+4000]

After some further poking it looks like the latest images bump the minimum 
memory
requirements from 256M to 512M so qemu-system-sparc64 needs to run with -m 512.

One other slight annoyance is that when the grub menu loads it seems to hammer 
the
CPU for the first 60s or so which makes selection almost impossible. I'll see 
if I
can find some time to look at this later.

>> Patches look good, although the second patch still uses 
>> /boot/grub/sparc64.elf
>> instead of /boot/grub/core.img for the grub-mkimage output parameter - is 
>> that correct?
> Good catch. Probably forgot a "git commit -a -amend" here.
> 
> Btw, any suggestions for powerpc/ppc64? We are still using Yaboot here. I 
> assume this
> case will be a bit more complicated due to the fact we also need to support 
> PowerMacs.

What's the current status? Sorry I had to drop out of that thread but I've 
recently
had a break because I got married :)  I remember there being issues translating 
OF
pathnames for the OS, but was there progress using grub for HD installation and 
also
the installation media?

ATB,

Mark.

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

Hi!

On 4/28/19 10:20 AM, Thomas Schmitt wrote:
> Interesting. I never had an ISO for Itanium.
> Looks very similar to the Debian arm64 ISOs. Much neater MBR partition
> table than i386 and amd64 ISOs.
> 
> I still see room for improvements (for arm64 too):
> 
> - Use xorrisofs option -partition_offset 16 to get the full image size
>   including the appended partition from commands like /sbin/isosize.
> 
> - Use argument
> --interval:appended_partition_2:all::
>   to option -e, in order to point El Torito to the appended partition.
>   The image file ./CD1/boot/grub/efi.img may then be moved out of ./CD1
>   so that it does not eat room in the ISO filesystem.
> 
> Where to motivate and discuss these ?

You are very welcome to create a guest account for Debian Salsa and open
merge requests for the debian-installer and debian-cd projects [1]. I think
your expertise is very appreciated :-).

The projects can be found here:

> https://salsa.debian.org/images-team/debian-cd
> https://salsa.debian.org/installer-team/debian-installer

There is certainly a lot of room for improvement.

Note: The ia64 stuff for debian-cd was copied verbatim from arm64 (boot-ia64
is copied from boot-arm64 in debian-cd).

Adrian

> [1] https://salsa.debian.org/users/sign_in?redirect_to_referer=yes

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

2019-04-28 Thread Thomas Schmitt

Hi,

John Paul Adrian Glaubitz wrote:
> there is also a test image for ia64 with GRUB
> https://cdimage.debian.org/cdimage/ports/grub-test/

Interesting. I never had an ISO for Itanium.
Looks very similar to the Debian arm64 ISOs. Much neater MBR partition
table than i386 and amd64 ISOs.

I still see room for improvements (for arm64 too):

- Use xorrisofs option -partition_offset 16 to get the full image size
  including the appended partition from commands like /sbin/isosize.

- Use argument
--interval:appended_partition_2:all::
  to option -e, in order to point El Torito to the appended partition.
  The image file ./CD1/boot/grub/efi.img may then be moved out of ./CD1
  so that it does not eat room in the ISO filesystem.

Where to motivate and discuss these ?


Have a nice day :)

Thomas

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

On 4/28/19 9:25 AM, Mark Cave-Ayland wrote:
>>> Thanks everyone for the help!
>>
>> Attaching the two patches for debian-installer and debian-cd for reference,
>> will commit them next week after cleaning them up and also switching ia64
>> to GRUB as well.
> 
> Amazing - thank you for all the hard work you've put into this! I've just had 
> a look
> in your home directory on people.debian.org for the GRUB test ISO but I can't 
> see it
> - have you removed it pending application of your patches?

I moved the images to the cdimage server (there is also a test image for ia64 
with
GRUB), as the space on people.debian.org is limited:

> https://cdimage.debian.org/cdimage/ports/grub-test/

> Patches look good, although the second patch still uses /boot/grub/sparc64.elf
> instead of /boot/grub/core.img for the grub-mkimage output parameter - is 
> that correct?
Good catch. Probably forgot a "git commit -a -amend" here.

Btw, any suggestions for powerpc/ppc64? We are still using Yaboot here. I 
assume this
case will be a bit more complicated due to the fact we also need to support 
PowerMacs.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

On 27/04/2019 20:39, John Paul Adrian Glaubitz wrote:

> On 4/27/19 9:30 PM, John Paul Adrian Glaubitz wrote:
>> On 4/27/19 9:08 PM, Thomas Schmitt wrote:
>>> Maybe you should prepend 512 0-bytes to your cdboot.img.
>>
>> Yes, indeed that did the trick. The uploaded image now works
>> correctly and boots with GRUB on CD. We can finally get rid
>> of SILO \o/.
>>
>> Thanks everyone for the help!
> 
> Attaching the two patches for debian-installer and debian-cd for reference,
> will commit them next week after cleaning them up and also switching ia64
> to GRUB as well.

Amazing - thank you for all the hard work you've put into this! I've just had a 
look
in your home directory on people.debian.org for the GRUB test ISO but I can't 
see it
- have you removed it pending application of your patches?

Patches look good, although the second patch still uses /boot/grub/sparc64.elf
instead of /boot/grub/core.img for the grub-mkimage output parameter - is that 
correct?


ATB,

Mark.

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

On 4/27/19 11:12 PM, Thomas Schmitt wrote:
> The ISO is now added to my collection of bootable ISOs for regression
> test. My test loop checks whether the ISOs which are repacked from
> existing ISOs still show the same boot equipment and file tree content.
> (Happens when i change boot related program parts and before releases.
>  2 hours of 3.5 GHz Xeon shoveling forth and back on about 150 GB.)

Please note: The ISO on my people.debian.org website is just a test
build. The final images will show up on cdimage.debian.org/cdimage.

> May i assume that the old debian-10.0-sparc64-NETINST-1.iso is in
> retirement for now ?
> (Please announce on debian-sparc if the genisoimage style gets revived.)

Yes, once everything is committed to debian-installer and debian-cd git.

I will make an official announcement to the list.

>> boots with GRUB on CD.
> 
> SUN disk label is actually a hard disk thing. Are there machines which
> boot from USB attached disk storage ?

I think that works as well although I only run Linux inside LDOMs, so I
just attach the ISO to a virtual device.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

Hi,

> PS: You can fetch the image from the known location to test

Looks good. Viewing xorriso arguments in /mnt/iso/.disk/mkisofs ...
looks good too.

The ISO is now added to my collection of bootable ISOs for regression
test. My test loop checks whether the ISOs which are repacked from
existing ISOs still show the same boot equipment and file tree content.
(Happens when i change boot related program parts and before releases.
 2 hours of 3.5 GHz Xeon shoveling forth and back on about 150 GB.)


May i assume that the old debian-10.0-sparc64-NETINST-1.iso is in
retirement for now ?
(Please announce on debian-sparc if the genisoimage style gets revived.)


> boots with GRUB on CD.

SUN disk label is actually a hard disk thing. Are there machines which
boot from USB attached disk storage ?


Have a nice day :)

Thomas

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

On 4/27/19 9:30 PM, John Paul Adrian Glaubitz wrote:
> On 4/27/19 9:08 PM, Thomas Schmitt wrote:
>> Maybe you should prepend 512 0-bytes to your cdboot.img.
> 
> Yes, indeed that did the trick. The uploaded image now works
> correctly and boots with GRUB on CD. We can finally get rid
> of SILO \o/.
> 
> Thanks everyone for the help!

Attaching the two patches for debian-installer and debian-cd for reference,
will commit them next week after cleaning them up and also switching ia64
to GRUB as well.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>From c7e260bbe85af8b33df390bdaff85d9c36f8f0c0 Mon Sep 17 00:00:00 2001
From: John Paul Adrian Glaubitz 
Date: Sat, 27 Apr 2019 19:33:30 +
Subject: [PATCH] sparc64: Switch bootloader for d-i from SILO to GRUB

---
 tools/boot/buster/boot-sparc64 | 123 +++--
 tools/generate_di+k_list   |   1 -
 2 files changed, 58 insertions(+), 66 deletions(-)

diff --git a/tools/boot/buster/boot-sparc64 b/tools/boot/buster/boot-sparc64
index 778aee7f..6c48f973 100755
--- a/tools/boot/buster/boot-sparc64
+++ b/tools/boot/buster/boot-sparc64
@@ -1,93 +1,86 @@
-#!/bin/bash -e
-# 
-# boot-sparc64
+#!/bin/bash
 #
-# Do install stuff for sparc64, including making first CD bootable
+# Do install stuff for sparc64, including making bootable CDs
+# Works with debian-installer
+#
+# $1 is the CD number
+# $2 is the temporary CD build dir
 
 . $BASEDIR/tools/boot/$DI_CODENAME/common.sh
 
 set -e
+#set -x
 
 N=$1
 CDDIR=$2
+INSTALLDIR=$CDDIR/install
+
+# Common mkisofs options when creating CDs
+add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-J -joliet-long"
+add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-cache-inodes"
+add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-l"
+
+# mkisofs options specific to sparc64
+add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-G $CDDIR/../CD1/cdboot.img"
+add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-B '...'"
+add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "--grub2-sparc-core /boot/grub/core.img"
 
 # Exit if this is not CD#1/DVD#1
 if [ $N != "1" ]; then
-add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-J -joliet-long"
-add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-cache-inodes"
-add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-l"
 exit 0
 fi
 
 if [ "$DI_WWW_HOME" = "default" ]; then
-DI_WWW_HOME="https://d-i.debian.org/daily-images/sparc64/daily/cdrom/";
+DI_WWW_HOME="https://d-i.debian.org/daily-images/sparc64/daily";
 try_di_image_cache
 else
 DI_WWW_HOME=$(echo $DI_WWW_HOME | sed "s,%ARCH%,$ARCH,")
 fi
 
-add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-G boot1/boot/isofs.b -B ..."
-add_mkisofs_opt $CDDIR/../$N.mkisofs_dirs "boot1"
-
-inst=boot1
+case "$MKISOFS" in
+*xorriso*)
+XORRISO_VER=$(xorriso_version)
+;;
+*)
+	echo "ERROR: debian-cd now depends on xorriso for making sparc64 bootable CDs."
+	exit 1;
+	;;
+esac
 
 cd $CDDIR/..
 
-# Setup directories
-mkdir -p $inst/boot
-
-silo_deb=$(find_pkg_file silo)
-if [ -z "$silo_deb" ]; then
-   echo "ERROR: silo package is required"
-   exit 1
-fi 
-# put the relevant parts of SILO boot loader
-(dpkg --fsys-tarfile $MIRROR/$silo_deb | \
-	tar xf - -C $inst/ ./boot/{isofs,second}.b)
+BOOT_IMAGES="cdrom/initrd.gz cdrom/vmlinux cdrom/debian-cd_info.tar.gz"
 
-if [ -n "$ARCHIVE_EXTRACTED_SOURCES" ]; then
-echo $silo_deb >> $CDDIR/../$N.pkgs_extracted
-find_pkg_file silo source >> $CDDIR/../$N.pkgs_extracted
-fi
+# Download boot images.
+for image in $BOOT_IMAGES; do
+if [ ! -e "$image" ]; then
+dir=$(dirname $image)
+mkdir -p $dir
+if [ -n "$LOCAL"  -a -f "${LOCALDEBS:-$MIRROR}/dists/$DI_DIST/local/installer-$ARCH/current/images/$image" ]; then
+cp "${LOCALDEBS:-$MIRROR}/dists/$DI_DIST/local/installer-$ARCH/current/images/$image" "$image"
+elif [ ! "$DI_WWW_HOME" ];then
+if [ ! "$DI_DIR" ];then
+DI_DIR="$MIRROR/dists/$DI_DIST/main/installer-$ARCH/current/images"
+fi
+cp "$DI_DIR/$image" "$image"
+else
+$WGET "$DI_WWW_HOME/$image" -O "$image"
+fi
+fi
+done
 
-# Some custom etc files
-cp -f -p $BASEDIR/data/${CODENAME}/sparc64/silo.conf $inst/boot/
-if [ -n "$KERNEL_PARAMS" ]; then
-	# Add KERNEL_PARAMS to any existing append line
-	sed -i "/^[[:space:]]*append=\"/ s|append=\"|append=\"$KER

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

On 4/27/19 9:08 PM, Thomas Schmitt wrote:
> Maybe you should prepend 512 0-bytes to your cdboot.img.

Yes, indeed that did the trick. The uploaded image now works
correctly and boots with GRUB on CD. We can finally get rid
of SILO \o/.

Thanks everyone for the help!

PS: You can fetch the image from the known location to test
it yourself. I just need to upload a temporary fix to
the rootskel bug now.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

Hi,

i wrote:
> grub-mkrescue copies stuff to bytes 512 to 767 of its -G image.

It's 512 to 1023, of course.


Have a nice day :)

Thomas

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

Hi,

there is a copy of the -G image file in the ISO:

  /boot/grub/sparc64-ieee1275/cdboot.img

It has only 512 bytes. Very non-zero.

But block 0 is for the SUN disk label (partition table).
libisofs overwrites it completely at ISO production time.
See
  https://sources.debian.org/src/libisofs/1.5.0-1/libisofs/system_area.c/#L776

grub-mkrescue copies stuff to bytes 512 to 767 of its -G image.
Maybe you should prepend 512 0-bytes to your cdboot.img.


Have a nice day :)

Thomas

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

On 27/04/2019 19:26, Thomas Schmitt wrote:

> Hi,
> 
> xorriso-wise, the debian-10.0-sparc64-grub-NETINST-1.iso looks ok:
> 
>   $ xorriso -indev debian-10.0-sparc64-grub-NETINST-1.iso \
> -report_system_area plain
>   ...
>   Volume id: 'Debian 10.0 sparc64 n'
>   System area options: 0x000c
>   System area summary: SUN-SPARC-Disk-Label
>   ISO image size/512 : 443640
>   SUN SPARC disklabel: CD-ROM Disc with Sun sparc boot created by libisofs
>   SUN SPARC secs/head: 640
>   SUN SPARC heads/cyl: 1
>   SUN SPARC partmap  :   N   IdTag   PermsStartCyl   NumBlocks
>   SUN SPARC partition:   1  0x0004  0x0010   0  443640
>   SUN SPARC partition:   2  0x0002  0x0010   0  443640
>   SUN SPARC partition:   3  0x0002  0x0010   0  443640
>   SUN SPARC partition:   4  0x0002  0x0010   0  443640
>   SUN SPARC partition:   5  0x0002  0x0010   0  443640
>   SUN SPARC partition:   6  0x0002  0x0010   0  443640
>   SUN SPARC partition:   7  0x0002  0x0010   0  443640
>   SUN SPARC partition:   8  0x0002  0x0010   0  443640
>   SPARC GRUB2 core   : 1748992  453104
>   SPARC GRUB2 path   : /boot/core.img
> 
> xorriso reports /boot/core.img as "SPARC GRUB2 path", because it was
> recognized as comming from the same disk inode as /boot/grub/core.img
> and thus shares the content blocks with it:
> 
>   $ xorriso -indev debian-10.0-sparc64-grub-NETINST-1.iso \
> -find /boot/core.img -exec report_lba -- \
> -find /boot/grub/core.img -exec report_lba --
>   ...
>   Report layout: xt , Startlba ,   Blocks , Filesize , ISO image path
>   File data lba:  0 ,  854 ,  222 ,   453104 , '/boot/core.img'
>   Report layout: xt , Startlba ,   Blocks , Filesize , ISO image path
>   File data lba:  0 ,  854 ,  222 ,   453104 , '/boot/grub/core.img'
> 
> So all is well. Except the nearly zero content of bytes 512 to 767 of
> the ISO.

One interesting point: the local man page for genisoimage on my Debian stretch
machine states this:

   -G generic_boot_image
Specifies  the  path  and filename of the generic boot image to be used
when making a generic bootable CD.  The boot image will be placed on
the first 16 sectors of the CD, before the ISO9660 primary volume
descriptor.  If this option is used together with -sparc-boot, the Sun
disk label will overlay the first 512 bytes of the generic boot image.

This implies that we need to pad cdboot.img with an initial 512 bytes which 
matches
what Thomas said in one of his earlier emails:

"grub-mkrescue opens cdboot.img for reading and the image file for -G
for writing and truncates it to 0 length. Then it writes 512 zero bytes,
reads 512 bytes from cdboot.img and writes them to the -G image file."


ATB,

Mark.

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

Hi,

xorriso-wise, the debian-10.0-sparc64-grub-NETINST-1.iso looks ok:

  $ xorriso -indev debian-10.0-sparc64-grub-NETINST-1.iso \
-report_system_area plain
  ...
  Volume id: 'Debian 10.0 sparc64 n'
  System area options: 0x000c
  System area summary: SUN-SPARC-Disk-Label
  ISO image size/512 : 443640
  SUN SPARC disklabel: CD-ROM Disc with Sun sparc boot created by libisofs
  SUN SPARC secs/head: 640
  SUN SPARC heads/cyl: 1
  SUN SPARC partmap  :   N   IdTag   PermsStartCyl   NumBlocks
  SUN SPARC partition:   1  0x0004  0x0010   0  443640
  SUN SPARC partition:   2  0x0002  0x0010   0  443640
  SUN SPARC partition:   3  0x0002  0x0010   0  443640
  SUN SPARC partition:   4  0x0002  0x0010   0  443640
  SUN SPARC partition:   5  0x0002  0x0010   0  443640
  SUN SPARC partition:   6  0x0002  0x0010   0  443640
  SUN SPARC partition:   7  0x0002  0x0010   0  443640
  SUN SPARC partition:   8  0x0002  0x0010   0  443640
  SPARC GRUB2 core   : 1748992  453104
  SPARC GRUB2 path   : /boot/core.img

xorriso reports /boot/core.img as "SPARC GRUB2 path", because it was
recognized as comming from the same disk inode as /boot/grub/core.img
and thus shares the content blocks with it:

  $ xorriso -indev debian-10.0-sparc64-grub-NETINST-1.iso \
-find /boot/core.img -exec report_lba -- \
-find /boot/grub/core.img -exec report_lba --
  ...
  Report layout: xt , Startlba ,   Blocks , Filesize , ISO image path
  File data lba:  0 ,  854 ,  222 ,   453104 , '/boot/core.img'
  Report layout: xt , Startlba ,   Blocks , Filesize , ISO image path
  File data lba:  0 ,  854 ,  222 ,   453104 , '/boot/grub/core.img'

So all is well. Except the nearly zero content of bytes 512 to 767 of
the ISO.


Have a nice day :)

Thomas

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

Hi,

bytes 512 to 768 of debian-10.0-sparc64-grub-NETINST-1.iso are all
zero, except the numbers inserted by xorriso:

At byte 552:  00  00  00  00  00  1a  b0  0

At byte 560:  00  06  e9  f0


So something went wrong with boot block image production before the
xorriso run, where it was used with -G.


Have a nice day :)

Thomas

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

Hi,

John Paul Adrian Glaubitz:
> xorriso -as mkisofs -r -checksum_algorithm_iso md5,sha1
> -V 'Debian 10.0 sparc64 n'
> -o /home/glaubitz/debian-cd-test/debian-10.0-sparc64-NETINST-1.iso
> -J -joliet-long -cache-inodes
> -G /home/glaubitz/tmp/sid/CD1/../CD1/boot/grub/sparc64-ieee1275/cdboot.img
> -B '...'
> --grub2-sparc-core /boot/grub/core.img
> -graft-points
> /boot/core.img=/home/glaubitz/tmp/sid/CD1/../CD1/boot/grub/core.img
> CD1

Now you first insert .../core.img as /boot/core.img.
Then you insert it again by its role as sub-file of "CD1" as
ISO file /boot/grub/core.img.
To the latter you refer by --grub2-sparc-core .

So this is without much effect (except adding a file copy to the ISO):

  -graft-points
  /boot/core.img=/home/glaubitz/tmp/sid/CD1/../CD1/boot/grub/core.img


> {0} ok boot cdrom
> Boot device: /virtual-devices@100/channel-devices@200/disk@1  File and args:
> WARNING: Unsupported bootblk image, can not extract fcode
> WARNING: Bootblk fcode extraction failed
> The file just loaded does not appear to be executable.

Is this the SUN firmware speaking ?

Google "sun bootblk" yields
  
https://www.thegeekdiary.com/howto-verify-if-a-bootblk-is-installed-on-the-boot-disk-sparc/?PageSpeed=noscript
where block 1 (i.e. byte 512 ff.) is inspected for "Bootblk".

So it would be about block 1 of your disk file for -G

  /home/glaubitz/tmp/sid/CD1/../CD1/boot/grub/sparc64-ieee1275/cdboot.img

That's where --grub2-sparc-core inserts its numbers.
But i guess it is about the other bytes in there.


Have a nice day :)

Thomas

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

Hi,

> xorriso -as mkisofs -r -checksum_algorithm_iso md5,sha1
> -V 'Debian 10.0 sparc64 n'
> -o /home/glaubitz/debian-cd-test/debian-10.0-sparc64-NETINST-1.iso
> -J -joliet-long -cache-inodes
> -G /home/glaubitz/tmp/sid/CD1/../CD1/boot/grub/sparc64-ieee1275/cdboot.img
> -B ...
> --grub2-sparc-core /home/glaubitz/tmp/sid/CD1/../CD1/boot/grub/core.img
> CD1

Try

  --grub2-sparc-core /boot/grub/core.img

Reasoning:
You obviously give it the path on the source disk. But the option wants
the path in the ISO.

The disk path and the pathspec "CD1" give the impression that there
is a disk file

  CD1/boot/grub/core.img

which by the sparse form of the pathspec will be mapped to ISO path

  /boot/grub/core.img

Later mail:
I wrote:
> >   -graft-points \
> >   /boot/grub/core.img=./dummy_for_core

> What is missing and what I am testing now is the > "-graft-points"
> option which matches the core.img in the ISO with the one outside the ISO.

Not needed.
This is not a matcher but rather an enabler and a file (or tree) insertion.

Option -graft-points enables the pathspec format iso_rr_path=disk_path .

The following pathspec makes use of this:
  /boot/grub/core.img=./dummy_for_core
It inserts the disk file ./dummy_for_core into the ISO as
/boot/grub/core.img .

Your "CD1" inserts the disk tree ./CD1 into the ISO as /-directory.
(Actually it merges the content of ./CD1 with the content of /, which
 at that time is still empty. You may merge-in more disk trees.)

(That's all classical mkisofs operation. I am not happy about everything
 there, but it enables swift transition from mkisofs or genisoimage.)

The option
  -checksum_algorithm_iso md5,sha1
is without effect if you do not produce Jigdo files by option -jigdo-jigdo
et.al. It does not harm, though.

Have a nice day :)

Thomas

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

On 4/27/19 7:16 PM, John Paul Adrian Glaubitz wrote:
> xorriso -as mkisofs -r -checksum_algorithm_iso md5,sha1 -V 'Debian 10.0 
> sparc64 n' -o /home/glaubitz/debian-cd-test/debian-10.0-sparc64-NETINST-1.iso 
> -J -joliet-long -cache-inodes -G 
> /home/glaubitz/tmp/sid/CD1/../CD1/boot/grub/sparc64-ieee1275/cdboot.img 
> --grub2-sparc-core /home/glaubitz/tmp/sid/CD1/../CD1/boot/grub/core.img -B 
> ... CD1
> 
> Maybe the ... need to be quoted.

Still fails to boot:

{0} ok boot cdrom
Boot device: /virtual-devices@100/channel-devices@200/disk@1  File and args: 
WARNING: Unsupported bootblk image, can not extract fcode

WARNING: Bootblk fcode extraction failed

The file just loaded does not appear to be executable.
{0} ok

Image here:

> https://people.debian.org/~glaubitz/debian-10.0-sparc64-grub-NETINST-1.iso

Created with:

xorriso -as mkisofs -r -checksum_algorithm_iso md5,sha1 -V 'Debian 10.0 sparc64 
n' -o /home/glaubitz/debian-cd-test/debian-10.0-sparc64-NETINST-1.iso -J 
-joliet-long -cache-inodes -G 
/home/glaubitz/tmp/sid/CD1/../CD1/boot/grub/sparc64-ieee1275/cdboot.img -B 
'...' --grub2-sparc-core /boot/grub/core.img -graft-points 
/boot/core.img=/home/glaubitz/tmp/sid/CD1/../CD1/boot/grub/core.img CD1

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

On 4/27/19 7:25 PM, Mark Cave-Ayland wrote:
> I think it's trying to find /boot/grub/core.img in the ISO image built from 
> your CD1
> directory and failing - did you also update grub-mkimage in your first patch 
> so that
> the core image is output as core.img and not sparc64.elf?

Yes, of course. What is missing and what I am testing now is the "-graft-points"
option which matches the core.img in the ISO with the one outside the ISO.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

On 4/27/19 7:11 PM, Thomas Schmitt wrote:
>   $ xorriso -as mkisofs \
>   -o test.iso \
>   -V 'FAKE_SPARC_64_ISO' \
>   -J -joliet-long -cache-inodes -l \
>   -G ./dummy_for_G \
>   -B '...' \
>   --grub2-sparc-core /boot/grub/core.img \
>   -graft-points \
>   /boot/grub/core.img=./dummy_for_core
Ah, I think the last two lines are important. The path for --grub2-sparc-core
is *within* the ISO image. And then you have to match it to the outside path.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

On 27/04/2019 18:12, John Paul Adrian Glaubitz wrote:

> On 4/27/19 6:47 PM, Thomas Schmitt wrote:
>> Mark Cave-Ayland wrote:
>>> In that case I think the change for Adrian's second patch should in fact be
>>> this:
>>>  add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-G cdboot.img -B ...
>>> --grub2-sparc-core /boot/grub/core.img"
>>>
>>> Does that look better?
>>
>> If /boot/grub/core.img is the path of the next stage boot file in the
>> ISO filesystem, then yes.
>> grub-mkrescue names it similarly: /boot/grub/sparc64-ieee1275/core.img .
> 
> This gives me an obscure error message:
> 
> xorriso -as mkisofs -r -checksum_algorithm_iso md5,sha1 -V 'Debian 10.0 
> sparc64 n' -o /home/glaubitz/debian-cd-test/debian-10.0-sparc64-NETINST-1.iso 
> -J -joliet-long -cache-inodes -G 
> /home/glaubitz/tmp/sid/CD1/../CD1/boot/grub/sparc64-ieee1275/cdboot.img -B 
> ... --grub2-sparc-core /home/glaubitz/tmp/sid/CD1/../CD1/boot/grub/core.img 
> CD1
> xorriso 1.4.6 : RockRidge filesystem manipulator, libburnia project.
> 
> Drive current: -outdev 
> 'stdio:/home/glaubitz/debian-cd-test/debian-10.0-sparc64-NETINST-1.iso'
> Media current: stdio file, overwriteable
> Media status : is blank
> Media summary: 0 sessions, 0 data blocks, 0 data, 2390g free
> xorriso : WARNING : -volid text problematic as automatic mount point name
> xorriso : WARNING : -volid text does not comply to ISO 9660 / ECMA 119 rules
> xorriso : NOTE : -as mkisofs: Ignored option '-cache-inodes'
> Added to ISO image: directory '/'='/home/glaubitz/tmp/sid/CD1'
> xorriso : UPDATE : 1165 files added in 1 seconds
> xorriso : UPDATE : 1165 files added in 1 seconds
> xorriso : FAILURE : Cannot find in ISO image: -boot_image grub 
> grub2_sparc_core='/home/glaubitz/tmp/sid/CD1/boot/grub/core.img'
> xorriso : NOTE : -return_with SORRY 32 triggered by problem severity FAILURE
> Makefile:489: recipe for target 'images' failed
> make: *** [images] Error 32

I think it's trying to find /boot/grub/core.img in the ISO image built from 
your CD1
directory and failing - did you also update grub-mkimage in your first patch so 
that
the core image is output as core.img and not sparc64.elf?


ATB,

Mark.

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

On 4/27/19 7:11 PM, Thomas Schmitt wrote:
> John Paul Adrian Glaubitz wrote:
>> -J -joliet-long -cache-inodes -l
>> -G $CDDIR/../CD1/boot/grub/sparc64-ieee1275/cdboot.img -B ...
>>
>> Would it be enough to just switch to xorriso here?
> 
> I think you forgot -o result.o and -V Volume_Id.

Those are passed by the other debian-cd code.

The full command line is now:

xorriso -as mkisofs -r -checksum_algorithm_iso md5,sha1 -V 'Debian 10.0 sparc64 
n' -o /home/glaubitz/debian-cd-test/debian-10.0-sparc64-NETINST-1.iso -J 
-joliet-long -cache-inodes -G 
/home/glaubitz/tmp/sid/CD1/../CD1/boot/grub/sparc64-ieee1275/cdboot.img 
--grub2-sparc-core /home/glaubitz/tmp/sid/CD1/../CD1/boot/grub/core.img -B ... 
CD1

Maybe the ... need to be quoted.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

On 4/27/19 6:47 PM, Thomas Schmitt wrote:
> Mark Cave-Ayland wrote:
>> In that case I think the change for Adrian's second patch should in fact be
>> this:
>>  add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-G cdboot.img -B ...
>> --grub2-sparc-core /boot/grub/core.img"
>>
>> Does that look better?
> 
> If /boot/grub/core.img is the path of the next stage boot file in the
> ISO filesystem, then yes.
> grub-mkrescue names it similarly: /boot/grub/sparc64-ieee1275/core.img .

This gives me an obscure error message:

xorriso -as mkisofs -r -checksum_algorithm_iso md5,sha1 -V 'Debian 10.0 sparc64 
n' -o /home/glaubitz/debian-cd-test/debian-10.0-sparc64-NETINST-1.iso -J 
-joliet-long -cache-inodes -G 
/home/glaubitz/tmp/sid/CD1/../CD1/boot/grub/sparc64-ieee1275/cdboot.img -B ... 
--grub2-sparc-core /home/glaubitz/tmp/sid/CD1/../CD1/boot/grub/core.img CD1
xorriso 1.4.6 : RockRidge filesystem manipulator, libburnia project.

Drive current: -outdev 
'stdio:/home/glaubitz/debian-cd-test/debian-10.0-sparc64-NETINST-1.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 2390g free
xorriso : WARNING : -volid text problematic as automatic mount point name
xorriso : WARNING : -volid text does not comply to ISO 9660 / ECMA 119 rules
xorriso : NOTE : -as mkisofs: Ignored option '-cache-inodes'
Added to ISO image: directory '/'='/home/glaubitz/tmp/sid/CD1'
xorriso : UPDATE : 1165 files added in 1 seconds
xorriso : UPDATE : 1165 files added in 1 seconds
xorriso : FAILURE : Cannot find in ISO image: -boot_image grub 
grub2_sparc_core='/home/glaubitz/tmp/sid/CD1/boot/grub/core.img'
xorriso : NOTE : -return_with SORRY 32 triggered by problem severity FAILURE
Makefile:489: recipe for target 'images' failed
make: *** [images] Error 32

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

Hi,

John Paul Adrian Glaubitz wrote:
> -J -joliet-long -cache-inodes -l
> -G $CDDIR/../CD1/boot/grub/sparc64-ieee1275/cdboot.img -B ...
>
> Would it be enough to just switch to xorriso here?

I think you forgot -o result.o and -V Volume_Id.

They are all in the list of emulated options (xorriso -as mkisofs -help
man xorrisofs)

A test:

  $ dd if=/dev/zero bs=512 count=2 of=dummy_for_G

  $ dd if=/dev/zero bs=512 count=10 of=dummy_for_core

  $ xorriso -as mkisofs \
  -o test.iso \
  -V 'FAKE_SPARC_64_ISO' \
  -J -joliet-long -cache-inodes -l \
  -G ./dummy_for_G \
  -B '...' \
      --grub2-sparc-core /boot/grub/core.img \
  -graft-points \
  /boot/grub/core.img=./dummy_for_core
  ...
  Written to medium : 186 sectors at LBA 0
  Writing to 'stdio:test.iso' completed successfully.

  $ xorriso -indev test.iso -report_system_area plain
  ...
  Volume id: 'FAKE_SPARC_64_ISO'
  System area options: 0x000c
  System area summary: SUN-SPARC-Disk-Label
  ISO image size/512 : 744
  SUN SPARC disklabel: CD-ROM Disc with Sun sparc boot created by libisofs
  SUN SPARC secs/head: 640
  SUN SPARC heads/cyl: 1
  SUN SPARC partmap  :   N   IdTag   PermsStartCyl   NumBlocks
  SUN SPARC partition:   1  0x0004  0x0010   0 744
  SUN SPARC partition:   2  0x0002  0x0010   0 744
  SUN SPARC partition:   3  0x0002  0x0010   0 744
  SUN SPARC partition:   4  0x0002  0x0010   0 744
  SUN SPARC partition:   5  0x0002  0x0010   0 744
  SUN SPARC partition:   6  0x0002  0x0010   0 744
  SUN SPARC partition:   7  0x0002  0x0010   0 744
  SUN SPARC partition:   8  0x0002  0x0010   0 744
  SPARC GRUB2 core   : 67584  5120
  SPARC GRUB2 path   : /boot/grub/core.img

The fact that the file core.img is named as "SPARC GRUB2 path" indicates
that its start LBA was written to the right place in the -G image.
(Numbers shown as "SPARC GRUB2 core".)


Have a nice day :)

Thomas

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

Hi,

Mark Cave-Ayland wrote:
> In that case I think the change for Adrian's second patch should in fact be
> this:
>  add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-G cdboot.img -B ...
> --grub2-sparc-core /boot/grub/core.img"
>
> Does that look better?

If /boot/grub/core.img is the path of the next stage boot file in the
ISO filesystem, then yes.
grub-mkrescue names it similarly: /boot/grub/sparc64-ieee1275/core.img .

Note: It won't work with genisoimage.

Have a nice day :)

Thomas

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

On 4/27/19 5:40 PM, Thomas Schmitt wrote:
>> Once this is done and the ISO image is generated, [...]
>> - Next check the offset and size of /boot/grub/core.img embedded in
>> sector 1 using dd and hexdump. As per Thomas' message you should find
>> the offset in bytes of the start of /boot/grub/core.img at offset 552
>> from the start of the .iso (64-bit big endian) and its size at offset
>> 560 from the start of the .iso (32-bit big endian)
> 
> This would be put there by xorriso -as mkisofs option
> 
>   --grub2-sparc-core ...path.of.file.in.ISO.filesystem...
> 
> With genisoimage it would be necessary to insert the info by
> post-processing. /usr/bin/isoinfo prints block addresses as first number
> in its "[   NN NN]" column. Byte offset is block address * 2048.

Okay, I can switch to xorriso, too. But I would assume I would have
to tune more options then.

Currently, we have:

# Common mkisofs options when creating CDs  


add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-J -joliet-long"
add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-cache-inodes"
add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-l"
(...)
add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-G 
$CDDIR/../CD1/boot/grub/sparc64-ieee1275/cdboot.img -B ..."

Would it be enough to just switch to xorriso here?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

On 27/04/2019 17:21, John Paul Adrian Glaubitz wrote:

> On 4/27/19 5:35 PM, Mark Cave-Ayland wrote:
>>> I set $CDDIR to the source directory which contains core.img? How does the 
>>> initial
>>> bootloader know that it has to boot core.img?
>>
>> This is the part which Thomas explained: the offset of core.img *as embedded 
>> within
>> the ISO filesystem image* and its size are embedded at byte offsets 552 and 
>> 560
>> respectively from the start of the image. From what I can see 
>> boot.S/diskboot.S seek
>> to sector 1, read in these values, seek to the start offset and then read the
>> relevant number of bytes into memory before finally transferring control.
> 
> But how does genisoimage know that it is supposed to place "core.img" there?
> 
> This is simply what I cannot wrap my head around it. There is some hidden 
> magic
> that knows that it has to put "core.img" there, but the file is never 
> mentioned
> anywhere.

My understanding is that it's the other way around: the location of core.img is
extracted from the ISO image itself and then re-injected back into sector 1...

> FWIW, it also doesn't boot:
> 
> {0} ok boot cdrom
> Boot device: /virtual-devices@100/channel-devices@200/disk@1  File and args: 
> WARNING: Unsupported bootblk image, can not extract fcode
> 
> WARNING: Bootblk fcode extraction failed
> 
> The file just loaded does not appear to be executable.
> {0} ok
> 
> Image here: 
> https://people.debian.org/~glaubitz/debian-10.0-sparc64-grub-NETINST-1.iso
> 
> Current debian-cd patch attached.

...and the trigger for this is the --grub2-sparc-core parameter that Thomas 
pointed
out was missing from my previous email (see
https://lists.debian.org/debian-sparc/2019/04/msg00057.html for the updated
add_mkisofs_opt).


ATB,

Mark.

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

On 4/27/19 5:35 PM, Mark Cave-Ayland wrote:
>> I set $CDDIR to the source directory which contains core.img? How does the 
>> initial
>> bootloader know that it has to boot core.img?
> 
> This is the part which Thomas explained: the offset of core.img *as embedded 
> within
> the ISO filesystem image* and its size are embedded at byte offsets 552 and 
> 560
> respectively from the start of the image. From what I can see 
> boot.S/diskboot.S seek
> to sector 1, read in these values, seek to the start offset and then read the
> relevant number of bytes into memory before finally transferring control.

But how does genisoimage know that it is supposed to place "core.img" there?

This is simply what I cannot wrap my head around it. There is some hidden magic
that knows that it has to put "core.img" there, but the file is never mentioned
anywhere.

FWIW, it also doesn't boot:

{0} ok boot cdrom
Boot device: /virtual-devices@100/channel-devices@200/disk@1  File and args: 
WARNING: Unsupported bootblk image, can not extract fcode

WARNING: Bootblk fcode extraction failed

The file just loaded does not appear to be executable.
{0} ok

Image here: 
https://people.debian.org/~glaubitz/debian-10.0-sparc64-grub-NETINST-1.iso

Current debian-cd patch attached.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff --git a/tools/boot/buster/boot-sparc64 b/tools/boot/buster/boot-sparc64
index 778aee7f..1a383944 100755
--- a/tools/boot/buster/boot-sparc64
+++ b/tools/boot/buster/boot-sparc64
@@ -1,93 +1,78 @@
-#!/bin/bash -e
-# 
-# boot-sparc64
+#!/bin/bash
 #
-# Do install stuff for sparc64, including making first CD bootable
+# Do install stuff for sparc64, including making bootable CDs
+# Works with debian-installer
+#
+# $1 is the CD number
+# $2 is the temporary CD build dir
 
 . $BASEDIR/tools/boot/$DI_CODENAME/common.sh
 
 set -e
+#set -x
 
 N=$1
 CDDIR=$2
+INSTALLDIR=$CDDIR/install
+
+# Common mkisofs options when creating CDs
+add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-J -joliet-long"
+add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-cache-inodes"
+add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-l"
 
 # Exit if this is not CD#1/DVD#1
 if [ $N != "1" ]; then
-add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-J -joliet-long"
-add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-cache-inodes"
-add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-l"
 exit 0
 fi
 
 if [ "$DI_WWW_HOME" = "default" ]; then
-DI_WWW_HOME="https://d-i.debian.org/daily-images/sparc64/daily/cdrom/";
+DI_WWW_HOME="https://d-i.debian.org/daily-images/sparc64/daily";
 try_di_image_cache
 else
 DI_WWW_HOME=$(echo $DI_WWW_HOME | sed "s,%ARCH%,$ARCH,")
 fi
 
-add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-G boot1/boot/isofs.b -B ..."
-add_mkisofs_opt $CDDIR/../$N.mkisofs_dirs "boot1"
-
-inst=boot1
+# case "$MKISOFS" in
+# *xorriso*)
+# XORRISO_VER=$(xorriso_version)
+# ;;
+# *)
+# 	echo "ERROR: debian-cd now depends on xorriso for making sparc64 bootable CDs."
+# 	exit 1;
+# 	;;
+# esac
 
 cd $CDDIR/..
 
-# Setup directories
-mkdir -p $inst/boot
+BOOT_IMAGES="cdrom/initrd.gz cdrom/vmlinux cdrom/debian-cd_info.tar.gz"
 
-silo_deb=$(find_pkg_file silo)
-if [ -z "$silo_deb" ]; then
-   echo "ERROR: silo package is required"
-   exit 1
-fi 
-# put the relevant parts of SILO boot loader
-(dpkg --fsys-tarfile $MIRROR/$silo_deb | \
-	tar xf - -C $inst/ ./boot/{isofs,second}.b)
+# Download boot images.
+for image in $BOOT_IMAGES; do
+if [ ! -e "$image" ]; then
+dir=$(dirname $image)
+mkdir -p $dir
+if [ -n "$LOCAL"  -a -f "${LOCALDEBS:-$MIRROR}/dists/$DI_DIST/local/installer-$ARCH/current/images/$image" ]; then
+cp "${LOCALDEBS:-$MIRROR}/dists/$DI_DIST/local/installer-$ARCH/current/images/$image" "$image"
+elif [ ! "$DI_WWW_HOME" ];then
+if [ ! "$DI_DIR" ];then
+DI_DIR="$MIRROR/dists/$DI_DIST/main/installer-$ARCH/current/images"
+fi
+cp "$DI_DIR/$image" "$image"
+else
+$WGET "$DI_WWW_HOME/$image" -O "$image"
+fi
+fi
+done
 
-if [ -n "$ARCHIVE_EXTRACTED_SOURCES" ]; then
-echo $silo_deb >> $CDDIR/../$N.pkgs_extracted
-find_pkg_file silo source >> $CDDIR/../$N.pkgs_extracted
-fi
+# Boot setup including config and help files comes from d-i.
+mkdir -pv $PWD/CD$N
+cat cdrom/debian-cd_info.tar.gz | (cd CD

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

On 27/04/2019 16:40, Thomas Schmitt wrote:

> Hi,
> 
> Mark Cave-Ayland wrote:
>> - In your second patch re-enable the -G/-B options but with -G set to
>> cdboot.img:
>> add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-G cdboot.img -B ..."
> 
> Does this refer to
>   From: John Paul Adrian Glaubitz 
>   Date: Thu, 25 Apr 2019 00:05:45 +0200
>   https://lists.debian.org/debian-sparc/2019/04/msg00036.html
> ?
> 
> 
>> Once this is done and the ISO image is generated, [...]
>> - Next check the offset and size of /boot/grub/core.img embedded in
>> sector 1 using dd and hexdump. As per Thomas' message you should find
>> the offset in bytes of the start of /boot/grub/core.img at offset 552
>> from the start of the .iso (64-bit big endian) and its size at offset
>> 560 from the start of the .iso (32-bit big endian)
> 
> This would be put there by xorriso -as mkisofs option
> 
>   --grub2-sparc-core ...path.of.file.in.ISO.filesystem...
> 
> With genisoimage it would be necessary to insert the info by
> post-processing. /usr/bin/isoinfo prints block addresses as first number
> in its "[   NN NN]" column. Byte offset is block address * 2048.

Ooops yes indeed, it is necessary to explicitly enable this via 
--grub2-sparc-core.
In that case I think the change for Adrian's second patch should in fact be 
this:

 add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-G cdboot.img -B ... 
--grub2-sparc-core
/boot/grub/core.img"

Does that look better?


ATB,

Mark.

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

Hi,

Mark Cave-Ayland wrote:
> - In your second patch re-enable the -G/-B options but with -G set to
> cdboot.img:
> add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-G cdboot.img -B ..."

Does this refer to
  From: John Paul Adrian Glaubitz 
  Date: Thu, 25 Apr 2019 00:05:45 +0200
  https://lists.debian.org/debian-sparc/2019/04/msg00036.html
?

> Once this is done and the ISO image is generated, [...]
> - Next check the offset and size of /boot/grub/core.img embedded in
> sector 1 using dd and hexdump. As per Thomas' message you should find
> the offset in bytes of the start of /boot/grub/core.img at offset 552
> from the start of the .iso (64-bit big endian) and its size at offset
> 560 from the start of the .iso (32-bit big endian)

This would be put there by xorriso -as mkisofs option

  --grub2-sparc-core ...path.of.file.in.ISO.filesystem...

With genisoimage it would be necessary to insert the info by
post-processing. /usr/bin/isoinfo prints block addresses as first number
in its "[   NN NN]" column. Byte offset is block address * 2048.

Have a nice day :)

Thomas

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

On 27/04/2019 16:14, John Paul Adrian Glaubitz wrote:

> Hi!
> 
> On 4/27/19 5:02 PM, Mark Cave-Ayland wrote:
>> Adrian: based upon this I think what you need to do is:
>>
>> - For consistency rename /boot/grub/sparc64.elf to /boot/grub/core.img to 
>> match
>>   the descriptions of the grub components in the documentation
> 
> Ok. But still generate it with grub-mkimage?
> 
> +   grub-mkimage -O sparc64-ieee1275-cdcore -p '()/boot/grub' \
> +   -o $(TEMP_CD_INFO_DIR)/boot/grub/sparc64.elf \
> +   $(GRUB_MODULES) $(GRUB_MODULES_CDROM)

Yes, I believe that grub-mkimage generates the grub core image (which by 
convention
is called core.img).

>> - Confirm that cdboot.img is the a.out executable generated by boot.S and 
>> diskboot.S
>>   (use dd and hexdump to check for the 0x01 0x03 0x01 0x07 signature in the 
>> first 4
>>   bytes)
> 
> glaubitz@kyoto:/usr/lib/grub/sparc64-ieee1275$ xxd cdboot.img |head -n2
> : 0103 0107  01e0      ....
> 0010:    4000      ..@.
> glaubitz@kyoto:/usr/lib/grub/sparc64-ieee1275$
> 
> Yes.

Excellent!

>> - In your second patch re-enable the -G/-B options but with -G set to 
>> cdboot.img:
>>  add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-G cdboot.img -B ..."
> 
> I set $CDDIR to the source directory which contains core.img? How does the 
> initial
> bootloader know that it has to boot core.img?

This is the part which Thomas explained: the offset of core.img *as embedded 
within
the ISO filesystem image* and its size are embedded at byte offsets 552 and 560
respectively from the start of the image. From what I can see boot.S/diskboot.S 
seek
to sector 1, read in these values, seek to the start offset and then read the
relevant number of bytes into memory before finally transferring control.

>> Once this is done and the ISO image is generated, the basic setup can be 
>> checked as
>> follows:
>>
>> - Use fdisk or similar tool to confirm that the Sun disk label exists at the
>>   start of the .iso with all 8 partitions starting at sector 0 with an end 
>> sector
>>   representing the contents of the whole CDROM image
>>
>> - Use dd and hexdump to confirm that cdboot.img appears 512 bytes into the 
>> .iso
>>   by checking for the 0x01 0x03 0x01 0x07 signature
>>
>> - Next check the offset and size of /boot/grub/core.img embedded in sector 1 
>> using
>>   dd and hexdump. As per Thomas' message you should find the offset in bytes 
>> of
>>   the start of /boot/grub/core.img at offset 552 from the start of the .iso 
>> (64-bit
>>   big endian) and its size at offset 560 from the start of the .iso (32-bit 
>> big
>>   endian)
>>
>> - If everything is correct then again using dd and hexdump you should be 
>> able to
>>   see the ELF signature for core.img from the offset discovered above.
>>
>> Assuming all of this looks correct, then I believe that you should end up 
>> with a
>> bootable CDROM image using grub...
> 
> Nice. I'll give it a shot tonight and report back.

Actually one thought: are you sure that your grub-mkimage generates an ELF 
binary?
Given that boot.S/diskboot.S don't contain an ELF loader this makes me think 
that
core.img is actually a plain non-relocatable binary. In which case, of course, 
the
final ELF header check above is incorrect.


ATB,

Mark.

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

Hi!

On 4/27/19 5:02 PM, Mark Cave-Ayland wrote:
> Adrian: based upon this I think what you need to do is:
> 
> - For consistency rename /boot/grub/sparc64.elf to /boot/grub/core.img to 
> match
>   the descriptions of the grub components in the documentation

Ok. But still generate it with grub-mkimage?

+   grub-mkimage -O sparc64-ieee1275-cdcore -p '()/boot/grub' \
+   -o $(TEMP_CD_INFO_DIR)/boot/grub/sparc64.elf \
+   $(GRUB_MODULES) $(GRUB_MODULES_CDROM)

> - Confirm that cdboot.img is the a.out executable generated by boot.S and 
> diskboot.S
>   (use dd and hexdump to check for the 0x01 0x03 0x01 0x07 signature in the 
> first 4
>   bytes)

glaubitz@kyoto:/usr/lib/grub/sparc64-ieee1275$ xxd cdboot.img |head -n2
: 0103 0107  01e0      
0010:    4000      ..@.
glaubitz@kyoto:/usr/lib/grub/sparc64-ieee1275$

Yes.

> - In your second patch re-enable the -G/-B options but with -G set to 
> cdboot.img:
>  add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-G cdboot.img -B ..."

I set $CDDIR to the source directory which contains core.img? How does the 
initial
bootloader know that it has to boot core.img?

> Once this is done and the ISO image is generated, the basic setup can be 
> checked as
> follows:
> 
> - Use fdisk or similar tool to confirm that the Sun disk label exists at the
>   start of the .iso with all 8 partitions starting at sector 0 with an end 
> sector
>   representing the contents of the whole CDROM image
> 
> - Use dd and hexdump to confirm that cdboot.img appears 512 bytes into the 
> .iso
>   by checking for the 0x01 0x03 0x01 0x07 signature
> 
> - Next check the offset and size of /boot/grub/core.img embedded in sector 1 
> using
>   dd and hexdump. As per Thomas' message you should find the offset in bytes 
> of
>   the start of /boot/grub/core.img at offset 552 from the start of the .iso 
> (64-bit
>   big endian) and its size at offset 560 from the start of the .iso (32-bit 
> big
>   endian)
> 
> - If everything is correct then again using dd and hexdump you should be able 
> to
>   see the ELF signature for core.img from the offset discovered above.
> 
> Assuming all of this looks correct, then I believe that you should end up 
> with a
> bootable CDROM image using grub...

Nice. I'll give it a shot tonight and report back.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64