While sys-boot/refind-0.10.2 works fine, 0.10.3 and 0.10.4 do not. The behavior I see upon poweron is: 1. Normal Mac boot "ding". 2. Delay of about 4 seconds. 3. A truncated Mac boot "ding" (perhaps the first quarter second of it) infinitely repeats every three seconds or so. Note that the screen turns on, but remains black throughout. I have tested 0.10.3 and 0.10.4, with and without USE=gnuefi, and the result was as above for all cases (I was also careful to completely remove refind from the EFI partition between tests). Rolling back to 0.10.2 (where the ebuild _only_ supported GNU-EFI) solves the boot problem immediately. The timing of the emergence of this problem, coincident with introduction of the gnuefi USE flag and support to the TianoCore UDK, suggests that this is an ebuild problem, but of course, it's also possible that this is, in fact, an upstream bug. Thanks in advance for dev efforts! ======= Portage 2.3.0 (python 2.7.10-final-0, default/linux/amd64/13.0/desktop/plasma/systemd, gcc-4.9.3, glibc-2.22-r4, 4.4.26-gentoo x86_64) ================================================================= System uname: Linux-4.4.26-gentoo-x86_64-Intel-R-_Core-TM-_i7-4870HQ_CPU_@_2.50GHz-with-gentoo-2.2 KiB Mem: 16286084 total, 12925308 free KiB Swap: 21276152 total, 21276152 free Timestamp of repository gentoo: Sun, 30 Oct 2016 04:42:10 +0000 sh bash 4.3_p48 ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1 app-shells/bash: 4.3_p48::gentoo dev-java/java-config: 2.2.0-r3::gentoo dev-lang/perl: 5.22.2::gentoo dev-lang/python: 2.7.10-r1::gentoo, 3.4.3-r1::gentoo dev-util/cmake: 3.5.2-r1::gentoo dev-util/pkgconfig: 0.28-r2::gentoo sys-apps/baselayout: 2.2::gentoo sys-apps/openrc: 0.21.7::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.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: 4.3::gentoo (virtual/os-headers) sys-libs/glibc: 2.22-r4::gentoo Repositories: gentoo location: /usr/portage sync-type: git sync-uri: https://github.com/gentoo-mirror/gentoo.git priority: -1000 local location: /usr/local/portage masters: gentoo priority: 0 toaster location: /var/lib/overlays/toaster sync-type: git sync-uri: https://github.com/toaster/gentoo-overlay.git masters: gentoo priority: 0 lmiphay location: /var/lib/layman/lmiphay sync-type: laymansync sync-uri: git://anongit.gentoo.org/user/lmiphay.git masters: gentoo priority: 50 niftyrepo location: /var/lib/layman/niftyrepo sync-type: laymansync sync-uri: git://github.com/simoncadman/niftyrepo-layman.git masters: gentoo priority: 50 steam-overlay location: /var/lib/layman/steam-overlay sync-type: laymansync sync-uri: git://github.com/anyc/steam-overlay.git masters: gentoo priority: 50 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/themes/oxygen-gtk/gtk-2.0" 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="-march=native -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS=" --with-bdeps y --binpkg-respect-use=y" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs collision-protect 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" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed,-z,now,--hash-style=gnu,--sort-common" MAKEOPTS="-j9" 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 --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" USE="X a52 aac acl acpi aes alsa amd64 avx avx2 bash-completion berkdb branding bzip2 cairo cdda cdio cdr cli cracklib crypt cups curl cxx dbus declarative dri dts dvd dvdr efi emboss encode exif faad fam fdk ffmpeg firefox flac fma3 fortran ftp gd gdbm gif git glamor glib gmp gnuefi gnutls gpm gtk iconv icu idn imagemagick imap innodb ipv6 ithreads jpeg kde kipi lame lcms ldap libnotify mad memlimit mmap mmx mmxext mng modules mp3 mp4 mpeg multilib ncurses netpbm networkmanager nls nptl ogg opengl opus pam pango pch pcre pdf phonon php pic plasma png policykit popcnt postgres ppds pulseaudio python python3 qml qt3support qt4 qt5 readline schroedinger sdl seccomp semantic-desktop session spell sse sse2 sse3 sse4_1 sse4_2 ssl ssse3 startup-notification streaming svg symlink systemd taglib threads threadsafe tiff truetype udev udisks unicode upower usb vhosts vim-syntax vorbis widgets wps wxwidgets x264 xattr xcb xcomposite xinerama xml xscreensaver xv xvid zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="alias auth_basic authn_alias authn_default authn_file authz_default authz_groupfile authz_host authz_user autoindex dav dav_fs dir env expires headers include info log_config mime mime_magic negotiation proxy proxy_http rewrite setenvif status unique_id" APACHE2_MPMS="event" 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" CPU_FLAGS_X86="aes avx avx2 fma3 mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" 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="keyboard mouse evdev" KERNEL="linux" L10N="en en-US" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en en_US" NERONE_USERS="mike" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_4" RUBY_TARGETS="ruby20 ruby21" USERLAND="GNU" 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, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Thank you for reporting the bug. I will not be able to debug myself as I don't have a MacBook… I can anyway give you some ideas about the tests you could do: * Have you tested version 0.10.2-r1? If this version does not work either, it will prove for sure that the problem comes from ebuild, as upstream sources are the same than 0.10.2. * There are actually 2 changes between 0.10.2 and later versions. You noticed the first one, which is the ability to compile using TianoCore UDK, but there is also another modification, which is that the compilation is now using the provided compilers and flags (CFLAGS, LDFLAGS, etc.) Maybe you could try and play with the flags to see if something is changing? Thank you.
Concurrent with your comment, I had also realized that the UDK support was introduced in 0.10.2-r1, which I'd missed before. I've now tested with that (with and without USE=gnuefi), and the same failure does indeed result. I will try some time to experiment with the compilation flags as you suggested, but finding time is rare thing for me these days. If anyone else is experiencing this issue, hopefully they will be able to fill in some gaps, too.
> the compilation is now using the provided compilers and flags > (CFLAGS, LDFLAGS, etc.) Maybe you could try and play with the > flags to see if something is changing? rEFInd is *NOT A LINUX APPLICATION;* it MUST be built using compiler and linker flags that are optimized for the EFI environment, not for a Linux environment. Thus, applying CFLAGS, LDFLAGS, etc., intended for Linux applications is asking for trouble. I've spent literally hours finding compilation and linker flags that work reliably for building rEFInd, and I've discovered that changing those options produces a non-functional binary more often than not. I realize that Gentoo users expect to be able to build binaries with options customized for their own environments; but as the system environment for EFI applications is different from the system environment for Linux applications, it will take a great deal of research and experimentation to figure out which options can be safely changed. In the absence of such research and experimentation, it's best to stick with the compile options that are built into rEFInd's Makefiles.
0.10.2-r1 to 0.10.4 are broken for me on an HP EliteBook 2560p. I tested mostly with gnuefi but at least once without it. Symptom is simply a frozen BIOS screen that does not respond to anything except Ctrl-Alt-Del. Given Rod's comments, it sounds like we urgently need to revert to the recommended compilation flags. I assume the Gentoo CFLAGS/CXXFLAGS apply to the refind command-line utilities such as refind-install, but it sounds like they are not appropriate for whatever binary is installed into the EFI partition. This is a pretty serious regression with high impact on failure so I recommend removing the broken ebuilds immediately. Cheers.
After reading his arguments (and a discussion on IRC), I did as suggested by Rod Smith: not use for EFI compilation the flags the user set for Linux application. Anyway, the unsupported custom-cflags USE was added for adventurers… Pull request: https://github.com/gentoo/gentoo/pull/2754
Hi Mike, Jeremy, Could you make tests with the new releases merged into portage (0.10.2-r2, 0.10.3-r1 or 0.10.4-r1)? Thank you.
Due to limited time, I was only able to test with 0.10.4-r1 and the news is half good: it does work fine now with USE=gnuefi, but without it (i.e. using TianoCore UDK), it continues to fail in the same way. Perhaps the same CFLAGS issues Rod described in comment #3 exists with _that_ ebuild, as well - I'm not able to investigate that possibility further at the moment due to the aforementioned time constraints.
0.10.4-r1[gnuefi] works, thanks.
Someone might want to change the title to something more accurate that relates to CFLAGS and not to Macbooks.
*** Bug 599124 has been marked as a duplicate of this bug. ***
Given the potential breakage this causes and Rods remarks in comment 3, I'm inclined to remove the custom-cflags USE entirely. If there are no objections to this, I'll commit it in the next day or so.
(In reply to Sam Jorna (wraeth) from comment #11) > Given the potential breakage this causes and Rods remarks in comment 3, I'm > inclined to remove the custom-cflags USE entirely. If there are no > objections to this, I'll commit it in the next day or so. The custom-cflags flag allows user to play with CFLAGS even in the EFI application. The custom-cflags use flag is indicated as unsupported in the Gentoo use flag index page, so users should use it carefully, and when they know what they do. For this, I don't think keeping it is a problem. In another hand, if even a small modification of the CFLAGS can break the EFI build, I don't think removing this flag is a problem either. So for me -> neutral opinion. That would be good to have @gokturk's advice, as he suggested to add this flag.
(In reply to Stéphane Veyret from comment #12) > (In reply to Sam Jorna (wraeth) from comment #11) > > Given the potential breakage this causes and Rods remarks in comment 3, I'm > > inclined to remove the custom-cflags USE entirely. If there are no > > objections to this, I'll commit it in the next day or so. > > The custom-cflags flag allows user to play with CFLAGS even in the EFI > application. The custom-cflags use flag is indicated as unsupported in the > Gentoo use flag index page, so users should use it carefully, and when they > know what they do. For this, I don't think keeping it is a problem. > In another hand, if even a small modification of the CFLAGS can break the > EFI build, I don't think removing this flag is a problem either. > So for me -> neutral opinion. > That would be good to have @gokturk's advice, as he suggested to add this > flag. I also don't think this is a problem. We already tell users that custom-cflags isn't supported, so if they break it, it's on them. It doesn't introduce much complexity to the ebuild. If we start getting a lot of whiners who enable the flag, maybe we can remove it then.
Building with custom-cflags has now been fixed, as well as adding a warning that doing so is not recommended and may lead to either failed builds or unbootable binaries. commit 636e954d1e3931cfea387c984fa38a883fc7e8ae Author: Sam Jorna <wraeth@gentoo.org> Date: Wed Dec 14 13:22:26 2016 +1100 sys-boot/refind: fix building with custom-cflags Gentoo-bug: 598587 Acked-by: Stéphane Veyret <sveyret@gmail.com> Package-Manager: Portage-2.3.3, Repoman-2.3.1
