When emerging grub-0.96-r1 (currently the grub of choice in portage) finishes up emerging, it gets stuck in copying files from /usr/lib/grub to /boot. There remain a couple of grub processes in the process list after three almost succeeded attempts: >>> original instance of package unmerged safely. * Linking from new grub.conf name to menu.lst * Copying files from /usr/lib/grub to /boot [1]+ Stopped emerge grub rolmops vincentc # bg [1]+ emerge grub & rolmops vincentc # ps -ef | grep grub root 21087 21047 0 09:15 ? 00:00:00 /sbin/grub --batch --device-map=/boot/grub/device.map root 24066 1 0 09:24 ? 00:00:02 /usr/bin/python -O /usr/bin/emerge grub root 28796 28756 0 09:27 ? 00:00:00 /sbin/grub --batch --device-map=/boot/grub/device.map root 28949 28942 0 10:12 ? 00:00:00 grub root 30017 30005 1 15:27 pts/9 00:00:02 /usr/bin/python -O /usr/bin/emerge grub root 2278 2238 0 15:29 pts/9 00:00:00 /sbin/grub --batch --device-map=/boot/grub/device.map root 2292 30005 0 15:30 pts/9 00:00:00 grep grub I say "almost succeeded", because portage reports grub-0.96-r1 as the currently installed version of grub on my system: rolmops vincentc # emerge -pv grub These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] sys-boot/grub-0.96-r1 -debug -netboot -static 0 kB Total size of downloads: 0 kB Reproducible: Always Steps to Reproduce: 1. Emerge grub Expected Results: emerge should finish and give back my system prompt Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.4.20041102-r1, 2.6.11.4 i686) ================================================================= System uname: 2.6.11.4 i686 Pentium III (Coppermine) Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Mar 22 2005, 05:16:04)] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.8.5-r3, 1.5, 1.9.4, 1.6.3, 1.7.9-r1, 1.4_p6 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.14 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=pentium3 -pipe -mmmx -msse -mfpmath=sse -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=pentium3 -pipe -mmmx -msse -mfpmath=sse -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks fixpackages sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X alsa apm avi berkdb bidi bitmap-fonts crypt cups divx4linux emboss encode esd fam flac foomaticdb fortran gdbm gif gnome gpm gtk gtk2 i8x0 imlib ipv6 java jpeg kerberos ldap libg++ libwww mad mikmod mmx motif mozilla mp3 mpeg ncurses nls nptl nvidia ogg oggvorbis opengl oss pam pdflib perl png python quicktime readline real samba sdl spell sse ssl svga tcpd tiff truetype truetype-fonts type1-fonts vorbis xml2 xmms xv xvid zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
forgot to mention: /boot/grub/device.map does not exist
Same problem here. The error occures no matter if /boot is mounted or not.
Some time ago I removed the floppy data cable, because I never used the floppy drive. Now every grub command gets stuck, if not one of the following conditions is true: --device-map=... is passed pointing to a device file that does NOT contain a floppy disk entry. --no-floppy is present and at the same time there is no --device-map=... that points to a device file that contains a floppy disk entry. So I could resolve the problem by removing the (fd0) line in my /boot/grub/device.map I think that this problem should be fixed by the grub developers: Grub must not crash when there is a non-working floppy drive.
this is because of the attempt at automatically updating the mbr with: [[ -e /boot/grub/grub.conf ]] \ && /sbin/grub \ --batch \ --device-map=/boot/grub/device.map \ < /boot/grub/grub.conf > /dev/null 2>&1 which fails more often than it works. there's really got to be a better way to do it. honestly i still think that this command should be removed and replaced with a flashybeepy notice to the user to run grub-install.
*** Bug 91866 has been marked as a duplicate of this bug. ***
What is this device-map supposed to do and how is it generated? It contains lot of bogus entries here: (fd0) /dev/floppy/0 (hd0) /dev/ide/host0/bus0/target0/lun0/disc (hd1) /dev/ide/host0/bus0/target1/lun0/disc (hd2) /dev/ide/host0/bus1/target0/lun0/disc (hd3) /dev/ide/host2/bus0/target0/lun0/disc (hd4) /dev/ide/host2/bus1/target0/lun0/disc (hd5) /dev/scsi/host0/bus0/target0/lun0/disc (hd6) /dev/scsi/host1/bus0/target0/lun0/disc The machine has no floppy drive and also there is no /dev/scsi/... with udev-056 for me, despite the fact that there are 6 SATA disks in this machine.
I have same problem here with 0.96-r2. root 6865 1960 1 19:35 pts/0 00:00:02 /usr/bin/python -O /usr/bin/emerge grub root 11542 6865 1 19:37 pts/0 00:00:00 /bin/bash /usr/lib/portage/bin/ebuild.sh postinst root 11581 11542 35 19:37 pts/0 00:00:04 /sbin/grub --batch --device-map=/boot/grub/device.map root 11583 2187 0 19:37 pts/5 00:00:00 ps -ef vrapenec ~ # strace -v -p 11581 Process 11581 attached - interrupt to quit write(1, "6858: \n66859: \n66860: \n66861: \n6"..., 1024) = 1024 write(1, "6986: \n66987: \n66988: \n66989: \n6"..., 1024) = 1024 write(1, "7114: \n67115: \n67116: \n67117: \n6"..., 1024) = 1024 write(1, "7242: \n67243: \n67244: \n67245: \n6"..., 1024) = 1024 write(1, "7370: \n67371: \n67372: \n67373: \n6"..., 1024) = 1024 write(1, "7498: \n67499: \n67500: \n67501: \n6"..., 1024) = 1024 write(1, "7626: \n67627: \n67628: \n67629: \n6"..., 1024) = 1024 write(1, "7754: \n67755: \n67756: \n67757: \n6"..., 1024) = 1024 write(1, "7882: \n67883: \n67884: \n67885: \n6"..., 1024) = 1024 write(1, "8010: \n68011: \n68012: \n68013: \n6"..., 1024) = 1024 write(1, "8138: \n68139: \n68140: \n68141: \n6"..., 1024) = 1024 write(1, "8266: \n68267: \n68268: \n68269: \n6"..., 1024) = 1024 write(1, "8394: \n68395: \n68396: \n68397: \n6"..., 1024) = 1024 write(1, "8522: \n68523: \n68524: \n68525: \n6"..., 1024) = 1024 write(1, "8650: \n68651: \n68652: \n68653: \n6"..., 1024) = 1024 write(1, "8778: \n68779: \n68780: \n68781: \n6"..., 1024) = 1024 write(1, "8906: \n68907: \n68908: \n68909: \n6"..., 1024) = 1024 write(1, "9034: \n69035: \n69036: \n69037: \n6"..., 1024) = 1024 write(1, "9162: \n69163: \n69164: \n69165: \n6"..., 1024) = 1024 write(1, "9290: \n69291: \n69292: \n69293: \n6"..., 1024) = 1024 write(1, "9418: \n69419: \n69420: \n69421: \n6"..., 1024) = 1024 write(1, "9546: \n69547: \n69548: \n69549: \n6"..., 1024) = 1024 write(1, "9674: \n69675: \n69676: \n69677: \n6"..., 1024) = 1024 It looks quite scary. It just keeps writing something and eating 100% of CPU. :(
could try grub-0.97
(In reply to comment #4) I wholeheartedly agree! especially since I don't always have a setup line in my grub.conf and the return value of the grub is never checked to make sure it was a success. Can anyone explain why this is written this way? > this is because of the attempt at automatically updating the mbr with: > > [[ -e /boot/grub/grub.conf ]] \ > && /sbin/grub \ > --batch \ > --device-map=/boot/grub/device.map \ > < /boot/grub/grub.conf > /dev/null 2>&1 > > which fails more often than it works. there's really got to be a better way to do it. > > honestly i still think that this command should be removed and replaced with a flashybeepy notice to the user to run grub-install.
(In reply to comment #9) > I wholeheartedly agree! especially since I don't always have a setup line in my > grub.conf and the return value of the grub is never checked to make sure it was > a success. Can anyone explain why this is written this way? not a clue. i went as far as searching in the CVS changelogs back to when grub was first added but didn't find anything. when i was writing the grub-0.96 ebuild i poked it with a stick a bit but only ended up making things worse. in the end i figured it was safer to leave it alone. the main problem with removing it is that if the grub stage files in /boot are updated, but the version in the mbr is not, the system won't boot. and we can't just update the mbr from the ebuild because we have no idea where the user wants to install the grub image to - the mbr of the first disk? first partition? a second drive? if we make any assumptions we'll just end up writing over the boot record of some dual-booting user's Windows partition. the oneliner's purpose is basically to find a "root" line in grub.conf (which tells grub the location of the image to boot from) and assume that since the user is already booting from there that it's the most logical place to install.
*** Bug 109918 has been marked as a duplicate of this bug. ***
I'm having this same issue with grub-0.97-r2
re-open in grub 0.97-r3 doesnt fix things
