Created attachment 462668 [details] modified ebuild for grub-0.97-r17 gcc-6.3.0 doesn't know the compiler option nopie. It has to be replaced with no-pie The culprit is patch 860_all_grub-0.97-pie.patch I have attached an ebuild which fixes this patch on-the-fly
(In reply to Helmut Jarausch from comment #0) > Created attachment 462668 [details] > modified ebuild for grub-0.97-r17 > > gcc-6.3.0 doesn't know the compiler option nopie. It has to be replaced with > no-pie > > The culprit is patch 860_all_grub-0.97-pie.patch > > I have attached an ebuild which fixes this patch on-the-fly You need to test what version of the compiler that get just for <gcc-6 don't support -no-pie. Grub 2 allready have the support.
I am getting the same on grub-0.97-r16 when trying to compile with x86_64-pc-linux-gnu-6.4.0: ======================================= x86_64-pc-linux-gnu-gcc -m32 -DHAVE_CONFIG_H -I. -I.. -I../stage1 -Wall -Wmissing-prototypes -Wunused -Wshadow -Wpointer-arith -falign-jumps=1 -falign-loops=1 -falign-functions=1 -Wundef -Os -fno-stack-protector -nopie -fno-strict-aliasing -march=i686 -fno-reorder-functions -fno-builtin -nostdinc -DSUPPORT_SERIAL=1 -DSUPPORT_HERCULES=1 -DSUPPORT_GRAPHICS=1 -DFSYS_EXT2FS=1 -DFSYS_FAT=1 -DFSYS_FFS=1 -DFSYS_UFS2=1 -DFSYS_MINIX=1 -DFSYS_REISERFS=1 -DFSYS_VSTAFS=1 -DFSYS_JFS=1 -DFSYS_XFS=1 -DFSYS_ISO9660=1 -DUSE_MD5_PASSWORDS=1 -g -c -o pre_stage2_exec-builtins.o `test -f 'builtins.c' || echo './'`builtins.c x86_64-pc-linux-gnu-gcc -m32 -DHAVE_CONFIG_H -I. -I.. -I../stage1 -Wall -Wmissing-prototypes -Wunused -Wshadow -Wpointer-arith -falign-jumps=1 -falign-loops=1 -falign-functions=1 -Wundef -Os -fno-stack-protector -nopie -fno-strict-aliasing -march=i686 -fno-reorder-functions -fno-builtin -nostdinc -DSUPPORT_SERIAL=1 -DSUPPORT_HERCULES=1 -DSUPPORT_GRAPHICS=1 -DFSYS_EXT2FS=1 -DFSYS_FAT=1 -DFSYS_FFS=1 -DFSYS_UFS2=1 -DFSYS_MINIX=1 -DFSYS_REISERFS=1 -DFSYS_VSTAFS=1 -DFSYS_JFS=1 -DFSYS_XFS=1 -DFSYS_ISO9660=1 -DUSE_MD5_PASSWORDS=1 -g -c -o pre_stage2_exec-char_io.o `test -f 'char_io.c' || echo './'`char_io.c x86_64-pc-linux-gnu-gcc: error: unrecognized command line option ‘-nopie’; did you mean ‘-no-pie’? x86_64-pc-linux-gnu-gcc: error: unrecognized command line option ‘-nopie’; did you mean ‘-no-pie’? make[2]: *** [Makefile:2878: pre_stage2_exec-bios.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: *** [Makefile:2892: pre_stage2_exec-boot.o] Error 1 x86_64-pc-linux-gnu-gcc: error: unrecognized command line option ‘-nopie’; did you mean ‘-no-pie’? make[2]: *** [Makefile:2920: pre_stage2_exec-char_io.o] Error 1 x86_64-pc-linux-gnu-gcc: error: unrecognized command line option ‘-nopie’; did you mean ‘-no-pie’? make[2]: *** [Makefile:1492: pre_stage2_exec-asm.o] Error 1 x86_64-pc-linux-gnu-gcc: error: unrecognized command line option ‘-nopie’; did you mean ‘-no-pie’? make[2]: *** [Makefile:2906: pre_stage2_exec-builtins.o] Error 1 make[2]: Leaving directory '/data/tmp_var/portage/sys-boot/grub-0.97-r16/work/grub-0.97/stage2' make[1]: *** [Makefile:382: all-recursive] Error 1 make[1]: Leaving directory '/data/tmp_var/portage/sys-boot/grub-0.97-r16/work/grub-0.97' make: *** [Makefile:323: all] Error 2 * ERROR: sys-boot/grub-0.97-r16::gentoo failed (compile phase): =============================================================== BUT ... grub-0.97-r17 compiled fine. Can you please stabilise sys-boot/grub-0.97-r17? -- Regards, Mick
With gcc-6.x stable, I guess -r17 should go stable too. (Fixing the assignee per metadata.xml comments.) commit fd205ea13d9f7998b8de9b5311d0dcb1c278f76d Author: Ian Stakenvicius <axs@gentoo.org> Date: Thu Oct 26 16:25:49 2017 -0400 sys-boot/grub-0.97-r17: switch -nopie for -no-pie on gcc6+ As the -nopie option was something gentoo patched into gcc via the pie patc$ used for hardened, and these patches are not applied to gcc6, the no-pie patch used with grub:0 needs to be adjusted to hse the new flag when a newer gcc is used. Package-Manager: Portage-2.3.8, Repoman-2.3.3
gcc-6.4 completes the build of sys-boot/grub-0.97-r17 now but the binary results are totally unusable: Look at the file sizes of the stage files: ~ $ ls -l /lib/grub/i386-pc/ total 263324 -rw-r--r-- 1 root root 10964 Dec 2 05:04 e2fs_stage1_5 -rw-r--r-- 1 root root 10068 Dec 2 05:04 fat_stage1_5 -rw-r--r-- 1 root root 9396 Dec 2 05:04 ffs_stage1_5 -rw-r--r-- 1 root root 9428 Dec 2 05:04 iso9660_stage1_5 -rw-r--r-- 1 root root 11232 Dec 2 05:04 jfs_stage1_5 -rw-r--r-- 1 root root 9684 Dec 2 05:04 minix_stage1_5 -rw-r--r-- 1 root root 12372 Dec 2 05:04 reiserfs_stage1_5 -rw-r--r-- 1 root root 134481293 Dec 2 05:04 stage1 -rw-r--r-- 1 root root 134607237 Dec 2 05:04 stage2 -rw-r--r-- 1 root root 134608261 Dec 2 05:04 stage2_eltorito -rw-r--r-- 1 root root 9716 Dec 2 05:04 ufs2_stage1_5 -rw-r--r-- 1 root root 9012 Dec 2 05:04 vstafs_stage1_5 -rw-r--r-- 1 root root 11866 Dec 2 05:04 xfs_stage1_5 stage1 for example is 130MB (!!) in size and should be 512 bytes. Needless to say that any attempt of running "setup (hdx)" ends up with an error, because it detects the stages as being broken. As soon as the as "sys-boot/grub-0.97-r17" copies the files over the ones in "/boot/grub" the system wont come up from the next reboot anymore.
(In reply to Christian Birchinger from comment #4) > gcc-6.4 completes the build of sys-boot/grub-0.97-r17 now but the binary > results are totally unusable: ... > -rw-r--r-- 1 root root 134481293 Dec 2 05:04 stage1 > -rw-r--r-- 1 root root 134607237 Dec 2 05:04 stage2 .. > stage1 for example is 130MB (!!) in size and should be 512 bytes. I saw this as well (the copy failed due to lack of space on my boot partition). I switched back gcc 5.4.0, rebuilt grub-0.97-r16 and confirmed that I could reboot.
From my x86 system: > # du -h /var/tmp/portage/sys-boot/grub-0.97-r17/image/lib/grub/i386-pc/stag* > 4.0K /var/tmp/portage/sys-boot/grub-0.97-r17/image/lib/grub/i386-pc/stage1 > 116K /var/tmp/portage/sys-boot/grub-0.97-r17/image/lib/grub/i386-pc/stage2 > 116K /var/tmp/portage/sys-boot/grub-0.97-r17/image/lib/grub/i386-pc/stage2_eltorito However, on my ~amd64 system (with gcc-7.2.0 instead of gcc-6.4.0) I can confirm that there's something wrong: > # du -h /var/tmp/portage/sys-boot/grub-0.97-r17/image/lib/grub/i386-pc/stag* > 8,0K /var/tmp/portage/sys-boot/grub-0.97-r17/image/lib/grub/i386-pc/stage1 > 129M /var/tmp/portage/sys-boot/grub-0.97-r17/image/lib/grub/i386-pc/stage2 > 129M /var/tmp/portage/sys-boot/grub-0.97-r17/image/lib/grub/i386-pc/stage2_eltorito grub-0.97-r17 on my stable x86 system (built with gcc-6.4.0 / binutils-2.29.1!) boots.
Same problem here; after upgrading to new gcc and starting to do the 17.0 profile move, I had to add grub-0.97-r17 to /etc/portage/package.keywords to get past the nopie/no-pie flag mismatch during an emerge -e @world and then the next time I rebooted, grub wasn't working. After inspecting /boot/grub from a livecd, I saw similarly large binaries (~128MB) but without installing an old GCC (since I had already removed 5.x.x) couldn't rebuild stage1 and stage2 and ended up copying the stage1 and stage2 from the livecd to get my system bootable again.
If you've already removed gcc-5 and upgraded to profile 17.0, you can try unmasking gcc-5 in /etc/portage/package.unmask, emerging gcc-5, switching to gcc-5 with gcc-config, emerging grub:0, then switching back to gcc-6 with gcc-config.
*** Bug 639772 has been marked as a duplicate of this bug. ***
(In reply to Lucian Poston from comment #8) > If you've already removed gcc-5 and upgraded to profile 17.0, you can try > unmasking gcc-5 in /etc/portage/package.unmask, emerging gcc-5, switching to > gcc-5 with gcc-config, emerging grub:0, then switching back to gcc-6 with > gcc-config. As a workaround, emerging grub-0.97-r17 with gcc-5 on a 17.0 profile, and installing it worked fine for me.
RIGHT. So I'm not good enough to be able to fix whatever gcc6 is doing to the code, and although it -can- be installed still with gcc5, gcc5 isn't stable and there's no support for switching toolchains in ebuilds on the fly. I'm thinking that this may be the time to p.mask grub:0 for eventual removal. Unless someone else here can contribute patches that work..
At least I would, for now, hard mask it for 17.0 profiles or people can get an unbootable system
Some sort of workable solution, or reasonably simple workaround needs to be made available, or be clearly (albeit temporarily) inserted into the install guide(s). Grub2 is an extra level of complexity that really isn't required if you're not concerned about UEFI. If I had to recover a legacy server from scratch this would certainly cause me hours of misery (if I didn't know about it) in the midst of a crisis.
I think I have got a patch for the issue(s) with gcc6. # cat /etc/portage/patches/sys-boot/grub-0.97/grub-0.97-piex.patch --- grub-0.97/configure.ac 2017-12-11 10:48:19.529910979 -0600 +++ grub-0.97x/configure.ac 2017-12-11 10:54:39.347763206 -0600 @@ -122,8 +122,9 @@ grub_cv_cc_fpie=no) ]) if test "x$grub_cv_cc_fpie" = xyes; then - STAGE1_CFLAGS="$STAGE1_CFLAGS -no-pie" - STAGE2_CFLAGS="$STAGE2_CFLAGS -no-pie" + STAGE1_CFLAGS="$STAGE1_CFLAGS -fno-pie" + STAGE2_CFLAGS="$STAGE2_CFLAGS -fno-pie" + LDFLAGS="$LDFLAGS -no-pie" fi fi fi With the above patch the build is successful and the resultant sizes of stage1 and stage2 are like they should be: # ls -l /lib/grub/i386-pc total 352 -rw-r--r-- 1 root root 9972 Dec 11 11:17 e2fs_stage1_5 -rw-r--r-- 1 root root 9204 Dec 11 11:17 fat_stage1_5 -rw-r--r-- 1 root root 8532 Dec 11 11:17 ffs_stage1_5 -rw-r--r-- 1 root root 8532 Dec 11 11:17 iso9660_stage1_5 -rw-r--r-- 1 root root 10144 Dec 11 11:17 jfs_stage1_5 -rw-r--r-- 1 root root 8724 Dec 11 11:17 minix_stage1_5 -rw-r--r-- 1 root root 11220 Dec 11 11:17 reiserfs_stage1_5 -rw-r--r-- 1 root root 512 Dec 11 11:17 stage1 -rw-r--r-- 1 root root 118456 Dec 11 11:17 stage2 -rw-r--r-- 1 root root 118456 Dec 11 11:17 stage2_eltorito -rw-r--r-- 1 root root 8788 Dec 11 11:17 ufs2_stage1_5 -rw-r--r-- 1 root root 8180 Dec 11 11:17 vstafs_stage1_5 -rw-r--r-- 1 root root 10842 Dec 11 11:17 xfs_stage1_5 For comparison my previous build (sys-boot/grub-0.97-r16 built with sys-devel/gcc-5.4.0-r3) looked like this: # ls -l /lib/grub/i386-pc total 356 -rw-r--r-- 1 root root 10036 Dec 11 2016 e2fs_stage1_5 -rw-r--r-- 1 root root 9236 Dec 11 2016 fat_stage1_5 -rw-r--r-- 1 root root 8564 Dec 11 2016 ffs_stage1_5 -rw-r--r-- 1 root root 8564 Dec 11 2016 iso9660_stage1_5 -rw-r--r-- 1 root root 10208 Dec 11 2016 jfs_stage1_5 -rw-r--r-- 1 root root 8724 Dec 11 2016 minix_stage1_5 -rw-r--r-- 1 root root 11252 Dec 11 2016 reiserfs_stage1_5 -rw-r--r-- 1 root root 512 Dec 11 2016 stage1 -rw-r--r-- 1 root root 118712 Dec 11 2016 stage2 -rw-r--r-- 1 root root 118712 Dec 11 2016 stage2_eltorito -rw-r--r-- 1 root root 8852 Dec 11 2016 ufs2_stage1_5 -rw-r--r-- 1 root root 8212 Dec 11 2016 vstafs_stage1_5 -rw-r--r-- 1 root root 10874 Dec 11 2016 xfs_stage1_5 **** WARNING **** **** WARNING **** **** WARNING **** I have not yet been able to test the build to see if it will actually boot because my machine is still working its way through the monster world rebuild after switching to the 17.0 profile and that will be going on for a several more hours. However I did do a binary diff of stage1 to that from the previous build and they are identical.
(In reply to acmondor from comment #14) > I think I have got a patch for the issue(s) with gcc6. > > > # cat /etc/portage/patches/sys-boot/grub-0.97/grub-0.97-piex.patch > --- grub-0.97/configure.ac 2017-12-11 10:48:19.529910979 -0600 > +++ grub-0.97x/configure.ac 2017-12-11 10:54:39.347763206 -0600 > @@ -122,8 +122,9 @@ > grub_cv_cc_fpie=no) > ]) > if test "x$grub_cv_cc_fpie" = xyes; then > - STAGE1_CFLAGS="$STAGE1_CFLAGS -no-pie" > - STAGE2_CFLAGS="$STAGE2_CFLAGS -no-pie" > + STAGE1_CFLAGS="$STAGE1_CFLAGS -fno-pie" > + STAGE2_CFLAGS="$STAGE2_CFLAGS -fno-pie" > + LDFLAGS="$LDFLAGS -no-pie" > fi > fi > fi > > > With the above patch the build is successful and the resultant sizes of > stage1 and stage2 are like they should be: > > # ls -l /lib/grub/i386-pc > total 352 > -rw-r--r-- 1 root root 9972 Dec 11 11:17 e2fs_stage1_5 > -rw-r--r-- 1 root root 9204 Dec 11 11:17 fat_stage1_5 > -rw-r--r-- 1 root root 8532 Dec 11 11:17 ffs_stage1_5 > -rw-r--r-- 1 root root 8532 Dec 11 11:17 iso9660_stage1_5 > -rw-r--r-- 1 root root 10144 Dec 11 11:17 jfs_stage1_5 > -rw-r--r-- 1 root root 8724 Dec 11 11:17 minix_stage1_5 > -rw-r--r-- 1 root root 11220 Dec 11 11:17 reiserfs_stage1_5 > -rw-r--r-- 1 root root 512 Dec 11 11:17 stage1 > -rw-r--r-- 1 root root 118456 Dec 11 11:17 stage2 > -rw-r--r-- 1 root root 118456 Dec 11 11:17 stage2_eltorito > -rw-r--r-- 1 root root 8788 Dec 11 11:17 ufs2_stage1_5 > -rw-r--r-- 1 root root 8180 Dec 11 11:17 vstafs_stage1_5 > -rw-r--r-- 1 root root 10842 Dec 11 11:17 xfs_stage1_5 > > For comparison my previous build (sys-boot/grub-0.97-r16 built with > sys-devel/gcc-5.4.0-r3) looked like this: > > # ls -l /lib/grub/i386-pc > total 356 > -rw-r--r-- 1 root root 10036 Dec 11 2016 e2fs_stage1_5 > -rw-r--r-- 1 root root 9236 Dec 11 2016 fat_stage1_5 > -rw-r--r-- 1 root root 8564 Dec 11 2016 ffs_stage1_5 > -rw-r--r-- 1 root root 8564 Dec 11 2016 iso9660_stage1_5 > -rw-r--r-- 1 root root 10208 Dec 11 2016 jfs_stage1_5 > -rw-r--r-- 1 root root 8724 Dec 11 2016 minix_stage1_5 > -rw-r--r-- 1 root root 11252 Dec 11 2016 reiserfs_stage1_5 > -rw-r--r-- 1 root root 512 Dec 11 2016 stage1 > -rw-r--r-- 1 root root 118712 Dec 11 2016 stage2 > -rw-r--r-- 1 root root 118712 Dec 11 2016 stage2_eltorito > -rw-r--r-- 1 root root 8852 Dec 11 2016 ufs2_stage1_5 > -rw-r--r-- 1 root root 8212 Dec 11 2016 vstafs_stage1_5 > -rw-r--r-- 1 root root 10874 Dec 11 2016 xfs_stage1_5 > > > **** WARNING **** **** WARNING **** **** WARNING **** > > I have not yet been able to test the build to see if it will actually boot > because my machine is still working its way through the monster world > rebuild after switching to the 17.0 profile and that will be going on for a > several more hours. > > However I did do a binary diff of stage1 to that from the previous build and > they are identical. Just a quick note to say that I just had a chance to test my above mentioned patch and all is well. My machine rebooted fine with sys-boot/grub-0.97-r17 (~amd64) built with sys-devel/gcc-6.4.0 and the above mentioned patch on the default/linux/amd64/17.0/desktop profile.
> + LDFLAGS="$LDFLAGS -no-pie" Is the important line. I'll prepare a rev bump, thanks!
(In reply to Thomas Deutschmann from comment #16) > > + LDFLAGS="$LDFLAGS -no-pie" > > Is the important line. I'll prepare a rev bump, thanks! That is correct. I originally changed -no-pie to -fno-pie in the CFLAGS because some testing in a simple hello world program revealed that -no-pie had no effect during the compilation step whereas -fno-pie did. Then when I discovered the above mentioned LDFLAGS change I didn't go back to see if the CFLAGS change was actually required. I just did another test and can confirm that my CFLAGS change (-no-pie to -fno-pie) is not required. That is, my patch now this: # cat /etc/portage/patches/sys-boot/grub-0.97/grub-0.97-piex.patch --- grub-0.97/configure.ac 2017-12-12 07:57:37.131567040 -0600 +++ grub-0.97x/configure.ac 2017-12-12 07:59:46.710603773 -0600 @@ -124,6 +124,7 @@ if test "x$grub_cv_cc_fpie" = xyes; then STAGE1_CFLAGS="$STAGE1_CFLAGS -no-pie" STAGE2_CFLAGS="$STAGE2_CFLAGS -no-pie" + LDFLAGS="$LDFLAGS -no-pie" fi fi fi
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=750afd3aecf8d3bc320aa69f251130fe6959750a commit 750afd3aecf8d3bc320aa69f251130fe6959750a Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2017-12-14 11:58:00 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2017-12-14 11:59:46 +0000 sys-boot/grub: Fix build against 17.0 profile Ebuild changes: =============== - EAPI bumped to EAPI=6 - Sanity check for stage2 added Bug: https://bugs.gentoo.org/608460 Package-Manager: Portage-2.3.18, Repoman-2.3.6 sys-boot/grub/Manifest | 1 + sys-boot/grub/grub-0.97-r18.ebuild | 317 +++++++++++++++++++++++++++++++++++++ 2 files changed, 318 insertions(+)}
Should be fixed in >=sys-boot/grub-0.97-r18. Please report back if it works for your or not so that we know when we can proceed with stabilization.
I can confirm, that upgrading to grub-0.97-r18 fixed all issues.
0.97-r18 does not compile for me. Attaching build.log.
It won't let me attach the build.log. The size is not the issue. So, here are the last lines: ../netboot/libdrivers.a(3c509.o):/var/tmp/portage/sys-boot/grub-0.97-r18/work/grub-0.97/netboot/timer.h:53: first defined here ../netboot/libdrivers.a(libdrivers_a-timer.o): In function `waiton_timer2': /var/tmp/portage/sys-boot/grub-0.97-r18/work/grub-0.97/netboot/timer.h:58: multiple definition of `waiton_timer2' ../netboot/libdrivers.a(3c509.o):/var/tmp/portage/sys-boot/grub-0.97-r18/work/grub-0.97/netboot/timer.h:58: first defined here collect2: error: ld returned 1 exit status
We need full build.log and "emerge --info" output. If you cannot attach for some reason, send me an email with your gzip'ed build.log and "emerge --info" output.
Created attachment 510336 [details] build.log for 0.97-r18 failed compiling build.log for failed build.
Created attachment 510338 [details] emerge --info for 0.97-r18 failed compiling Attached emerge --info.
Thanks, confirmed. grub[netboot] is failing. I created a new bug 641412.
