When emerging grub-static on amd64, the ebuild installs inspite of this message: * Checking for suitable kernel configuration options... * CONFIG_IA32_EMULATION: is not set when it should be. Besides, there is also this:* QA Notice: Pre-stripped files found: * /sbin/grub * /bin/mbchk AND this: grub bash: /sbin/grub: cannot execute binary file AND this: bzip2: /var/tmp/portage/sys-boot/grub-static-0.97-r9/distdir/grub-static-0.97-r9.tar.bz2: trailing garbage after EOF ignored You don't suppose there would be quality control at all @Gentoo. Reproducible: Always Steps to Reproduce:
Created attachment 212719 [details] output of emerge --info =sys-boot/grub-static-0.97-r9
I am only a gentoo *user*, but reading (by mere accident) such a stupid bug report - even marked as critical and equipped with an insult - makes me so angry that I have to say something. It is such stupid reports which make the developers sometimes also close sane requests and reports. Really, if you have no idea about your system then don't use gentoo; everything you mention is completely valid and *desired* behavior: You installed a 32 bit binary with a kernel which is not able to run such binaries. There are many reason why one might want to do this: You might currently be running a test kernel or a virtual environment, or might want to use the binary only from a boot disk or for security reasons only from a special kernel or or or... emerge even warns you that the binary you installed will probably not be running according to your kernel configuration, so concerning your insult: The message shows quite the opposite, namely that quality control is perfectly working here. Gentoo just (gladly) doesn't prevent you from shooting in your foot if you want to. So you do not need nasty workarounds if you have some of the many reasons to install a binary with a kernel which cannot run this binary: This freedom is one of gentoo's main advantages. If you are not able to handle it, switch to a distribution which does not allow you to do anything unexpected. > bash: /sbin/grub: cannot execute binary file So the detection was right, your kernel cannot run the binary. > QA Notice: Pre-stripped files found Yes, binary files are pre-stripped, which is what every sane person would expect; so you will not be able to run a debugger on the source or do similar things with these files even if you would attempt to prevent stripping, and this message tells you this. Again it shows: Quality control is working perfectly here. > trailing garbage after EOF ignored Yes, the additional information contained at the end of tar.bz2 tarballs is ignored for the unpacking phase. So what? Again, it is an advantage that such informal messages are displayed instead of being suppressed and thus possibly some problems are hidden from the user.
why did you CC me? The metadata states this package is managed by amd64.
1. Your kernel is mis-configured for this grub. You ignored the warning, it's deliberately not fatal because it's perfectly possible to build it on a system where you aren't going to run it, and run it somewhere where it's valid. 2. The files are pre-stripped because we distribute a binpkg that we build with the normal ebuild. I've suppressed them now. 3. The EOF/trailing garbage warning is similar, but it's really NOT garbage, it's valid data, just not used for this purpose. Despite this, I've added a different check to the ebuild, so if you TRY to install+run it on a system without IA32_EMULATION, it will give you a fatal error now.
(In reply to comment #4) > 1. Your kernel is mis-configured for this grub. You ignored the warning, it's > deliberately not fatal because it's perfectly possible to build it on > a system where you aren't going to run it, and run it somewhere where > it's valid. It happened that I didn't ignore that warning. grub-static was once emerged during a semi-automatic install some time ago. Then the kernel was updated and immediately reconfigured to exclude IA32 support. Then, much later, emerge --update world did run, and your package did update stage2 in boot, accompanied by the dire warning that one must run grub (or grub-install, something like that), else the system would be unbootable. Running grub wasn't an option because the running kernel did not contain IA32 support. What would you had done in this situation? Well, renaming stage2.old. I decided to switch to lilo. > 2. The files are pre-stripped because we distribute a binpkg that we build with the normal ebuild. I've suppressed them now. I have splitdebug and installsources in FEATURES. So simply suppressing this messages supresses a Gentoo QA message. Stripping is done automatically by the prestrip ebuild helpers the moment the package gets merged, saving debug information and source files on the fly. > 3. The EOF/trailing garbage warning is similar, but it's really NOT garbage, > it's valid data, just not used for this purpose. the bzip2 message sounded like the archive was somehow corrupted. I don't feel exactly comfortable if this happens with the source for a package which is going to write to a raw device: root kits, anyone? > Despite this, I've added a different check to the ebuild, so if you TRY to > install+run it on a system without IA32_EMULATION, it will give you a fatal > error now. Well, how do you +run an ebuild? My proposal is this: if you install into host root, grub-static should'nt mount /boot automatically and alter stages in /boot/grub without user intervention. May be you would like move all this into pkg_config, which is only run when USE=-config is given, much like you do already do for USB disks. Someone has closed this bug. Reopening. @Robin: I cc'ed you because your remark in ChangeLog: 04 Jul 2009; Robin H. Johnson <robbat2@gentoo.org> grub-static-0.97-r9.ebuild: Bug #255271: check for IA32_EMULATION on 64-bit, as we are building a 32-bit binary and need to be able to run it.
I closed the bug as one of the sys-boot/grub-0* (legacy GRUB) maintainers, please don't reopen it unless something is actually broken. (In reply to comment #5) > (In reply to comment #4) > > 1. Your kernel is mis-configured for this grub. You ignored the warning, it's > > deliberately not fatal because it's perfectly possible to build it on > > a system where you aren't going to run it, and run it somewhere where > > it's valid. > > It happened that I didn't ignore that warning. grub-static was once emerged > during a semi-automatic install some time ago. Then the kernel was updated and > immediately reconfigured to exclude IA32 support. Then, much later, emerge > --update world did run, and your package did update stage2 in boot, accompanied > by the dire warning that one must run grub (or grub-install, something like > that), else the system would be unbootable. Running grub wasn't an option > because the running kernel did not contain IA32 support. What would you had > done in this situation? Well, renaming stage2.old. I decided to switch to lilo. The system would INDEED be unbootable due to changes in grub's stage2 as we have patched bugs, but why did your running kernel not contain IA32 support if you were using grub-static? Using lilo is a perfectly acceptable option here. Keeping grub and turning off IA32 is not. > I have splitdebug and installsources in FEATURES. So simply suppressing this > messages supresses a Gentoo QA message. Stripping is done automatically by the > prestrip ebuild helpers the moment the package gets merged, saving debug > information and source files on the fly. The "distfile" for grub-static is a binpkg of sys-boot/grub, already stripped, and built without splitdebug. -r10 may bring in splitdebug again on it, but there have been prior bugs with it, as well as complaints of wanting a smaller distfile. > > 3. The EOF/trailing garbage warning is similar, but it's really NOT garbage, > > it's valid data, just not used for this purpose. > the bzip2 message sounded like the archive was somehow corrupted. I don't feel > exactly comfortable if this happens with the source for a package which is > going to write to a raw device: root kits, anyone? bzip2 rejected the content at the end. it's a block based streaming format for that reason. Corruption looks different, bzip2 will actually halt as it has checksums on the compressed blocks. > > Despite this, I've added a different check to the ebuild, so if you TRY to > > install+run it on a system without IA32_EMULATION, it will give you a fatal > > error now. > Well, how do you +run an ebuild? My proposal is this: if you install into host > root, grub-static should'nt mount /boot automatically and alter stages in > /boot/grub without user intervention. May be you would like move all this into > pkg_config, which is only run when USE=-config is given, much like you do > already do for USB disks. This is ALREADY selectable, via mount-boot.eclass. elog "To avoid automounting and auto(un)installing with /boot," elog "just export the DONT_MOUNT_BOOT variable."
(In reply to comment #6) > I closed the bug as one of the sys-boot/grub-0* (legacy GRUB) maintainers, > please don't reopen it unless something is actually broken. Well, won't do, though I still consider a package to be broken which is going to break an entire system. When it happened, it wasn't even my own. > (In reply to comment #5) > > (In reply to comment #4) > > > 1. Your kernel is mis-configured for this grub. You ignored the > > > warning, it's deliberately not fatal because it's perfectly possible > > > to build it on a system where you aren't going to run it, and run > > > it somewhere where it's valid. > > > > It happened that I didn't ignore that warning. grub-static was once emerged > > during a semi-automatic install some time ago. Then the kernel was > > updated and immediately reconfigured to exclude IA32 support. Then, > > much later, emerge --update world did run, and your package did > > update stage2 in boot, accompanied by the dire warning that one must > > run grub (or grub-install, something like that), else the system would > > be unbootable. Running grub wasn't an option because the running kernel > > did not contain IA32 support. What would you had done in this situation? > > Well, renaming stage2.old. I decided to switch to lilo. > The system would INDEED be unbootable due to changes in grub's stage2 as we > have patched bugs, but why did your running kernel not contain IA32 > support if you were using grub-static? Using lilo is a perfectly > acceptable option here. > Keeping grub and turning off IA32 is not. Re why using grub at all: As I said, grub came into play much like an unwanted guest, but behaved nicely until I did run "emerge --update world" trying to analyze a severe bug in ld which left KDE in an unusable state (see #295765) Again, grub isn't like any ordinary package which may fail at will. There are sound reasons to turn off IA32 support. Once turned off, you are in a catch22 situation when an automatic update of these grub binaries in /boot/grub weighs in. Moving to lilo was easy to do in that case, but there are people running unconventional setups with a bunch of unusual disk adapaters and buggy Bioses involved. > > I have splitdebug and installsources in FEATURES. So simply suppressing > > this messages supresses a Gentoo QA message. Stripping is done > > automatically by the prestrip ebuild helpers the moment the package > > gets merged, saving debug information and source files on the fly. > The "distfile" for grub-static is a binpkg of sys-boot/grub, > already stripped, and built without splitdebug. -r10 may bring in > splitdebug again on it, but there have been prior bugs with it, > as well as complaints of wanting a smaller distfile. I see these complaints conflicting with Gentoo's general concept here, which basically is having the sources at hand. And shouldn't binary packages reside in /opt? > > > 3. The EOF/trailing garbage warning is similar, but it's really > > > NOT garbage,it's valid data, just not used for this purpose. > > the bzip2 message sounded like the archive was somehow corrupted. I > > don't feel exactly comfortable if this happens with the source for > > a package which is going to write to a raw device: root kits, anyone? > bzip2s rejected the content at the end. it's a block based streaming > format for that reason. Corruption looks different, bzip2 will actually > halt as it has checksums on the compressed blocks. Sure, but as I read elsewhere, the signature chain protecting packages the Gentoo relies upon isn't that tamper proof. If someone wanted to spread a root kit, he probably w'd target binary packages and welcome warning commonly regarded as insignificant as a neat cover, simply fixing bzip2 checksums. > > > Despite this, I've added a different check to the ebuild, so if you > > > TRY to install+run it on a system without IA32_EMULATION, it will > > > give you a fatal error now. So you changed the ebuild and still closed this bug the second time now ... May I please test your modifications? > > Well, how do you +run an ebuild? My proposal is this: if you install > > into host root, grub-static should'nt mount /boot automatically and > > alter stages in /boot/grub without user intervention. May be you would > > like move all this into pkg_config, which is only run when USE=-config > > is given, much like you do already do for USB disks. duh, have to correct what I wrote here: "emerge --config" would call pkg_config > This is ALREADY selectable, via mount-boot.eclass. > elog "To avoid automounting and auto(un)installing with /boot," > elog "just export the DONT_MOUNT_BOOT variable." Robin, entries in logs are a nice thing to have. But packets manipulating the system boot loader should be ultimately robust. There is a reason why there exists (well, except in Gentoo) sln, a static version of ln. If all else blows, static versions should work. But you can't deduce from sys-boot/grub-static package's description that this a binary package running only on IA32. When you finally realize it, it's already too late to export DONT_MOUNT_BOOT. One could do it the other way round: call the user to export MOUNT_BOOT, but enforcing "emerge --config" would be a neat solution. Looking closer into sys-boot/grub-static-0.97-r9.ebuild, there is another inconsistency. You actually change stage2 while you keep saying stage2 will be the old version until grub-install is run. Maybe I'm missing something here, and maybe the system still would have been bootable in the first place, as /sbin/grub didn't wasn't able to run at all? if [[ -e ${dir}/stage2 ]] ; then mv "${dir}"/stage2{,.old} ewarn "*** IMPORTANT NOTE: you must run grub and install" ewarn "the new version's stage1 to your MBR. Until you do," ewarn "stage1 and stage2 will still be the old version, but" ewarn "later stages will be the new version, which could" ewarn "cause problems such as an unbootable system." ewarn "This means you must use either grub-install or perform" ewarn "root/setup manually! For more help, see the handbook:" ewarn "http://www.gentoo.org/doc/en/handbook/handbook-${ARCH}.xml?part=1&chap=10#grub-install-auto" ebeep fi
