Re: Any progress with grub-installer?

2019-01-13 Thread John Paul Adrian Glaubitz
On 1/13/19 11:11 PM, Dennis Clarke wrote:
> I mistakenly went with the expert installer of the latest netinst image and 
> saw this :
> 
> 
>   ┌┤ [!!] Install the GRUB boot loader on a hard disk ├┐
>   │  Unable to install GRUB in dummy   │
>   │ Executing 'grub-install dummy' failed. │
>   │ This is a fatal error. │

There is no support for GRUB on PowerPC Macs yet. GRUB is supported on
CHRP and similar machines on powerpc and ppc64 only.

Installing GRUB on a PPC Mac is more complicated and involves creating
an HFS partition which is why it's not been implemented yet. We have
agreed yet on what would be the best implementation.

One suggestion was to use a FAT partition which would apparently work
on real Macintosh hardware but not in QEMU.

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: Any progress with grub-installer?

2019-01-13 Thread Dennis Clarke

On 1/7/19 3:14 PM, John Paul Adrian Glaubitz wrote:

On Jan 7, 2019, at 9:07 PM, Frank Scheiner  wrote:

On 1/7/19 16:35, John Paul Adrian Glaubitz wrote:

On 1/7/19 4:31 PM, John Paul Adrian Glaubitz wrote:
I tried to install GRUB using a ELF boot image:

root@debian:~/grub2# grub-install /dev/vdiska
Installing for sparc64-ieee1275 platform.
grub-install: error: the size of `/boot/grub/sparc64-ieee1275/boot.img' is not 
512.
root@debian:~/grub2# ls -l /boot/grub/sparc64-ieee1275/boot.img
-rw-r--r-- 1 root root 816 Jan  7 18:29 /boot/grub/sparc64-ieee1275/boot.img
root@debian:~/grub2#



I mistakenly went with the expert installer of the latest netinst image 
and saw this :



  ┌┤ [!!] Install the GRUB boot loader on a hard disk ├┐
  │  Unable to install GRUB in dummy   │
  │ Executing 'grub-install dummy' failed. │
  │ This is a fatal error. │


So I will go with lilo or perhaps start over with the default installer
which doesn't really seem to allow manual ipv4 config but may be more
commonly tested.

Dennis



Re: Any progress with grub-installer?

2019-01-08 Thread Frank Scheiner

On 1/7/19 16:31, John Paul Adrian Glaubitz wrote:

On 1/7/19 4:22 PM, John Paul Adrian Glaubitz wrote:

I have done this now:

glaubitz@kyoto:~/grub-debian/test$ find /usr/lib/grub/sparc64-ieee1275/ -name 
"*.img" -exec file {} \;
/usr/lib/grub/sparc64-ieee1275/diskboot.img: data
/usr/lib/grub/sparc64-ieee1275/cdboot.img: SPARC executable
/usr/lib/grub/sparc64-ieee1275/kernel.img: ELF 64-bit MSB executable, SPARC V9, 
relaxed memory ordering, version 1 (SYSV), statically linked, stripped
/usr/lib/grub/sparc64-ieee1275/boot.img: SPARC executable
glaubitz@kyoto:~/grub-debian/test$

Try the packages from here:


I tried to install GRUB using a ELF boot image:

root@debian:~/grub2# grub-install /dev/vdiska
Installing for sparc64-ieee1275 platform.
grub-install: error: the size of `/boot/grub/sparc64-ieee1275/boot.img' is not 
512.
root@debian:~/grub2# ls -l /boot/grub/sparc64-ieee1275/boot.img
-rw-r--r-- 1 root root 816 Jan  7 18:29 /boot/grub/sparc64-ieee1275/boot.img
root@debian:~/grub2#

So, the generated ELF image is too big. No idea yet how to address this.


That's odd. Installed on my machine (a V240 this time) the "boot.img" 
from the grub-sparc-elf-v2 packages from [1] is actually smaller than 
the original one from the packages in Debian Ports currently:


```
## 2.02+dfsg1-9
root@v240-2:/usr/lib/grub/sparc64-ieee1275# ls -l boot.img
-rw-r--r-- 1 root root 480 Dec  7 10:38 boot.img

## 2.02+dfsg1-4
$ ls -l boot.img
-rw-r--r-- 1 user user 512 Apr  1  2018 boot.img
```

...which is backed by the output of `hexdump -C` for both files:

```
## 2.02+dfsg1-9
# hexdump -C boot.img
  40 00 00 51 a0 10 00 0c  00 00 00 00 00 00 00 00 
|@..Q|
0010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
||

*
0080  00 00 00 00 00 00 04 00  00 00 42 00 66 69 6e 64 
|..B.find|

[...]

## 2.02+dfsg1-4
$ hexdump -C boot.img
  01 03 01 07 00 00 01 e0  00 00 00 00 00 00 00 00 
||
0010  00 00 00 00 00 00 40 00  00 00 00 00 00 00 00 00 
|..@.|
0020  40 00 00 51 a0 10 00 0c  00 00 00 00 00 00 00 00 
|@..Q|
0030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
||

*
00a0  00 00 00 00 00 00 04 00  00 00 42 00 66 69 6e 64 
|..B.find|

[...]
```

The newer one is missing 32 bytes at the beginning.

[1]: https://people.debian.org/~glaubitz/grub-sparc-elf-v2/

I still have to test this with an on-disk installation.

Cheers,
Frank



Re: Any progress with grub-installer?

2019-01-08 Thread Mark Cave-Ayland
On 06/01/2019 20:40, John Paul Adrian Glaubitz wrote:

> Switching list for GRUB on SPARC.
> 
> On 1/6/19 9:35 PM, Frank Scheiner wrote:
>>> I think I will work on GRUB on SPARC next to address the build issues there.
>>
>> Before re-enabling COFF for GRUB, we could look into GRUB as ELF on sparc64, 
>> because looking at OpenBSD, their second stage bootloader is actually an ELF 
>> binary:
>>
>> ```
>> root@nfs:/srv/nfs/openbsd/6.3/sparc64# file ofwboot.net
>> ofwboot.net: ELF 64-bit MSB executable, SPARC V9, relaxed memory ordering, 
>> version 1 (SYSV), statically linked, stripped
>>
>> root@nfs:/srv/nfs/openbsd/6.3/sparc64# file bsd.mp
>> bsd.mp: ELF 64-bit MSB executable, SPARC V9, total store ordering, version 1 
>> (SYSV), statically linked, not stripped
>> ```
>>
>> ...so the sparc64 firmware seems to also support ELF binaries. And according 
>> to [6] this seems to work for a lot of systems. If an ELF version of GRUB 
>> can be provided by someone, I have a lot of sparc64 gear to test on - though 
>> not as many as OpenBSD supports ;-).
> 
> I do actually. I have built a version of GRUB for sparc64 with the COFF
> linker options stripped off. Feel free to try the packages from [1].
> 
> If we actually don't ned COFF even on older SPARC boxes, that would be
> great.

>From memory whilst working on this for OpenBIOS: real OBPs can understand an 
>ELF
executable when fed to init-program but something else still has to load them 
from
disk into memory. Possibly much newer hardware can run something like "boot
hd:,\path\to\me.elf" but certainly the Ultra series don't have elf-files or 
equivalent.

The BSD bootloaders follow the Solaris method which is to have a Fcode (compiled
Forth) bootblock which pulls in the ELF and then executes it via "init-program 
go".
SILO works by having an a.out bootblock which pulls in the next stage by 
memorising
the set of block numbers at installation time, loads it and then executes it.


ATB,

Mark.



Re: Any progress with grub-installer?

2019-01-07 Thread John Paul Adrian Glaubitz
On 1/7/19 9:59 PM, James Clarke wrote:
> Maybe. I wouldn't be surprised if sector 0 still has the old boot.img, but is
> loading the newer kernel.img or whatever is the next stage from /boot. That
> version number in the fancy boot menu almost certainly doesn't live in sector
> 0, 512 bytes (or 816 bytes) is really not very much at all.

Well, I do know that in past times, the version number didn't get bumped before
I actually ran the grub-install command. But I haven't dissected the whole
process yet.

I will perform more tests tomorrow.

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: Any progress with grub-installer?

2019-01-07 Thread James Clarke
On 7 Jan 2019, at 20:47, John Paul Adrian Glaubitz 
 wrote:
> 
> Hi!
> 
> On 1/7/19 9:23 PM, Frank Scheiner wrote:
>>> Yes, but I know what I did. I‘m not sure why you are questioning that. Do 
>>> you see any unexpected results?
>> 
>> No, but from the `grub-install` output I didn't expect that the installation
>> worked and after comparing the versions of v1 and v2, I just wanted to be
>> sure about the details. I was not questioning what you did. :-)
> 
> Well, I was sure the installation didn't work either. But after rebooting, 
> the GRUB
> version in the boot menu was bumped. So the bootloader was most likely 
> rewritten.

Maybe. I wouldn't be surprised if sector 0 still has the old boot.img, but is
loading the newer kernel.img or whatever is the next stage from /boot. That
version number in the fancy boot menu almost certainly doesn't live in sector
0, 512 bytes (or 816 bytes) is really not very much at all.

James



Re: Any progress with grub-installer?

2019-01-07 Thread John Paul Adrian Glaubitz
Hi!

On 1/7/19 9:23 PM, Frank Scheiner wrote:
>> Yes, but I know what I did. I‘m not sure why you are questioning that. Do 
>> you see any unexpected results?
> 
> No, but from the `grub-install` output I didn't expect that the installation
> worked and after comparing the versions of v1 and v2, I just wanted to be
> sure about the details. I was not questioning what you did. :-)

Well, I was sure the installation didn't work either. But after rebooting, the 
GRUB
version in the boot menu was bumped. So the bootloader was most likely 
rewritten.

I will have a look with a hex editor later to see whether there is an ELF binary
now. It should be possible to see the ELF header starting at sector 0.

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: Any progress with grub-installer?

2019-01-07 Thread Frank Scheiner

On 1/7/19 21:14, John Paul Adrian Glaubitz wrote:




On Jan 7, 2019, at 9:07 PM, Frank Scheiner  wrote:


On 1/7/19 16:35, John Paul Adrian Glaubitz wrote:

On 1/7/19 4:31 PM, John Paul Adrian Glaubitz wrote:
I tried to install GRUB using a ELF boot image:

root@debian:~/grub2# grub-install /dev/vdiska
Installing for sparc64-ieee1275 platform.
grub-install: error: the size of `/boot/grub/sparc64-ieee1275/boot.img' is not 
512.
root@debian:~/grub2# ls -l /boot/grub/sparc64-ieee1275/boot.img
-rw-r--r-- 1 root root 816 Jan  7 18:29 /boot/grub/sparc64-ieee1275/boot.img
root@debian:~/grub2#

So, the generated ELF image is too big. No idea yet how to address this.

It does seem to work, however. At least with GPT:
  GNU GRUB  version 2.02+dfsg1-9
  ++
  |*Debian GNU/Linux   |



Did you maybe already install the v1 version on this GPT disk?


No, I didn’t. I only ever tried v2 on this machine. In fact, I built v2 first, 
then ran the tests.


As both v1 and v2 use the same version number it's not clear if this is one or 
the other.


Yes, but I know what I did. I‘m not sure why you are questioning that. Do you 
see any unexpected results?


No, but from the `grub-install` output I didn't expect that the 
installation worked and after comparing the versions of v1 and v2, I 
just wanted to be sure about the details. I was not questioning what you 
did. :-)


Cheers,
Frank



Re: Any progress with grub-installer?

2019-01-07 Thread John Paul Adrian Glaubitz



> On Jan 7, 2019, at 9:07 PM, Frank Scheiner  wrote:
> 
>> On 1/7/19 16:35, John Paul Adrian Glaubitz wrote:
>>> On 1/7/19 4:31 PM, John Paul Adrian Glaubitz wrote:
>>> I tried to install GRUB using a ELF boot image:
>>> 
>>> root@debian:~/grub2# grub-install /dev/vdiska
>>> Installing for sparc64-ieee1275 platform.
>>> grub-install: error: the size of `/boot/grub/sparc64-ieee1275/boot.img' is 
>>> not 512.
>>> root@debian:~/grub2# ls -l /boot/grub/sparc64-ieee1275/boot.img
>>> -rw-r--r-- 1 root root 816 Jan  7 18:29 /boot/grub/sparc64-ieee1275/boot.img
>>> root@debian:~/grub2#
>>> 
>>> So, the generated ELF image is too big. No idea yet how to address this.
>> It does seem to work, however. At least with GPT:
>>  GNU GRUB  version 2.02+dfsg1-9
>>  
>> ++
>>  |*Debian GNU/Linux  
>>  |
> 
> 
> Did you maybe already install the v1 version on this GPT disk?

No, I didn’t. I only ever tried v2 on this machine. In fact, I built v2 first, 
then ran the tests.

> As both v1 and v2 use the same version number it's not clear if this is one 
> or the other.

Yes, but I know what I did. I‘m not sure why you are questioning that. Do you 
see any unexpected results?

> And maybe the above `grub-install /dev/vdiska` didn't install the v2 version 
> at all. Did it exit with `0`, as it actually reports an "error" and not a 
> "warning"?

It did. The version number in the GRUB menu was bumped from -4 something to -9.

I used —force, FWIW when running grub-install.

Adrian


Re: Any progress with grub-installer?

2019-01-07 Thread Frank Scheiner

On 1/7/19 16:35, John Paul Adrian Glaubitz wrote:

On 1/7/19 4:31 PM, John Paul Adrian Glaubitz wrote:

I tried to install GRUB using a ELF boot image:

root@debian:~/grub2# grub-install /dev/vdiska
Installing for sparc64-ieee1275 platform.
grub-install: error: the size of `/boot/grub/sparc64-ieee1275/boot.img' is not 
512.
root@debian:~/grub2# ls -l /boot/grub/sparc64-ieee1275/boot.img
-rw-r--r-- 1 root root 816 Jan  7 18:29 /boot/grub/sparc64-ieee1275/boot.img
root@debian:~/grub2#

So, the generated ELF image is too big. No idea yet how to address this.


It does seem to work, however. At least with GPT:


  GNU GRUB  version 2.02+dfsg1-9

  ++
  |*Debian GNU/Linux   |



Did you maybe already install the v1 version on this GPT disk?

As both v1 and v2 use the same version number it's not clear if this is 
one or the other. And maybe the above `grub-install /dev/vdiska` didn't 
install the v2 version at all. Did it exit with `0`, as it actually 
reports an "error" and not a "warning"?


Cheers,
Frank



Re: Any progress with grub-installer?

2019-01-07 Thread Dennis Clarke

On 1/7/19 10:35 AM, John Paul Adrian Glaubitz wrote:

On 1/7/19 4:31 PM, John Paul Adrian Glaubitz wrote:

I tried to install GRUB using a ELF boot image:



Now we just need to test this on a machine with a Sun partition table.


I can drag out an old sparc for that easily.

Dennis




Re: Any progress with grub-installer?

2019-01-07 Thread John Paul Adrian Glaubitz
On 1/7/19 4:31 PM, John Paul Adrian Glaubitz wrote:
> I tried to install GRUB using a ELF boot image:
> 
> root@debian:~/grub2# grub-install /dev/vdiska
> Installing for sparc64-ieee1275 platform.
> grub-install: error: the size of `/boot/grub/sparc64-ieee1275/boot.img' is 
> not 512.
> root@debian:~/grub2# ls -l /boot/grub/sparc64-ieee1275/boot.img
> -rw-r--r-- 1 root root 816 Jan  7 18:29 /boot/grub/sparc64-ieee1275/boot.img
> root@debian:~/grub2#
> 
> So, the generated ELF image is too big. No idea yet how to address this.

It does seem to work, however. At least with GPT:


 GNU GRUB  version 2.02+dfsg1-9

 ++
 |*Debian GNU/Linux   | 
 | Advanced options for Debian GNU/Linux  |
 ||
 ||
 ||
 ||
 ||
 ||
 ||
 ||
 ||
 || 
 ++

  Use the ^ and v keys to select which entry is highlighted.  
  Press enter to boot the selected OS, `e' to edit the commands   
  before booting or `c' for a command-line.

Now we just need to test this on a machine with a Sun partition table.

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: Any progress with grub-installer?

2019-01-07 Thread John Paul Adrian Glaubitz
On 1/7/19 4:22 PM, John Paul Adrian Glaubitz wrote:
> I have done this now:
> 
> glaubitz@kyoto:~/grub-debian/test$ find /usr/lib/grub/sparc64-ieee1275/ -name 
> "*.img" -exec file {} \;
> /usr/lib/grub/sparc64-ieee1275/diskboot.img: data
> /usr/lib/grub/sparc64-ieee1275/cdboot.img: SPARC executable
> /usr/lib/grub/sparc64-ieee1275/kernel.img: ELF 64-bit MSB executable, SPARC 
> V9, relaxed memory ordering, version 1 (SYSV), statically linked, stripped
> /usr/lib/grub/sparc64-ieee1275/boot.img: SPARC executable
> glaubitz@kyoto:~/grub-debian/test$
> 
> Try the packages from here:

I tried to install GRUB using a ELF boot image:

root@debian:~/grub2# grub-install /dev/vdiska
Installing for sparc64-ieee1275 platform.
grub-install: error: the size of `/boot/grub/sparc64-ieee1275/boot.img' is not 
512.
root@debian:~/grub2# ls -l /boot/grub/sparc64-ieee1275/boot.img
-rw-r--r-- 1 root root 816 Jan  7 18:29 /boot/grub/sparc64-ieee1275/boot.img
root@debian:~/grub2#

So, the generated ELF image is too big. No idea yet how to address this.

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: Any progress with grub-installer?

2019-01-07 Thread John Paul Adrian Glaubitz
On 1/7/19 3:43 PM, John Paul Adrian Glaubitz wrote:
> I guess I need to modify the linker flags to explicitly create the
> images as ELF.

I have done this now:

glaubitz@kyoto:~/grub-debian/test$ find /usr/lib/grub/sparc64-ieee1275/ -name 
"*.img" -exec file {} \;
/usr/lib/grub/sparc64-ieee1275/diskboot.img: data
/usr/lib/grub/sparc64-ieee1275/cdboot.img: SPARC executable
/usr/lib/grub/sparc64-ieee1275/kernel.img: ELF 64-bit MSB executable, SPARC V9, 
relaxed memory ordering, version 1 (SYSV), statically linked, stripped
/usr/lib/grub/sparc64-ieee1275/boot.img: SPARC executable
glaubitz@kyoto:~/grub-debian/test$

Try the packages from here:

> https://people.debian.org/~glaubitz/grub-sparc-elf-v2/

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: Any progress with grub-installer?

2019-01-07 Thread John Paul Adrian Glaubitz
On 1/7/19 3:34 PM, John Paul Adrian Glaubitz wrote:
> According to the build log, the affected image is "boot.img":
> 
> if test x0 = x1; then   ../grub-macho2img boot.image boot.img; else   objcopy 
>  -O a.out-sunos-big  --strip-unneeded -R .note -R .comment -R 
> .note.gnu.build-id -R .MIPS.abiflags -R .reginfo -R .rel.dyn -R 
> .note.gnu.gold-version -R .ARM.exidx boot.image boot.img; fi
> objcopy:boot.img: invalid bfd target
> 
> And looking the output of file, it seems that boot.img (and some other images)
> is indeed not ELF:
> 
> glaubitz@kyoto:~$ file /usr/lib/grub/sparc64-ieee1275/boot.img
> /usr/lib/grub/sparc64-ieee1275/boot.img: SPARC executable
> glaubitz@kyoto:~$ file /usr/lib/grub/sparc64-ieee1275/cdboot.img 
> /usr/lib/grub/sparc64-ieee1275/cdboot.img: SPARC executable
> glaubitz@kyoto:~$ file /usr/lib/grub/sparc64-ieee1275/diskboot.img
> /usr/lib/grub/sparc64-ieee1275/diskboot.img: data
> glaubitz@kyoto:~$
> 
> These images should be of ELF type on your machine.
Some more comparision:

glaubitz@kyoto:~/grub-debian/test$ find . -name "*.img" -exec file {} \;
./usr/lib/grub/sparc64-ieee1275/diskboot.img: data
./usr/lib/grub/sparc64-ieee1275/cdboot.img: data
./usr/lib/grub/sparc64-ieee1275/kernel.img: ELF 64-bit MSB executable, SPARC 
V9, relaxed memory ordering, version 1 (SYSV), statically linked, stripped
./usr/lib/grub/sparc64-ieee1275/boot.img: data
glaubitz@kyoto:~/grub-debian/test$ find /usr/lib/grub/sparc64-ieee1275/ -name 
"*.img" -exec file {} \;
/usr/lib/grub/sparc64-ieee1275/diskboot.img: data
/usr/lib/grub/sparc64-ieee1275/cdboot.img: SPARC executable
/usr/lib/grub/sparc64-ieee1275/kernel.img: ELF 64-bit MSB executable, SPARC V9, 
relaxed memory ordering, version 1 (SYSV), statically linked, stripped
/usr/lib/grub/sparc64-ieee1275/boot.img: SPARC executable
glaubitz@kyoto:~/grub-debian/test$ diff -u 
./usr/lib/grub/sparc64-ieee1275/diskboot.img 
/usr/lib/grub/sparc64-ieee1275/diskboot.img
glaubitz@kyoto:~/grub-debian/test$ diff -u 
./usr/lib/grub/sparc64-ieee1275/cdboot.img 
/usr/lib/grub/sparc64-ieee1275/cdboot.img
Binary files ./usr/lib/grub/sparc64-ieee1275/cdboot.img and 
/usr/lib/grub/sparc64-ieee1275/cdboot.img differ
glaubitz@kyoto:~/grub-debian/test$ diff -u 
./usr/lib/grub/sparc64-ieee1275/kernel.img 
/usr/lib/grub/sparc64-ieee1275/kernel.img
Binary files ./usr/lib/grub/sparc64-ieee1275/kernel.img and 
/usr/lib/grub/sparc64-ieee1275/kernel.img differ
glaubitz@kyoto:~/grub-debian/test$ diff -u 
./usr/lib/grub/sparc64-ieee1275/cdboot.img 
/usr/lib/grub/sparc64-ieee1275/cdboot.img
Binary files ./usr/lib/grub/sparc64-ieee1275/cdboot.img and 
/usr/lib/grub/sparc64-ieee1275/cdboot.img differ
glaubitz@kyoto:~/grub-debian/test$

And with the help of xxd:

glaubitz@kyoto:~/grub-debian/test$ diff -u ~/grub-boot-old.diff 
~/grub-boot-new.diff  
--- /home/glaubitz/grub-boot-old.diff   2019-01-07 15:40:01.075758523 +0100
+++ /home/glaubitz/grub-boot-new.diff   2019-01-07 15:39:56.383751925 +0100
@@ -1,32 +1,30 @@
-: 0103 0107  01e0      
-0010:    4000      ..@.
-0020: 4000 0051 a010 000c      @..Q
+: 4000 0051 a010 000c      @..Q
+0010:          
+0020:          
 0030:          
 0040:          
 0050:          
 0060:          
 0070:          
-0080:          
-0090:          
-00a0:    0400  4200 6669 6e64  ..B.find
-00b0: 6465 7669 6365 002f 6368 6f73 656e 0067  device./chosen.g
-00c0: 6574 7072 6f70 0073 7464 6f75 7400 7772  etprop.stdout.wr
-00d0: 6974 6500 626f 6f74 7061 7468 006f 7065  ite.bootpath.ope
-00e0: 6e00 7365 656b 0072 6561 6400 6578 6974  n.seek.read.exit
-00f0: 0047 5255 4220  9405 e0bd 4000 000d  .GRUB ..@...
-0100: 9610 2004 9005 e0cc 9410  1080 000c  .. .
-0110: 8210 2001 8210 2004 c274 6100 9210 0014  .. ... ..ta.
-0120: 1080 0007 9005 e09f 1080 0004 9210 0016  
-0130: 9005 e0ae 9210 0015 8210 2003 9a10 2001  .. ... .
-0140: d074 6000 c274 6008 da74 6010 d274 6018  .t`..t`..t`..t`.
-0150: d474 6020 d674 6028 d874 6030 81c4   .t` .t`(.t`0
-0160: 9010 0011 ae10 000f 2300 0014 9005 e08c  #...
-0170: 7fff ffe6 9205 e097 e85c 6020 02fd 3fe2  .\` ..?.
-0180: 9405 e0a7 9604 6100 7fff ffe3 9810 2400  ..a...$.
-0190: ea04 6100 02f5 7fdc 9405 

Re: Any progress with grub-installer?

2019-01-07 Thread John Paul Adrian Glaubitz
On 1/7/19 3:23 PM, Frank Scheiner wrote:
> I tried to test these packages, but the created core.img (for netboot though) 
> is still a COFF binary IIUIC:

Well, all I did is to strip "a.out" from the linker flags:

--- grub2-2.02+dfsg1.orig/grub-core/Makefile.core.def
+++ grub2-2.02+dfsg1/grub-core/Makefile.core.def
@@ -369,7 +369,6 @@ image = {
   i386_qemu_ldflags = 
'$(TARGET_IMG_BASE_LDOPT),$(GRUB_BOOT_MACHINE_LINK_ADDR)';
   i386_qemu_ccasflags = 
'-DGRUB_BOOT_MACHINE_LINK_ADDR=$(GRUB_BOOT_MACHINE_LINK_ADDR)';
 
-  sparc64_ieee1275_objcopyflags = '-O a.out-sunos-big';
   sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x4000';
 
   objcopyflags = '-O binary';
@@ -399,7 +398,6 @@ image = {
   i386_pc_ldflags = '$(TARGET_IMG_BASE_LDOPT),0x7C00';
 
   sparc64_ieee1275 = boot/sparc64/ieee1275/boot.S;
-  sparc64_ieee1275_objcopyflags = '-O a.out-sunos-big';
   sparc64_ieee1275_ldflags = ' -Wl,-Ttext=0x4000';
   sparc64_ieee1275_cppflags = '-DCDBOOT=1';

According to the build log, the affected image is "boot.img":

if test x0 = x1; then   ../grub-macho2img boot.image boot.img; else   objcopy  
-O a.out-sunos-big  --strip-unneeded -R .note -R .comment -R .note.gnu.build-id 
-R .MIPS.abiflags -R .reginfo -R .rel.dyn -R .note.gnu.gold-version -R 
.ARM.exidx boot.image boot.img; fi
objcopy:boot.img: invalid bfd target

And looking the output of file, it seems that boot.img (and some other images)
is indeed not ELF:

glaubitz@kyoto:~$ file /usr/lib/grub/sparc64-ieee1275/boot.img
/usr/lib/grub/sparc64-ieee1275/boot.img: SPARC executable
glaubitz@kyoto:~$ file /usr/lib/grub/sparc64-ieee1275/cdboot.img 
/usr/lib/grub/sparc64-ieee1275/cdboot.img: SPARC executable
glaubitz@kyoto:~$ file /usr/lib/grub/sparc64-ieee1275/diskboot.img
/usr/lib/grub/sparc64-ieee1275/diskboot.img: data
glaubitz@kyoto:~$

These images should be of ELF type on your machine.

> Checking the man page of `grub-mkimage` the available formats for sparc64 are 
> (1) "sparc64-ieee1275-raw",
> (2) "sparc64-ieee1275-cdcore" and (3) "sparc64-ieee1275-aout". Using format 1 
> and 2 creates a file that is
> identified by `file` as "data". The one from the `mknetdir` run above is of 
> type "SPARC executable". 

If there is a tool within GRUB that explicitly creates a.out binaries, I would 
expect that to still it's
job as merely changed linker flags.

> The "underlying" binary is ELF though:
> 
> ```
> root@e250-5:~# file /usr/lib/grub/sparc64-ieee1275/kernel.img
> /usr/lib/grub/sparc64-ieee1275/kernel.img: ELF 64-bit MSB executable, SPARC 
> V9, relaxed memory ordering, version 1 (SYSV), statically linked, stripped
> ```

This is already the case for the current GRUB package we have:

glaubitz@kyoto:~$ file /usr/lib/grub/sparc64-ieee1275/kernel.img
/usr/lib/grub/sparc64-ieee1275/kernel.img: ELF 64-bit MSB executable, SPARC V9, 
relaxed memory ordering, version 1 (SYSV), statically linked, stripped
glaubitz@kyoto:~$

> I can of course create an on-disk installation and try to use this image 
> instead as "core.img",
> but I think this is not enough and needs at least the module to access the 
> bootstrap partition added in some way.
> 
> I assume we need to create a new format named "sparc64-ieee1275-elf" in e.g. 
> `grub-mkimage` ([1]) and possibly
> other places, though I don't know what configuration is needed for formats in 
> the struct "image_targets".
> The above three formats only differ in the used "id", hence I think the 
> actual format is defined somewhere else.
> 
> [1]: https://salsa.debian.org/grub-team/grub/blob/master/util/mkimage.c
> 
> What do you think?

I would suggest you try whether your machine still boots after install the grub2
packages I provided you with. Just make sure you re-run "grub-install", then
update-grub and reboot.

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: Any progress with grub-installer?

2019-01-07 Thread Frank Scheiner

Hi Adrian,

On 1/6/19 21:43, Frank Scheiner wrote:

On 1/6/19 21:40, John Paul Adrian Glaubitz wrote:

On 1/6/19 9:35 PM, Frank Scheiner wrote:
If an ELF 
version of GRUB can be provided by someone, I have a lot of sparc64 
gear to test on - though not as many as OpenBSD supports ;-).


I do actually. I have built a version of GRUB for sparc64 with the COFF
linker options stripped off. Feel free to try the packages from [1].

If we actually don't ned COFF even on older SPARC boxes, that would be
great.


I tried to test these packages, but the created core.img (for netboot 
though) is still a COFF binary IIUIC:


```
root@e250-5:~# grub-mknetdir -v
[...]
grub-mknetdir: info: copying `/usr/share/grub/unicode.pf2' -> 
`/srv/tftp/boot/grub/fonts/unicode.pf2'.
grub-mknetdir: info: grub-mkimage --directory 
'/usr/lib/grub/sparc64-ieee1275' --prefix '/boot/grub' --output 
'/srv/tftp/boot/grub/sparc64-ieee1275/core.img' --format 
'sparc64-ieee1275-aout' --compression 'auto'  'tftp' 'ofnet'

.
grub-mknetdir: info: the total module size is 0x2ba48.
grub-mknetdir: info: reading /usr/lib/grub/sparc64-ieee1275/kernel.img.
grub-mknetdir: info: locating the section .text at 0x0.
grub-mknetdir: info: locating the section .rodata at 0x106b0.
grub-mknetdir: info: locating the section .data at 0x13618.
grub-mknetdir: info: locating the section .module_license at 0x14bb8.
grub-mknetdir: info: locating the section .bss at 0x14bd8.
grub-mknetdir: info: reading /usr/lib/grub/sparc64-ieee1275/bufio.mod.
grub-mknetdir: info: reading /usr/lib/grub/sparc64-ieee1275/datetime.mod.
grub-mknetdir: info: reading /usr/lib/grub/sparc64-ieee1275/boot.mod.
grub-mknetdir: info: reading 
/usr/lib/grub/sparc64-ieee1275/priority_queue.mod.

grub-mknetdir: info: reading /usr/lib/grub/sparc64-ieee1275/net.mod.
grub-mknetdir: info: reading /usr/lib/grub/sparc64-ieee1275/tftp.mod.
grub-mknetdir: info: reading /usr/lib/grub/sparc64-ieee1275/ofnet.mod.
grub-mknetdir: info: kernel_img=0xf8010005c010, kernel_size=0x14bd8.
grub-mknetdir: info: the core size is 0x40620.
grub-mknetdir: info: writing 0x40640 bytes.
Netboot directory for sparc64-ieee1275 created. Configure your DHCP 
server to point to /srv/tftp/boot/grub/sparc64-ieee1275/core.img

```

Checking the man page of `grub-mkimage` the available formats for 
sparc64 are (1) "sparc64-ieee1275-raw", (2) "sparc64-ieee1275-cdcore" 
and (3) "sparc64-ieee1275-aout". Using format 1 and 2 creates a file 
that is identified by `file` as "data". The one from the `mknetdir` run 
above is of type "SPARC executable". The "underlying" binary is ELF though:


```
root@e250-5:~# file /usr/lib/grub/sparc64-ieee1275/kernel.img
/usr/lib/grub/sparc64-ieee1275/kernel.img: ELF 64-bit MSB executable, 
SPARC V9, relaxed memory ordering, version 1 (SYSV), statically linked, 
stripped

```

I can of course create an on-disk installation and try to use this image 
instead as "core.img", but I think this is not enough and needs at least 
the module to access the bootstrap partition added in some way.


I assume we need to create a new format named "sparc64-ieee1275-elf" in 
e.g. `grub-mkimage` ([1]) and possibly other places, though I don't know 
what configuration is needed for formats in the struct "image_targets". 
The above three formats only differ in the used "id", hence I think the 
actual format is defined somewhere else.


[1]: https://salsa.debian.org/grub-team/grub/blob/master/util/mkimage.c

What do you think?

Cheers,
Frank



Re: Any progress with grub-installer?

2019-01-06 Thread Frank Scheiner

On 1/6/19 21:40, John Paul Adrian Glaubitz wrote:

Switching list for GRUB on SPARC.

On 1/6/19 9:35 PM, Frank Scheiner wrote:

I think I will work on GRUB on SPARC next to address the build issues there.


Before re-enabling COFF for GRUB, we could look into GRUB as ELF on sparc64, 
because looking at OpenBSD, their second stage bootloader is actually an ELF 
binary:

```
root@nfs:/srv/nfs/openbsd/6.3/sparc64# file ofwboot.net
ofwboot.net: ELF 64-bit MSB executable, SPARC V9, relaxed memory ordering, 
version 1 (SYSV), statically linked, stripped

root@nfs:/srv/nfs/openbsd/6.3/sparc64# file bsd.mp
bsd.mp: ELF 64-bit MSB executable, SPARC V9, total store ordering, version 1 
(SYSV), statically linked, not stripped
```

...so the sparc64 firmware seems to also support ELF binaries. And according to 
[6] this seems to work for a lot of systems. If an ELF version of GRUB can be 
provided by someone, I have a lot of sparc64 gear to test on - though not as 
many as OpenBSD supports ;-).


I do actually. I have built a version of GRUB for sparc64 with the COFF
linker options stripped off. Feel free to try the packages from [1].

If we actually don't ned COFF even on older SPARC boxes, that would be
great.

Adrian


[1] https://people.debian.org/~glaubitz/grub-sparc-elf/




Cool, thanks, will give that a try on my current local machines for a 
start and report back.


Cheers,
Frank



Re: Any progress with grub-installer?

2019-01-06 Thread John Paul Adrian Glaubitz
Switching list for GRUB on SPARC.

On 1/6/19 9:35 PM, Frank Scheiner wrote:
>> I think I will work on GRUB on SPARC next to address the build issues there.
> 
> Before re-enabling COFF for GRUB, we could look into GRUB as ELF on sparc64, 
> because looking at OpenBSD, their second stage bootloader is actually an ELF 
> binary:
> 
> ```
> root@nfs:/srv/nfs/openbsd/6.3/sparc64# file ofwboot.net
> ofwboot.net: ELF 64-bit MSB executable, SPARC V9, relaxed memory ordering, 
> version 1 (SYSV), statically linked, stripped
> 
> root@nfs:/srv/nfs/openbsd/6.3/sparc64# file bsd.mp
> bsd.mp: ELF 64-bit MSB executable, SPARC V9, total store ordering, version 1 
> (SYSV), statically linked, not stripped
> ```
> 
> ...so the sparc64 firmware seems to also support ELF binaries. And according 
> to [6] this seems to work for a lot of systems. If an ELF version of GRUB can 
> be provided by someone, I have a lot of sparc64 gear to test on - though not 
> as many as OpenBSD supports ;-).

I do actually. I have built a version of GRUB for sparc64 with the COFF
linker options stripped off. Feel free to try the packages from [1].

If we actually don't ned COFF even on older SPARC boxes, that would be
great.

Adrian

> [1] https://people.debian.org/~glaubitz/grub-sparc-elf/

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