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