Here is the ebuild for grub-0.96. I've fixed splash patch to work with this version of grub. BTW. grub-0.94-splash.patch.bz2 is very dirty. We do not need orig files inside... Reproducible: Always Steps to Reproduce:
Created attachment 50315 [details] This is the ebuild
Created attachment 50316 [details, diff] patch to modify all menu.lst into grub.conf
Created attachment 50317 [details, diff] Patch to remove -fwritable-strings that are deprecated.
Created attachment 50318 [details] Modified patch for splash screen.
Did you send these patches upstream and were they approved?
Can anybody explain me this strange sequence inside of ebuild: autoconf then aclocal then automake. I thought the we need first run aclocal then automake and then autoconf. BTW. Why not to use autoreconf?
No. I have not. Sorry. I don't know what is upstream. I've do my best to test this ebuild on my system. What is upstream?
upstream is http://www.gnu.org/software/grub upstream is where the original source comes from, where do you have your patches (which were not already in earlier ebuild versions) from?
Created attachment 50319 [details] Modified ebuild to contain actual ~arch. Sorry. Previous version of ebuild contains wrong ACCEPT_KEYWORDS.
Hm. This is the link for source code. ftp://alpha.gnu.org/gnu/grub/ Patches I took from grub-0.94 ebuild and modified some of them to be cleanly applied for grub-0.96. (some applied cleanly).
A search on bugzilla shows >20 open bugs on grub; most are about problems with the ebuild scripts, at least some of which are still extant in this proposed ebuild. It's probably best to wait for these to be sorted out, then create a 0.96 ebuild from that. See open bugs: bug #63445, bug #69726, bug #71717, bug #71811, bug #72196, bug #72795, bug #73499, bug #74274, bug #74825, bug #76143, bug #76995, bug #77516, bug #79219, bug #79355, bug #79378, bug #79734, bug #80144, bug #80422, bug #80693 also recently resolved bugs: bug #70111, bug #73156, bug #73419, bug #74513, bug #76160, bug #76347, bug #78549
here's an ebuild that (hopefully) fixes a lot of the bugs Kevin pointed out: fixed: - savedefault (bug #63445) now working according to the grub changelog. (please test) - address 2000/hardened errors. (bug #69726 bug #79734 bug #74825 bug #74825 bug #79734 bug #80144 bug #80422) - failing makecheck (bug #71811). patch included. - BLOCK_SIZE="human readable" in the env kills the compile. fixed in ebuild. (bug #73499 & bug #82217) added: - i2o block device support by request of Christian Zoffoli (bug #76143) - gfxboot support - also working on adding reiser4 support, but the splash patch is causing some difficulties. right now, so you can have either one or the other - splash is the default, but i'm including my reiser4 patch if anyone wants to play with it. ;] - grub can now be compiled PIC, thanks to solar (bug #79734) PS. thanks for doing the patch updates volkov. saved me a lot of time.
Created attachment 51439 [details] new grub ebuild
Created attachment 51440 [details, diff] Position Independant Code
Created attachment 51441 [details, diff] patch to have maketest pass.
Created attachment 51442 [details, diff] enables gfxboot support
Created attachment 51443 [details, diff] fix symlinks patch
Created attachment 51444 [details, diff] support for i2o block devices
Created attachment 51445 [details, diff] experimental reiser4 patch
Created attachment 51446 [details, diff] suppress warnings of depreciated functions.
Thank you Ryan. Two notes: 1. Three days ago I finished recompilation of my system from scratch (emerge -e world). Although before, grub check fails, now everything *works*! So it's not necessary to apply grub-0.96-bounced-checks.patch. May be someone else can test this? 2. Yes. Savedefault is not working. But I can not see anything in Changelog except this: 2001-02-02 OKUJI Yoshinori <okuji@gnu.org> Make savedefault workable even with Stage 1.5. Reported by Thierry Laronde <thierry@cri74.org>.
1) This: BLOCK_BACKUP="$BLOCK_SIZE" unset BLOCK_SIZE in global scope with this: export BLOCKSIZE="$BLOCK_BACKUP" at the end seems a bit odd. Perhaps an ebuild expert could comment, but it looks to me like it ought to be in src_compile() and perhaps a src_test() function. 2) On hardened, the netboot stuff fails - at this point due to non-PIC asm in netboot/main.c, and probably in netboot/pci.c (both of which clobber BREG). It'll take an asm patch to fix it, which I can do, but it'll take a little time. I would suggest worrying about that later though; no-one has bugged before about netboot on hardened, so perhaps no-one that uses hardened uses netboot yet. 3) I also got: /usr/lib/portage/bin/ebuild.sh: line 1858: 19306 Killed /sbin/grub --batch --device-map=/boot/grub/device.map </boot/grub/grub.conf >/dev/null 2>&1 reported during the merge phase. For some reason /sbin/grub has 'E' in its pax flags; changing the paxctl/chpax lines to '-spme' to allow emulation of trampolines stops it being killed. Also, I think paxctl should be tried first before chpax, as paxctl settings are used by kernels that have both types of flags configured in preference to chpax flags. 4) I'm not sure what running /sbin/grub like it is in the ebuild is supposed to achieve. Installing the boot sector needs different commands than exist in a live grub.conf, and is probably something best left to the user as it's easy to hose the system. Perhaps this should be removed? 5) On style, I think it's preferred to use '[[' rather than '['; this is simple to change, apart from swapping [ for [[ and ] for ]], just line 134 needs '&&' instead of '-a'. Also a number of lines start with spaces instead of tabs; if you're a vi user and have gentoo-syntax emerged, vi will show these highlighted.
Created attachment 51491 [details, diff] Modified PIC patch to cater for systems with start/end instead of _start/_end I don't know if any gentoo systems have start/end instead of _start/_end, but this adjustment to the PIC patch should cater for them.
volkov: i checked it myself many times when i was trying to figure out the BLOCK_SIZE bug. i can say for certain that it's still a problem, at least for some users. ;) kevin: 1) oh, i completely forgot about src_test(). yes that works. the problem i was having is that it would give false passes in the testing phase unless made a env variable. i pulled the idea from the firefox ebuild which does something similar, but this is much cleaner. 2) cool with me, but ultimately up to the maintainer i suppose. 3) you lost me at paxctl/chpax ;d i honestly know nil about hardened systems. feel free to jump in if you have the time. =] 4) me either. i kinda just warily sidestepped past the entire pkg_postinstall() section. i'll poke at a bit over the weekend. 5) thanks for the tips. i guess i had to learn vim at some point, might as well get it over with ;] also i'm going to pull reiser4 completely out of the build, due to Rob's comment on bug #69590.
Comment on attachment 51445 [details, diff] experimental reiser4 patch not ready for prime-time.
w.r.t. paxctl & chpax; I don't think there's a significant reason not to set both paxctl and chpax, so simply changing having two lines: [[ -x /sbin/paxctl ]] && /sbin/paxctl -spme /sbin/grub [[ -x /sbin/chpax ]] && /sbin/chpax -spme /sbin/grub is ok, indeed it's probably better. It might just be the "||:" in your ebuild on the end of the chpax line isn't supposed to be there - when I glanced at it I thouhgt perhaps it was trying to avoid paxctl if chpax succeeded, but now I look again it's probably just a typo (or cut-n-paste-o).
chpax should end w/ ||: , it is a running kernel issue, if EI_PAX is not enabled it fails
I have gotten also a curious result w/ hardened, gcc-3.3.5 + ssp catches a stack smashing in password_func(), interestingly gcc-3.4.3 + ssp does not find any, so it could be a false alarm. if grub is built w/ gcc-3.3.5 and grub.conf has a (md5) password, then running grub in pkg_postint will segfault
Created attachment 51633 [details] ebuild #3 give this a try. it builds and boots for me with the gcc 3.4.3-20050110 hardened config, both with USE="netboot" and without. static works, and the splash, but anything else i can't test from here. i left the bit at the end because honestly i don't know what it's there for and i don't want to break something by removing it. ;]
Created attachment 51634 [details] patch tarball here's a tarball of my grub/files, to cut down on the confusion and patches getting mixed up.
Created attachment 51660 [details, diff] ebuild diff to allow building w/ use pic && netboot the ebuild diff is not for final consumption, only show what and how I modified to allow building if USE="pic netboot", disabling auto -fPIE for 2 files I have moved -C to myconf, and added more comments to pkg_postinst, disabling the grub --batch run
The reiser4 patch seems to be broken. The latest Hill ebuild doesn't use it.. Has anyone got the combo grub 0.96 & libaal 1.0.4 & reiser4progs 1.0.4 along with grub-0.96-reiser4-20040130.diff (or LATEST_GRUB) from namesys ftp working? I have the full grub-0.95 tarball from namesys running at the moment, but it won't boot kernels larger than a certain size.
Ryan - a suggestion - mark this bug as blocking all the ones you're fixing with this ebuild (i.e. enter their numbers into the "Bug 80693 blocks" box and commit). Then all those other bugs will have an indication that this bug is taking them into account, also pointing users watching those bugs to this one.
i don't see blocks/depends used much on here. i find when i do use them it tends to generate a huge amount of mail, so i avoid it. i will leave a comment on them though when we have a prospective finished ebuild which should be pretty quick. peter, thanks for the update. i'll take a look tonite. i was able to track down the password/SSA bug and recreate it in gcc 3.4.3.20050110. when grub is run at then end of the ebuild and you have a password line in your grub.conf, grub will prompt the user for the password, even in --batch mode. if the next line of your grub.conf happens to be 32 characters or more in length, it triggers SSP. this happens both with and without --md5. #cat grubSSA-ex4 grub> grub> password xxxxxxx Password: #234567890123456789012345678901 Error 32: Must be authenticated # cat grubSSA-ex5 grub> grub> password xxxxxxx Password: #2345678901234567890123456789012 grub: stack smashing attack in function password_func() Aborted so i agree, that line is gone. re comment #33: see bug #69590.
We could make `cat /boot/grub/device.map` and show the content to the user, waiting some time and warning, so he could check if the device list is correct and also check for password line in grub.conf and dont run it then If grub is updated (as I did by adding the raid patch to the ebuild and rebuild) and grub --batch is not run, due to (probably) the changed stage2, it wont boot so running it would be wise, but how to really guard against faulty device.map?
after doing some reading, it looks like all that's needed from grub.conf is the "root" line. http://www.gnu.org/software/grub/manual/html_node/Installing-GRUB-natively.html#Installing%20GRUB%20natively http://www.gnu.org/software/grub/manual/html_node/Installation-under-UNIX.html#Installation%20under%20UNIX if [[ -e /boot/grub/grub.conf ]] ; then [[ -e /boot/grub/grubsetup ]] && rm /boot/grub/grubsetup grep "^root" /boot/grub/grub.conf > /boot/grub/grubsetup /sbin/grub --batch --device-map=/boot/grub/device.map \ < /boot/grub/grubsetup > /dev/null 2>&1 rm /boot/grub/grubsetup echo enote "Grub has been set up according to existing configuration" enote "found in /boot/grub/grub.conf." echo else echo ewarn "If this is the first emerge of grub, don't forget to install" ewarn "it into MBR or the active partition using grub-install or the" ewarn "grub shell, as described in the Gentoo Handbook." ewarn ewarn "Failure to do so will result in a nonbootable system." echo ?
looks like this went into portage without us. =P
there's still a problem with grub-0.96 and "savedefault": https://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=12018
Yeah, sorry guys - I should have checked here first. Could you guys please have a look at what is in portage now (there are some cleanups to parts - pkg_postinst()'s copying of files to /boot/grub for example) and just merge the good parts, and I will add your new stuff? Thanks.
With the patch which disables -fwriteable-strings I get a segmentation fault when trying to do "find /boot/grub/stage1" in grub's interactive shell.
Created attachment 52976 [details, diff] Allow operation with >2GB RAM
Grub 0.95.20040823 fails on systems with > 2GB of RAM. These errors remain unfixed in 0.96. The included patch, applicable to both versions, has been tested successfully on a system with 4GB of RAM.
azarah, np. i'm getting everything together and will submit an update against the build in portage before too long. i'm also checking w/ upstream on some of the patches, as they're things that really should be fixed. pcgod: prob best to file a new bug for that w/ your pc info. i can't reproduce here.
Created attachment 53009 [details, diff] Reiser4 for grub-0.96 This patch is intended to be applied after applying the warnings- and splash-patch (AFTER!!). So the ebuild is easy to modify.
reiser4 is not going into grub until it's accepted upstream or stops breaking things. sorry. here's what i want to submit. changes since the last one include a patch by peter jones which fixes a number of memory issues and fixes the issue of segfaulting on AMD64 systems that have the NX bit set. should also work on x86_64 if in the future that arch is added. psx, do you have any updated work on PIC? i noticed there was a cvs-patch in your last post that i haven't seen. this compiles fine on hardeneed gcc 3.4.3 but dies with an address 2000 error during config with hardened gcc 3.3.5-20050130. it looks like it's skipping has_ssp on that version. anyone know why / have a workaround? once that's fixed, this is ready (finally). =D Andreas, i want to include that patch but it dies horribly w/ the nxstack patch applied. any chance you could get me a diff -u against the patched code?
Created attachment 53147 [details] grub-0.96-r1_rc1 ebuild and by psx i meant psm. *^_^*
Created attachment 53148 [details] grub-0.96-r1_rc1 patches
the 2000 address "bug" is opjcopy failing, it is sure that has_ssp fails for some reason, it could be string 2005xxxx in gcc`s version? maybe remove has_ssp I am building almost all the time against current cvs, but it was not intended to push it into the ebuild, the rest of that ebuild was relevant If you want to, I could do a diff though.
nope that's fine, just wanted to check. making the objcopy cache unconditional works great as well. looks like this is done. setting blocks on the following open bugs: #83065 - grub should not RDEPEND on autoconf or automake #80422 - grub-ebuild does not change CFLAGS when using hardened gcc 3.3.5 #80144 - grub 0.94-r1 did not emerge, but gave an error and a config.log #79734 - grub fails econf on new hardened system #76143 - grub doesn't boot from an i2o raid card #73499 - grub ebuild fails when BLOCK_SIZE=human_readable set in environment #71811 - >=sys-boot/grub-0.94-r1 fail maketest - "ffs_stage1_5 is too big"
Created attachment 53157 [details, diff] grub-0.96-r1_final.ebuild diff
0.96 is in portage, is this bug still applicable ?
this was originally going to be 0.96 but it got added to portage before this bug was done. see comment #40. the final product takes that into account, so i guess it would be grub-0.96-r1.
ok, ive added 0.96-r1 with a bunch of these fixes ... could you review and update the attachments / buglist ?
bug #73499 is fixed, but you'll still get a false positive during test if BLOCK_SIZE=human_readable. that's not mentioned in the bug, just something i found while testing. bug #76143 & bug #83065 fixed. you added the comment about -fno-stack-protector detection, but none of the changes it describes except 'echo "grub_cv_prog_objcopy_absolute=yes" > config.cache'. that's just one small bit of it. for #79734 to be fixed, the rest of our changes would probably have to go through too (unset CFLAGS, don't append -DNDEBUG, compile lib-drivers -no-pic, econf with -C, run the chpax & paxctl lines, etc). as is, grub will not build on a hardened system. also removed bugs since closed.
Is there any reason why we can't have a reiser4 local USE flag? It is a better option than outright rejection of the patch.
i missed the src_test()/netboot-pic parts ... added src_test() fix cant the netboot portion be fixed with a patch to the relevant files ? all you need is just some '#ifdef __PIC__' lovin ... i changed the config.cache part to just export the variable ... that way configure will pick it up w/out a cache why does -DNDEBUG cause problems ? in your last attachment i didnt see any paxctl lines ...
> # hardened voodoo > [[ -x /sbin/chpax ]] && /sbin/chpax -spme /sbin/grub ||: > [[ -x /sbin/paxctl ]] && /sbin/paxctl -spme /sbin/grub lines 162-164 of my last ebuild (comment #47). -DNDEBUG causes problems with hardened for some reason i can't honestly say i understand 100%. with it enabled, the build will fail during linking with hundreds of ": undefined reference to `__guard'". during the regular grub make i think that 'CFLAGS=${CXXFLAGS}' should instead be 'CFLAGS=""' (line 107 of the build currently in CVS). grub shouldn't be built with any CFLAGS set whatsoever, for reasons both listed in the ebuild "### i686-specific code in the boot loader is a bad idea", and the extreme fragility of this software to CFLAGS. you're right about configure picking up the cache w/o -C. looks good. if you're concerned about disabling the tests for bsd systems (grub-0.96-bounced-checks.patch, bug #71811), it's what the developer of grub recommends. http://lists.gnu.org/archive/html/bug-grub/2004-05/msg00098.html, http://lists.gnu.org/archive/html/bug-grub/2004-05/msg00093.html. the netboot pic stuff probably could be fixed with some hackery, but i'm pretty much just a bash-monkey. :D there's been reports the reiser4 patch prevents grub from booting kernels over a certain size. besides, it's kind of silly to have support in grub when it's not supported in the kernel. a r4 /boot partition seems kind of insane to me, but that's just my opinion. is there anything in particular wrong with the ebuild as submitted? it's been tested by many and seems to work fine in every situation so far.
removed the -DNDEBUG CFLAGS arent a problem since we do 'unset CFLAGS' above it ;) that URL reference is perfect, thanks ... added test patch in reiser4 will be added once it's added to mainline kernel other than the pic thing for USE=netboot, is there anything else i missed ? (sync up and check 0.96-r1 again) the only reason i just dont rip and add your ebuild is because ive never dealt with grub before so i only add what i'm sure about ... our grub maintainer took off and we dont know where he went
the problem w/ user defined CFLAGS is (as I commented some time ago in the ebuild) following: configure w/o any user provided CFLAGS detects correctly the presence of ssp and disables it for stage2 building if someone provides CFLAGS to configure, configure is so dumb, that it overwrites its own -fno-stack-protector for stage2, resulting in missing __guard I have reported this upstream I have also reported all the other problems I have encountered, to introduce for ex. an option to configure, disabling all of the nested functions using some replacement (done on purpose as of the ChangeLog), so that chpax/paxctl shouldn't be necessary I haven't gotten on answer yet
vapier: understandable :) i just wanted to make sure, i'm relatively new to this still. other than the pic part for netboot everything looks good to me. oh, missing ||: at the end of [[ -x /sbin/chpax ]] && /sbin/chpax -spme /sbin/grub (see comment #27). otherwise working fine here.
OK, I got an issue with -r1, below is the logs. The only real difference I can see, is the amount of sectors the diff revisions try to embed. I will see later if I can track it to a patch or something. PS: using a striped DM volume as /boot and /. --------------------------- grub-0.96-r1 failing ------------------------------ GNU GRUB version 0.96 (640K lower / 3072K upper memory) [ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename. ] grub> device (hd0,0) /dev/isw0p1 grub> device (hd0) /dev/isw0 grub> root (hd0,0) Filesystem type is ext2fs, partition type 0x83 grub> setup (hd0) Checking if "/boot/grub/stage1" exists... yes Checking if "/boot/grub/stage2" exists... yes Checking if "/boot/grub/e2fs_stage1_5" exists... yes Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 16 sectors are embedded. succeeded Running "install /boot/grub/stage1 (hd0) (hd0)1+16 p (hd0,0)/boot/grub/stage2 /boot/grub/menu.lst"... failed Error 22: No such partition grub> ------------------------------------------------------------------------------- --------------------------- grub-0.96 succeeding ------------------------------ GNU GRUB version 0.96 (640K lower / 3072K upper memory) [ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename. ] grub> device (hd0,0) /dev/isw0p1 grub> device (hd0) /dev/isw0 grub> root (hd0,0) Filesystem type is ext2fs, partition type 0x83 grub> setup (hd0) Checking if "/boot/grub/stage1" exists... yes Checking if "/boot/grub/stage2" exists... yes Checking if "/boot/grub/e2fs_stage1_5" exists... yes Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 23 sectors are embedded. succeeded Running "install /boot/grub/stage1 (hd0) (hd0)1+23 p (hd0,0)/boot/grub/stage2 /boot/grub/menu.lst"... succeeded Done. grub> -------------------------------------------------------------------------------
the ||: is pointless seeing as how nothing checks the return status of that line ive moved the pic stuff to Bug 85566 perhaps the bug you're seeing is due to the grub-0.96-i2o-raid.patch ?
Possibly - can we make it a local USE flag? I will only be able to test tomorrow or tonight.
i dont see why it should be a local USE flag ... the patch doesnt add functionality, it attempts to fix code that is broken under some setups
Boo! Ill check later which patch it is.
Index: sys-boot/grub/grub-0.96-r1.ebuild =================================================================== RCS file: /var/cvsroot/gentoo-x86/sys-boot/grub/grub-0.96-r1.ebuild,v retrieving revision 1.5 diff -u -r1.5 grub-0.96-r1.ebuild --- sys-boot/grub/grub-0.96-r1.ebuild 15 Mar 2005 23:39:52 -0000 1.5 +++ sys-boot/grub/grub-0.96-r1.ebuild 17 Mar 2005 07:07:22 -0000 @@ -83,6 +83,7 @@ export grub_cv_prog_objcopy_absolute=yes #79734 use static && append-ldflags -static + append-flags -DNDEBUG # build the net-bootable grub first, but only if "netboot" is set if use netboot ; then
append-flags should be useless, because we have to ignore any provided CFLAGS as explained earlier. a patch/sed on Makefiles would do it for -DNDEBUG
The append-flags is after the 'unset CFLAGS' (check current CVS), so you really only get CFLAGS=-DNDEBUG. Except if its some other reason I missed due to the ~70 comments here.
setting any CFLAGS will nuke ssp detection by configure, resulting in undefined __guard building stage2. this was already explained twice, and commented in one of the attached ebuilds
Whoops, sorry psm - next time point me to comment #60 ;p
ok, 0.96-r1 has been added to ~arch w/out the raid patch due to az's issues
Its not the raid patch ... Ill wip up a patch later on.
my bad, i thought it was enabled the i2o patch then
This ebuild fails to install the new files into the /boot/grub directory due to exec-prefix=/ (landing in /lib/grub/*/* I propose not installing into /lib, why should those files be on /, it is enough to put them into /usr/lib/grub, those are needed only once, when they are copied to /boot/grub. Currently 2 stage2 files are installed, one in /usr/lib/grub/stage2, the other in /lib/grub/*/
Created attachment 56647 [details, diff] Patch, that helps savedefault feature to work. Seems that with the applied patch savedefault feature works for me. This is upstream patch, and it is already applied on their cvs. So I'm sure there is nothing bad if somebody adds this into gentoo's ebuild.
"our grub maintainer took off and we dont know where he went" Our grub maintainer (me) got a job, then was whisked away to London for several months for a load of training. Without my own computer, without access to non-web-based e-mail, without IRC access...! However... he's back! Some good work gone on here. Hopefully I'll get a chance to look over the stuff that either doesn't work or didn't get added (except the reiser4 stuff) once I get my machine back up and running - everything got hosed when I tried to update it from the last time I used it several months ago.
