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