Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
I updated grub yesterday and reinstalled it as ebuild suggested me but I forgot to modify my grub.conf for pointing to new splash location at /usr/share/grub instead of /boot/grub. Then, when I started my system today, I got a blank window with no more info and the default boot entry being booted. I remembered that splash location was changed because I checked ChangeLog some weeks ago, but is possible that other users won't find this and will think that something is broken Thanks a lot Reproducible: Always
If you run "emerge --config grub" as specifically directed, it gets copied to the /boot/grub/ location that was previously used. The new location is specifically as /boot/ might not be mounted when the install runs, and it also missed grub on other devices.
(In reply to comment #1) > If you run "emerge --config grub" as specifically directed, it gets copied to > the /boot/grub/ location that was previously used. > The message shown says: * To install grub files to another device (like a usb stick), just run:... as I don't wanted install it to another device I didn't run emerge --config... But, after reemerging grub today seems that splash has been copied automatically to /boot/grub/ again :-O Sorry for the inconvenience
I think this is still a problem, my computer crashed during my latest emerge world, after grub had installed. When I rebooted and was presented with a black screen and flashing cursor my first instinct was that something was seriously wrong with my computer. It took a certain amount of investigation to realize that the slash image was missing. I further agree with the previous post that the ebuild warning message is misleading.
Other report in 231134 and also my father's machine was affected. I don't know why splash is not being copied in /boot/grub sometimes even when /boot is mounted (I have /boot in / partition). Seems that setup_boot_dir "${ROOT}"/boot is not being run, but I don't know why
*** Bug 231134 has been marked as a duplicate of this bug. ***
I agree about the misleading message. I always read warnings and other statements at the end of any merge, and I missed this one too because it did not seem to apply to me. I would like to request that either: (1) the configuration or copying of the splash screen happen automatically when grub is updated OR (2) the warning message be changed to something more explicit so that the user will know to run emerge --config grub I also want to point out that there is another (separate) bug here: http://bugs.gentoo.org/show_bug.cgi?id=200505
Presently, we _DO_ try very hard to get /boot updated automatically, and you get one of two variants of message, depending on your system: ======= * WARNING: you have DONT_MOUNT_BOOT in effect, so you must apply * the following instructions for your /boot! * Neglecting to do so may cause your system to fail to boot! * * To interactively install grub files to another device such as a USB * stick, just run the following and specify the directory as prompted: * emerge --config =grub-0.97-r6 * Alternately, you can export GRUB_ALT_INSTALLDIR=/path/to/use to tell * grub where to install in a non-interactive way. ====== OR: ====== * *** IMPORTANT NOTE: you must run grub and install * the new version's stage1 to your MBR. Until you do, * stage1 and stage2 will still be the old version, but * later stages will be the new version, which could * cause problems such as an unbootable system. * This means you must use either grub-install or perform * root/setup manually! For more help, see the handbook: * http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=10#grub-install-auto * Copying files from /lib/grub, /usr/lib/grub and /usr/share/grub to //boot/grub * Grub has been installed to //boot successfully. * * To interactively install grub files to another device such as a USB * stick, just run the following and specify the directory as prompted: * emerge --config =grub-0.97-r6 * Alternately, you can export GRUB_ALT_INSTALLDIR=/path/to/use to tell * grub where to install in a non-interactive way. ======== If you get the SECOND one, then /boot/grub/splash.xpm.gz should exist. If you get the first one, then it's a mis or deliberate configuration on your system that stopped /boot from being updated. Running "emerge --config grub" manually will give you the top block of the second message as well. If those messages aren't explicit enough, I can offer a pair of glasses and a cluebat.
I got the second message, but /boot/grub/splash.xpm.gz did not exist - so there is a bug somewhere.
In my opinion, the following instruction is not clear: * WARNING: you have DONT_MOUNT_BOOT in effect, so you must apply * the following instructions for your /boot! * Neglecting to do so may cause your system to fail to boot! * * To interactively install grub files to another device such as a USB * stick, just run the following and specify the directory as prompted: * emerge --config =grub-0.97-r6 * Alternately, you can export GRUB_ALT_INSTALLDIR=/path/to/use to tell * grub where to install in a non-interactive way. "The following instructions" refer to what? The command "emerge --config =grub-097-r6"? That appears in the instructions of installing grub files to another device, which I was not interested in doing. If you are supposed to run that command, I would propose rewording it to something more direct, such as: * WARNING: you have DONT_MOUNT_BOOT in effect, so you must run * the following command for your /boot! * Neglecting to do so may cause your system to fail to boot! * * emerge --config =grub-0.97-r6 * * You will be prompted to specify the directory to install to. * You can also use this command to interactively install grub files * to another device such as a USB stick. * * Alternately, you can export GRUB_ALT_INSTALLDIR=/path/to/use to tell * grub where to install in a non-interactive way. Does this seem silly? I very carefully read the instructions and was confused. I also find the prompt unclear. Call me an idiot but I'm trying my best. Also...it's not clear to me from the instructions above what directory to give. It asks: * Enter the directory where you want to setup grub: Is this wanting /boot ? or /boot/grub? Or something else? I think the language needs to be made more explicit here. The instructions should leave no ambiguity, no room for questions or uncertainty.
Also, why can't portage mount the /boot directory on its own? This would work on the vast majority of systems and there could be some sort of detection process to see that it didn't work? Is there some problem with the user privileges? I know the emerge command is run as root but portage has its own user.
I've got BOTH messages and splash was not installed. ---------- * Messages for package sys-boot/grub-0.97-r6: * * To avoid automounting and autoinstalling with /boot, * just export the DONT_MOUNT_BOOT variable. * * To interactively install grub files to another device such as a USB * stick, just run the following and specify the directory as prompted: * emerge --config =grub-0.97-r6 * Alternately, you can export GRUB_ALT_INSTALLDIR=/path/to/use to tell * grub where to install in a non-interactive way. * *** IMPORTANT NOTE: you must run grub and install * the new version's stage1 to your MBR. Until you do, * stage1 and stage2 will still be the old version, but * later stages will be the new version, which could * cause problems such as an unbootable system. * This means you must use either grub-install or perform * root/setup manually! For more help, see the handbook: * http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=10#grub-in stall-auto * GNU info directory index is up-to-date. ------------ So I followed instruction and performed root/setup manually and end-up with screwed grub. The workaround is very simple. You just need to re-emerge grub (/boot can be unmounted, it doesn't matter), and it would install all files including splash.xpm.gz to the /boot directory back. Reproducible: Always. I have multiple systems with single /root, which separate /boot, with raiser and with ext2.
(In reply to comment #7) > Presently, we _DO_ try very hard to get /boot updated automatically Could it be better if we won't try to update /boot automatically and leave everything for --config action? I have a complicated disk partitioning: bash #fdisk -l Device Boot Start End Blocks Id System /dev/hda1 * 1 2775 20978968+ 7 HPFS/NTFS /dev/hda2 2776 7751 37618560 f W95 Ext'd (LBA) /dev/hda5 2776 7751 37618528+ 7 HPFS/NTFS /dev/hdc1 * 1 1355 10243768+ 7 HPFS/NTFS /dev/hdc2 1356 5168 28826280 5 Extended /dev/hdc5 1356 1360 37768+ 83 Linux /dev/hdc6 1361 1427 506488+ 82 Linux swap / Solaris /dev/hdc7 1428 2720 9775048+ 83 Linux /dev/hdc8 2721 5168 18506848+ 83 Linux So, after regular 'emerge -DNupv world' I suddenly receive message that I'm in the middle of update and if I won't finish it my system will be unbootable. Under that pressure, the chance that I'll do something wrong is quite high.
Seems that there is a problem when updating from 0.97-r5: I have /boot in / partition (it's always mounted and I didn't export DONT_MOUNT...), if I update with emerge -avuDN world, splash is not installed in /boot, but, if I re-emerge grub after failure or install grub from scratch (for example in a new gentoo installation), it works ok
> * To interactively install grub files to another device such as a USB > * stick, just run the following and specify the directory as prompted: > * emerge --config =grub-0.97-r6 This is what threw me off as well. It references installing grub files to a USB stick but not to /boot on your hard drive to enable the splash screen. So I read it and skipped it since I figured it did not apply to me. When I rebooted, I got a blank screen with a blinking cursor which doesn't mean grub doesn't work as I found out. It just means the splash screen didn't load so you can't read anything but can still select which kernel to boot to and boot the system.
*** Bug 231514 has been marked as a duplicate of this bug. ***
Same issues as #8, #10, and #14 -- Been using grub forever, and when this new version came in I did as it said and re-ran grub-install. I didn't run --config, because I had no reason to install grub to an alternate device like a USB stick -- just wanted it in my MBR as always. I also was thrown off by not having a splash screen, with a bonus: for some reason, not having the splash caused my console display to be wildly corrupted. I did get the following output (although not at the end of the emerge, I saw it scroll by during the emerge): * Copying files from /lib/grub, /usr/lib/grub and /usr/share/grub to //boot/grub * Grub has been installed to //boot successfully. But regardless of it saying that files from /usr/share/grub were copied to /boot/grub, the splash.xpm.gz file was *not* included. The message is quite misleading...it seems like everyone will want to run --config if their /boot isn't mounted. And if your /boot is mounted, it should be fixed to also copy the splash file from /usr/share/grub to /boot/grub
Ok, so the serious question at this point, why for the folk seeing "Copying files from /lib/grub, /usr/lib/grub and /usr/share/grub to //boot/grub", isn't the splash.xpm.gz being copied? If you'd like to experiment with it, that would be useful, since I can't reproduce it on my systems. I suggest starting around line 191 of the ebuild, and adding some debug output to show every file as it's copied in the for loop.
I was hit by this issue too, but fortunately I noticed that the splash file was missing before rebooting. I then scrolled up and saw that it was removed by emerge when cleaning out the old version of grub. I'm sure I got the second version of the notice and I remember seeing the "Copying files form..." line. This was several weeks ago so I don't have any logs left. I just stumbled upon this bug report right now. The splash image is being copied but then removed again by emerge for some reason. I hope this information can help to resolve the bug.
I just hit this. I too found myself misled. I'll accept that it's my fault but I'm still a big vague on why one has to manually issue `emerge --config grub`; I had the impression that running the usual grub commands manually would have done the trick. Oh well. AfC
I just ran into this myself. Downgrading to -r4 helped, then I noticed this bug. What happened so that it installed the splash file before and now doesnt anymore?
Ok, we ran into a portage bug it seems. A workaround for the moment might be just to emerge the new version twice. Once portage-2.1.5.7 is in stable, then we'll have to revbump grub and change both the -r6 and -r7 revs to ensure that the new portage is on the system, then everybody should get the fix properly.
(In reply to comment #7) > If those messages aren't explicit enough, I can offer a pair of glasses and a > cluebat. > Why do people think that some log output during an emerge is sufficient? When you do emerge -Du world and hundreds of packages re-build, it's impossible to even see the log messages from all of these installs. In my case, /boot/grub/splash.xpm.gz existed before the grub upgrade, but when the new version was installed and the old version deleted, /boot/grub/splash.xpm.gz was deleted and never re-created. I didn't see any warnings during emerge because grub was at least 100 ebuilds in, and I certainly don't think it's unreasonable to think someone might miss 10 lines out of millions upon millions whizzing past. I'm happy to provide any debug info I can if this breakage was unexpected (on boot, grub thinks it's installed to hd(0) and root is (hd0,1). When I'm actually booted and doing "setup" grub is actually installed to (hd2,1).)
(In reply to comment #22) > (removed) ifette: how about reading the entire bug before commenting? if you see comment 21, I explicitly stated that we had discovered a Portage bug (linked in the bug deptree) where it was deleting the file when it wasn't supposed to. In that comment I also provided the workaround that is usable until portage >=2.1.5.7 (not a typo) goes stable.
(In reply to comment #23) > (In reply to comment #22) > > (removed) > ifette: how about reading the entire bug before commenting? if you see comment > 21, I explicitly stated that we had discovered a Portage bug (linked in the bug > deptree) where it was deleting the file when it wasn't supposed to. > > In that comment I also provided the workaround that is usable until portage > >=2.1.5.7 (not a typo) goes stable. > Your comment 21 was not that specific, and in conjunction with comment 17 I thought the bug was that the new file was not being copied over. I was unsure why the file was being deleted at all. I didn't realize (nor do I really think it was clear from the bug trail) that the fact the file was being deleted was a portage bug. Apologizes for not adding anything new in that case.
Ok, the "new" Portage has been in the tree long enough. This will be absolutely solved for everybody else when -r10 rolls out.
