Hi, I don't really know how to handle this, but was asked on ia64 list to report this issue nevertheless. Problem is that I don't really know who's faulty package. Anyway, the facts. I'm unable to boot my ia64 workstation with generated elilo.efi from sys-boot/elilo package. I didn't noticed it until last week-end, when I wanted to give an updated kernel a try, so ran elilo -v to install it on EFI System Partition (ESP). As ia64 owners know, this also installs elilo.efi on ESP, copying it from /usr/lib/elilo/elilo.efi. I was then unable to boot my workstation. I'm getting EFI assertion failures and ultimately MCA: 3 0 0x0002C8 0x0000000000000000 EFI ASSERT error 7 0 0x00006B 0x0000000000000018 unexpected trap 7 0 0x000066 0x0000000000000018 trap taken, number in ext PE 7 0 0x00003C 0x0000000000005400 trap taken, offset in ext PE Replacing elilo.efi on ESP with a prebuilt one, as found on Gentoo or Debian ia64 boot CD, allows me to boot my workstation again. But of course, as soon as elilo -v is invoked, the broken elilo.efi is copied back on ESP. I don't know what triggered this failure. The only thing that comes to mind is that I've upgraded my whole system to gcc 4.9.3, now that gcc 4.9 is ia64 stable. So all packages were rebuilt, including elilo. I simply didn't noticed elilo was broken until last week-end as I didn't had to install a newer kernel before. Rebuilding elilo using older gcc 4.5.4 didn't help (I no more have previous ia64-stable gcc 4.7.3 installed). So maybe other packages than gcc involved in producing EFI binaries are involved. Trying out elilo 3.16 didn't help either. As a workaround, I've copied the prebuilt elilo.efi from Gentoo ia64 boot CD to /usr/lib/elilo/elilo.efi so that elilo -v no more leaves me with an unbootable system, but that's not a solution in the long run. Please let me know how I can help further. Thanks, Émeric
emerge --info output: Portage 2.2.26 (python 3.4.3-final-0, default/linux/ia64/13.0/desktop/gnome/systemd, gcc-4.9.3, glibc-2.21-r2, 4.1.15-gentoo-r1 ia64) ================================================================= System uname: Linux-4.1.15-gentoo-r1-ia64-Madison-with-gentoo-2.2 KiB Mem: 24988608 total, 135264 free KiB Swap: 524272 total, 524272 free Timestamp of repository gentoo: Fri, 19 Feb 2016 20:00:01 +0000 sh bash 4.3_p42-r1 ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1 app-shells/bash: 4.3_p42-r1::gentoo dev-lang/perl: 5.20.2::gentoo dev-lang/python: 2.7.10-r1::gentoo, 3.4.3-r1::gentoo dev-util/cmake: 3.3.1-r1::gentoo dev-util/pkgconfig: 0.28-r2::gentoo sys-apps/baselayout: 2.2::gentoo sys-apps/openrc: 0.18.4::gentoo sys-apps/sandbox: 2.10-r1::gentoo sys-devel/autoconf: 2.13::gentoo, 2.69::gentoo sys-devel/automake: 1.11.6-r1::gentoo, 1.14.1::gentoo, 1.15::gentoo sys-devel/binutils: 2.25.1-r1::gentoo sys-devel/gcc: 4.5.4::gentoo, 4.9.3::gentoo sys-devel/gcc-config: 1.7.3::gentoo sys-devel/libtool: 2.4.6::gentoo sys-devel/make: 4.1-r1::gentoo sys-kernel/linux-headers: 3.18::gentoo (virtual/os-headers) sys-libs/glibc: 2.21-r2::gentoo Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: -1000 my_ebuilds location: /var/lib/layman/my_ebuilds masters: gentoo priority: 0 ACCEPT_KEYWORDS="ia64" ACCEPT_LICENSE="* -@EULA" CBUILD="ia64-unknown-linux-gnu" CFLAGS="-O2 -pipe -mtune=itanium2" CHOST="ia64-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe -mtune=itanium2" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe -mtune=itanium2" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe -mtune=itanium2" GENTOO_MIRRORS="ftp://mirrors.linuxant.fr/distfiles.gentoo.org/" LANG="fr_FR.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" USE="X a52 aac acl acpi alsa berkdb branding bzip2 cairo cdda cdr cli colord cracklib crypt cups cxx dbus dri dts dvdr eds encode evo exif fam firefox flac fortran gdbm gif glamor gnome gnome-keyring gnome-online-accounts gpm gstreamer gtk ia64 iconv introspection ipv6 jpeg lcms ldap libnotify libsecret mad mng modules mp3 mp4 mpeg nautilus ncurses nls nptl ogg opengl openmp pam pango pcre pdf png policykit ppds pulseaudio qt3support qt4 readline sdl session spell ssl startup-notification svg systemd tcpd tiff tracker truetype udev udisks unicode upower usb vorbis wxwidgets xattr xcb xml xv xvid zlib" ALSA_CARDS="fm801" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="fr" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_4" RUBY_TARGETS="ruby20 ruby21" USERLAND="GNU" VIDEO_CARDS="radeon" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Hi, Still problematic with gcc 4.9.4, with the assumption that gcc is part of the problem. Except that this issue now behaves differently and no more ends up with MCA. Trying to boot Gentoo with rebuilt elilo.efi gives in the EFI shell: Loading.: Gentoo Linux ImageAddress: pointer is outside of image ImageAddress: pointer is outside of image LoadPe: Section 1 was not loaded Load of Gentoo Linux failed: Not Found Paused - press any key to continue Émeric
Created attachment 453992 [details] Working elilo.efi (3.12) from Gentoo boot CD image
Created attachment 453994 [details] Broken elilo.efi (3.12) binary as currently rebuilt
For people with EFI knowledge and PE32+ debugging skills, I've posted working and broken elilo.efi 3.12 in attachment 453992 [details] and attachment 453994 [details]. Émeric
A wild guess: I wonder if actual change was caused by sys-boot/gnu-efi
(In reply to Sergei Trofimovich from comment #6) > A wild guess: I wonder if actual change was caused by sys-boot/gnu-efi It looks like around 2008 versions 3.0a and 3.0g were popular. If anyone would like to give it a shot old ebuilds can be pulled at: https://github.com/gentoo/gentoo-gitmig-20150809-draft/tree/master/sys-boot/gnu-efi
(In reply to Sergei Trofimovich from comment #7) > (In reply to Sergei Trofimovich from comment #6) > > A wild guess: I wonder if actual change was caused by sys-boot/gnu-efi > > It looks like around 2008 versions 3.0a and 3.0g were popular. > If anyone would like to give it a shot old ebuilds can be pulled at: > > https://github.com/gentoo/gentoo-gitmig-20150809-draft/tree/master/sys-boot/ > gnu-efi Looking at my /var/log/emerge.log file, =sys-boot/gnu-efi-3.0u (u for unstable?) and =sys-boot/gnu-efi-3.0s (s for stable?) were the only ones ever installed on my system, besides =sys-boot/gnu-efi-3.0.2. So I've tried to downgrade to =sys-boot/gnu-efi-3.0s but it fails to emerge with several unknown type errors: * Package: sys-boot/gnu-efi-3.0s * Repository: localrepo * Maintainer: floppym@gentoo.org ia64@gentoo.org * USE: elibc_glibc ia64 kernel_linux userland_GNU * FEATURES: preserve-libs sandbox userpriv usersandbox >>> Unpacking source... >>> Unpacking gnu-efi_3.0s.orig.tar.gz to /var/tmp/portage/sys-boot/gnu-efi-3.0s/work >>> Unpacking gnu-efi_3.0i-4.diff.gz to /var/tmp/portage/sys-boot/gnu-efi-3.0s/work >>> Source unpacked in /var/tmp/portage/sys-boot/gnu-efi-3.0s/work >>> Preparing source in /var/tmp/portage/sys-boot/gnu-efi-3.0s/work/gnu-efi-3.0 ... * Applying gnu-efi_3.0i-4.diff ... [ ok ] >>> Source prepared. >>> Configuring source in /var/tmp/portage/sys-boot/gnu-efi-3.0s/work/gnu-efi-3.0 ... >>> Source configured. >>> Compiling source in /var/tmp/portage/sys-boot/gnu-efi-3.0s/work/gnu-efi-3.0 ... make -j3 prefix=ia64-unknown-linux-gnu- ARCH=ia64 LIBDIR=lib -j1 mkdir -p lib make -C lib -f ./../lib/Makefile SRCDIR=./../lib ARCH=ia64 make[1]: Entering directory '/var/tmp/portage/sys-boot/gnu-efi-3.0s/work/gnu-efi-3.0/lib' for sdir in ia32 x86_64 ia64 runtime; do mkdir -p $sdir; done ia64-unknown-linux-gnu-gcc -I./../lib -I./../lib/../inc -I./../lib/../inc/ia64 -I./../lib/../inc/protocol -O2 -fpic -Wall -fshort-wchar -fno-strict-aliasing -fno-merge-constants -fno-stack-protector -mfixed-range=f32-f127 -DCONFIG_ia64 -DGNU_EFI_USE_MS_ABI -c boxdraw.c -o boxdraw.o In file included from ./../lib/../inc/efi.h:35:0, from lib.h:20, from boxdraw.c:18: ./../lib/../inc/ia64/efibind.h:75:9: error: unknown type name ‘uint64_t’ typedef uint64_t UINT64; ^ ./../lib/../inc/ia64/efibind.h:76:9: error: unknown type name ‘int64_t’ typedef int64_t INT64; ^ ./../lib/../inc/ia64/efibind.h:77:9: error: unknown type name ‘uint32_t’ typedef uint32_t UINT32; ^ ./../lib/../inc/ia64/efibind.h:78:9: error: unknown type name ‘int32_t’ typedef int32_t INT32; ^ ./../lib/../inc/ia64/efibind.h:79:9: error: unknown type name ‘uint16_t’ typedef uint16_t UINT16; ^ ./../lib/../inc/ia64/efibind.h:80:9: error: unknown type name ‘int16_t’ typedef int16_t INT16; ^ ./../lib/../inc/ia64/efibind.h:81:9: error: unknown type name ‘uint8_t’ typedef uint8_t UINT8; ^ ./../lib/../inc/ia64/efibind.h:82:9: error: unknown type name ‘int8_t’ typedef int8_t INT8; ^ ./../lib/../inc/ia64/efibind.h:90:9: error: unknown type name ‘int64_t’ typedef int64_t INTN; ^ ./../lib/../inc/ia64/efibind.h:91:9: error: unknown type name ‘uint64_t’ typedef uint64_t UINTN; ^ make[1]: *** [../lib/../Make.rules:45: boxdraw.o] Error 1 make[1]: Leaving directory '/var/tmp/portage/sys-boot/gnu-efi-3.0s/work/gnu-efi-3.0/lib' make: *** [Makefile:50: lib] Error 2 * ERROR: sys-boot/gnu-efi-3.0s::localrepo failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=sys-boot/gnu-efi-3.0s::localrepo'`, * the complete build log and the output of `emerge -pqv '=sys-boot/gnu-efi-3.0s::localrepo'`. * The complete build log is located at '/var/tmp/portage/sys-boot/gnu-efi-3.0s/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-boot/gnu-efi-3.0s/temp/environment'. * Working directory: '/var/tmp/portage/sys-boot/gnu-efi-3.0s/work/gnu-efi-3.0' * S: '/var/tmp/portage/sys-boot/gnu-efi-3.0s/work/gnu-efi-3.0' I bet a lot of things has changed since the =sys-boot/gnu-efi-3.0s days (newer glibc and gcc come to mind). Émeric
(In reply to Émeric Maschino from comment #8) > (In reply to Sergei Trofimovich from comment #7) > > (In reply to Sergei Trofimovich from comment #6) > > > A wild guess: I wonder if actual change was caused by sys-boot/gnu-efi > > > > It looks like around 2008 versions 3.0a and 3.0g were popular. > > If anyone would like to give it a shot old ebuilds can be pulled at: > > > > https://github.com/gentoo/gentoo-gitmig-20150809-draft/tree/master/sys-boot/ > > gnu-efi > > Looking at my /var/log/emerge.log file, =sys-boot/gnu-efi-3.0u (u for > unstable?) and =sys-boot/gnu-efi-3.0s (s for stable?) were the only ones > ever installed on my system, besides =sys-boot/gnu-efi-3.0.2. > > So I've tried to downgrade to =sys-boot/gnu-efi-3.0s but it fails to emerge > with several unknown type errors: Aha! Let's try 3.0s then. I've tweaked it to build on modern ghc and pushed ebuild to ::slyfox overlay at: https://github.com/trofi/slyfox-gentoo/tree/master/sys-boot/gnu-efi It's mostly a one-liner: https://github.com/trofi/slyfox-gentoo/blob/master/sys-boot/gnu-efi/files/gnu-efi-3.0s-c99.patch (CFLAGS=-std=c89 should also do the trick)
(In reply to Sergei Trofimovich from comment #9) > > Aha! Let's try 3.0s then. > > I've tweaked it to build on modern ghc and pushed ebuild to ::slyfox overlay > at: > > https://github.com/trofi/slyfox-gentoo/tree/master/sys-boot/gnu-efi > > It's mostly a one-liner: > https://github.com/trofi/slyfox-gentoo/blob/master/sys-boot/gnu-efi/files/ > gnu-efi-3.0s-c99.patch > > (CFLAGS=-std=c89 should also do the trick) Your patch did the trick, thanks. But elilo.efi is still broken with gnu-efi-3.0s/u :-(
(In reply to Émeric Maschino from comment #10) > (In reply to Sergei Trofimovich from comment #9) > > > > Aha! Let's try 3.0s then. > > > > I've tweaked it to build on modern ghc and pushed ebuild to ::slyfox overlay > > at: > > > > https://github.com/trofi/slyfox-gentoo/tree/master/sys-boot/gnu-efi > > > > It's mostly a one-liner: > > https://github.com/trofi/slyfox-gentoo/blob/master/sys-boot/gnu-efi/files/ > > gnu-efi-3.0s-c99.patch > > > > (CFLAGS=-std=c89 should also do the trick) > > Your patch did the trick, thanks. > > But elilo.efi is still broken with gnu-efi-3.0s/u :-( Also not working for me.
I've got iLO access on gentoo's ia64 machine and familiarizing myself on how to put multiple EFI applications into boot loader without breaking the whole system. It's actually quite simple! Didn't try to reproduce the original bug yet.
(In reply to Émeric Maschino from comment #5) > For people with EFI knowledge and PE32+ debugging skills, I've posted > working and broken elilo.efi 3.12 in attachment 453992 [details] and > attachment 453994 [details]. > > Émeric Those two files are so different. One of them is even PE32 while another is PE32+. Can you try elilo.efi from this historical ISO? People say this still boots on ia64: https://dev.gentoo.org/~slyfox/isos/install-ia64-minimal-20160702.iso I'd like to minimize diff for 'objdump -x' first.
Confirmed. New elilo (built on 13.0 stable profile) does not boot: Loading.: Gentoo (try new elilo) ImageAddress: pointer is outside of image ImageAddress: pointer is outside of image LoadPe: Section 1 was not loaded Load of Gentoo (try new elilo) failed: Not Found Press any key to continue Elilo built on 2016 stable profile boots. Will attach elilo-2016.
Created attachment 516900 [details] elilo-2016-ok.efi
(In reply to Sergei Trofimovich from comment #15) > Created attachment 516900 [details] > elilo-2016-ok.efi In reality it might be even older file, from 2006 (reported by objdump -x): Time/Date Mon Jan 9 21:18:46 2006 Magic 010b (PE32)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5b265b524a28991d00be142a2b89a7afa872c496 commit 5b265b524a28991d00be142a2b89a7afa872c496 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-01-27 17:46:17 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-01-27 17:46:38 +0000 sys-boot/gnu-efi: allow user patches, bug #575300 Bug: https://bugs.gentoo.org/575300 Package-Manager: Portage-2.3.20, Repoman-2.3.6 sys-boot/gnu-efi/gnu-efi-3.0.2.ebuild | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)}
Created attachment 516912 [details, diff] gnu-efi-3.0.2-gnu-hash.patch And I have a candidate fix! Drop gnu-efi-3.0.2-gnu-hash.patch to /etc/portage/patches/sys-boot/gnu-efi/ and rebuild: emerge -v1 sys-boot/gnu-efi sys-boot/elilo """ Fix elilo miscompilation on ia64 (and likely others), bug #575300 Presence of a symbol in .hash (or .gnu.hash) section causes ld to generate external reference to ImageBase symbol instead if linking it in. That causes eilio to fail to load by EFI loader on ia64: Loading.: Gentoo (try new elilo) ImageAddress: pointer is outside of image """ I think it broke around the time gentoo enabled GNU hash by default in binutils-2.18 and later. Was stabilized in July 2008. gnu-efi uses very cunning scheme to build PE32+ applications (described in https://sourceforge.net/p/gnu-efi/code/ci/master/tree/README.gnuefi) TL;DR is: 1. link elilo as a shared libary against very restrictive linker script 2. objcopy certain sections in PE32+ libraries First step failed because linker script only connects .hash sections, but not .gnu.hash. As a result ImageBase symbol was not resolved statically. The fix adds .gnu.hash section collection and fixed elilo on ia64.
(In reply to Sergei Trofimovich from comment #18) > Created attachment 516912 [details, diff] [details, diff] > gnu-efi-3.0.2-gnu-hash.patch > The fix adds .gnu.hash section collection and fixed elilo on ia64. I'm not sure if it's an ancient bug in gnu-efi's linker script. The change follows existing .hash collection thus should be OK for workaround. +floppym@ as a gnu-efi co-maintainer +toolchain@ to check if need for .hash / .gnu.hash look bogus and a change works around possible ld bug.
(In reply to Sergei Trofimovich from comment #18) > I think it broke around the time gentoo enabled GNU hash by default in > binutils-2.18 and later. Was stabilized in July 2008. Correction: in 2.18 we have enabled '.gnu.hash' but did not disable '.hash' by default. Things did not break there. binutils-2.24 was the first version when gentoo have disabled '.hash' by default. On ia64 it was stabled in Oct 2014.
that patch looks sane to me. want to post it to the upstream site too ?
(In reply to SpanKY from comment #21) > that patch looks sane to me. want to post it to the upstream site too ? Will do. Also had a peek at http://www.skyfree.org/linux/references/ELF_Format.pdf . It says DT_HASH is a mandatory section for both shared objects and executables (or it's DT_GNU_HASH heir). I hereby declare gnu-efi to be buggy (and not binutils) :)
(In reply to Sergei Trofimovich from comment #22) if the EFI spec requires DT_HASH all the time, then we probably want to change the linker flags to use --hash-style=hash. if someone set LDFLAGS=--hash-style=gnu, then DT_HASH wouldn't be generated at all, and we'd be broken again. that'd also make this issue go away because there wouldn't be any .gnu.hash tables to collect. if the EFI runtime doesn't support DT_GNU_HASH, then it's pointless to generate & emit them in the first place. in which case, you could change the linker script to just discard .gnu.hash entirely rather than placing it in the output.
Proposed the change upstream as: https://sourceforge.net/p/gnu-efi/code/merge-requests/1/
(In reply to SpanKY from comment #23) AFAIU EFI is PE32+ files only (and never ELF files). At least gnu-efi can generate PE32+ only .efi. Thus EFI loader never sees any hash sections. Mechanically: sys-boot/gnu-efi converts "arbitrary" elf files to PE32+ using this hack and a bit of non-ELF relocations in .S files: FORMAT := --target efi-app-$(ARCH) ... %.efi: %.so $(OBJCOPY) -j .text -j .sdata -j .data -j .dynamic -j .dynsym -j .rel \ -j .rela -j .rel.* -j .rela.* -j .rel* -j .rela* \ -j .reloc $(FORMAT) $*.so $@ ... LOADLIBES += -lefi -lgnuefi LOADLIBES += $(LIBGCC) LOADLIBES += -T $(LDSCRIPT) %.so: %.o $(LD) $(LDFLAGS) $^ -o $@ $(LOADLIBES) .hash / .gnu.hash never survives up to .efi binary (-j whitelists expected subset). $(OBJCOPY) converts everything related to dynamic symbols to PE-specific IMPORT directory (.idata / .reloc). As I understand breakage happens here at $(LD) -T $(LDSCRIPT) call as we don't output .gnu.hash even when linker was requested to do it (via default being --hash-style=gnu). Perhaps ld should have failed in this case instead of producing new unresolved symbols? The change %.so: %.o - $(LD) $(LDFLAGS) $^ -o $@ $(LOADLIBES) + $(LD) $(LDFLAGS) -Wl,--hash-style=sysv $^ -o $@ $(LOADLIBES) would also work. As those %.so ELF files are intermediate and are not final product for EFI loader I tried to make them look more like normal .so files :)
(In reply to Sergei Trofimovich from comment #13) > > Can you try elilo.efi from this historical ISO? People say this still boots > on ia64: > https://dev.gentoo.org/~slyfox/isos/install-ia64-minimal-20160702.iso > > I'd like to minimize diff for 'objdump -x' first. I can tell you precisely when Gentoo ia64 ISO images broke: install-ia64-minimal-20161111.iso was the last working ISO. Next one was install-ia64-minimal-20161122.iso and elilo was broken since then. I still have backup copies of both if needed. Do you still need that I try to boot install-ia64-minimal-20160702.iso? As it's anterior to install-ia64-minimal-20161111.iso (last working ISO), I bet it's indeed booting fine. Émeric
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c62fc5c0068b7cf27a79700cf9f0e7f20a625641 commit c62fc5c0068b7cf27a79700cf9f0e7f20a625641 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-01-28 22:54:24 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-01-28 22:58:41 +0000 sys-boot/gnu-efi: fix linker script on .gnu.hash systems, bug #575300 Two patches here: - gnu-hash.patch: fix linker script to work on .gnu.hash-only systems - ia64-setjmp.patch: fix build breakage on ia64 systems Reported-by: Émeric Maschino Closes: https://bugs.gentoo.org/575300 Package-Manager: Portage-2.3.20, Repoman-2.3.6 .../files/gnu-efi-3.0.6-ia64-gnu-hash.patch | 149 +++++++++++++++++++ .../gnu-efi/files/gnu-efi-3.0.6-ia64-setjmp.patch | 163 +++++++++++++++++++++ sys-boot/gnu-efi/gnu-efi-3.0.6-r2.ebuild | 93 ++++++++++++ 3 files changed, 405 insertions(+)
(In reply to Émeric Maschino from comment #26) > (In reply to Sergei Trofimovich from comment #13) > > > > Can you try elilo.efi from this historical ISO? People say this still boots > > on ia64: > > https://dev.gentoo.org/~slyfox/isos/install-ia64-minimal-20160702.iso > > > > I'd like to minimize diff for 'objdump -x' first. > > I can tell you precisely when Gentoo ia64 ISO images broke: > install-ia64-minimal-20161111.iso was the last working ISO. Next one was > install-ia64-minimal-20161122.iso and elilo was broken since then. I still > have backup copies of both if needed. > > Do you still need that I try to boot install-ia64-minimal-20160702.iso? As > it's anterior to install-ia64-minimal-20161111.iso (last working ISO), I bet > it's indeed booting fine. No need to anymore. Thank you! I'll spot-check the delta on guppy, it still has copies of both isos. I believe we have a fix now. Can you try instead to build elilo against latest gnu-efi-3.0.6-r2 instead and give it a boot spin? # emerge -1 =gnu-efi-3.0.6-r2 elilo
(In reply to Sergei Trofimovich from comment #28) that's the nice thing about having such a huge disk :) i wonder if we can figure out how to boot the ISO in app-emulation/ski to help with regression testing
(In reply to Sergei Trofimovich from comment #28) > > I can tell you precisely when Gentoo ia64 ISO images broke: > > install-ia64-minimal-20161111.iso was the last working ISO. Next one was > > install-ia64-minimal-20161122.iso and elilo was broken since then I've compared elilo on both .isos (gentoo.efimg files) and they both have the same elilo binary up to sha1 hash. Kernel did change though. Caused by gcc-4.9.4 stabilization: GCC: (Gentoo 4.9.3 p1.5, pie-0.6.4) vs GCC: (Gentoo 4.9.4 p1.0, pie-0.6.4) Which was likely a bug #601014
(In reply to Sergei Trofimovich from comment #30) > (In reply to Sergei Trofimovich from comment #28) > > > I can tell you precisely when Gentoo ia64 ISO images broke: > > > install-ia64-minimal-20161111.iso was the last working ISO. Next one was > > > install-ia64-minimal-20161122.iso and elilo was broken since then > > I've compared elilo on both .isos (gentoo.efimg files) and they both have > the same elilo binary up to sha1 hash. > > Kernel did change though. Caused by gcc-4.9.4 stabilization: > GCC: (Gentoo 4.9.3 p1.5, pie-0.6.4) > vs > GCC: (Gentoo 4.9.4 p1.0, pie-0.6.4) > Which was likely a bug #601014 My bad, I've totally mixed bugreports :-S So, the last booting Gentoo ia64 ISO image (i.e. working elilo AND kernel) was definitely install-ia64-minimal-20161111.iso. Besides this, I don't remember when kernel was fixed on Gentoo ia64 ISO image, but elilo was broken in the meantime.
