I have a symlink /boot -> /mnt/dev/hda8/boot and mount /dev/hda8 on /mnt/dev/hda8 type vfat (rw,nosuid,nodev,noatime,uid=10292,gid=20159,codepage=850) Emerging grub-0.93.20030118 fails as follows: >>> Completed installing into /var/tmp/portage/grub-0.93.20030118/image/ >>> Merging sys-apps/grub-0.93.20030118 to / * * Assuming you do not have a separate /boot partition. * --- /bin/ >>> /bin/mbchk --- /usr/ --- /usr/share/ --- /usr/share/doc/ --- /usr/share/doc/grub-0.93.20030118/ >>> /usr/share/doc/grub-0.93.20030118/grub.conf.sample.gz >>> /usr/share/doc/grub-0.93.20030118/README.gz >>> /usr/share/doc/grub-0.93.20030118/THANKS.gz >>> /usr/share/doc/grub-0.93.20030118/TODO.gz >>> /usr/share/doc/grub-0.93.20030118/NEWS.gz >>> /usr/share/doc/grub-0.93.20030118/COPYING.gz >>> /usr/share/doc/grub-0.93.20030118/AUTHORS.gz >>> /usr/share/doc/grub-0.93.20030118/BUGS.gz >>> /usr/share/doc/grub-0.93.20030118/ChangeLog.gz --- /usr/share/man/ --- /usr/share/man/man1/ >>> /usr/share/man/man1/mbchk.1.gz --- /usr/share/man/man8/ >>> /usr/share/man/man8/grub-install.8.gz >>> /usr/share/man/man8/grub-md5-crypt.8.gz >>> /usr/share/man/man8/grub.8.gz >>> /usr/share/man/man8/grub-terminfo.8.gz --- /usr/share/grub/ --- /usr/share/grub/i386-pc/ >>> /usr/share/grub/i386-pc/e2fs_stage1_5 >>> /usr/share/grub/i386-pc/jfs_stage1_5 >>> /usr/share/grub/i386-pc/xfs_stage1_5 >>> /usr/share/grub/i386-pc/minix_stage1_5 >>> /usr/share/grub/i386-pc/fat_stage1_5 >>> /usr/share/grub/i386-pc/vstafs_stage1_5 >>> /usr/share/grub/i386-pc/stage1 >>> /usr/share/grub/i386-pc/stage2 >>> /usr/share/grub/i386-pc/reiserfs_stage1_5 >>> /usr/share/grub/i386-pc/ffs_stage1_5 --- /usr/share/info/ >>> /usr/share/info/grub.info-1.gz >>> /usr/share/info/grub.info-2.gz >>> /usr/share/info/grub.info-3.gz >>> /usr/share/info/multiboot.info.gz >>> /usr/share/info/grub.info.gz --- /boot/ --- /boot/grub/ !!! Failed to chown/chmod/unlink in movefile() !!! /boot/grub/splash.xpm.gz !!! [Errno 1] Operation not permitted: '/boot/grub/splash.xpm.gz' The first problem seems to be the assumption that /boot is not on a separate partition; the second one seems to be the inability to cope with file operations that are impossible on vfat. My portage system has been upgraded today; I did not have this problem before. Reproducible: Always Steps to Reproduce: Portage 2.0.49-r13-2 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1, 2.6.0-test7) ================================================================= System uname: 2.6.0-test7 i686 Intel(R) Pentium(R) 4 CPU 2.60GHz Gentoo Base System version 1.4.3.10p1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium3 -mcpu=pentium4 -O2 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=pentium3 -mcpu=pentium4 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="ccache autoaddcvs fixpackages notitles sandbox userpriv usersandbox" GENTOO_MIRRORS=" http://ftp.easynet.nl/mirror/gentoo/ ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ http://gentoo.linux.no/ ftp://sunsite.cnlab-switch.ch/mirror/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage/" USE="crypt foomaticdb gif gpm libg++ mad mikmod ncurses nls pdflib quicktime spell xml2 gdbm berkdb slang readline svga java guile X sdl pam libwww ssl perl python imlib qt motif -aalib acpi alsa -apm -arts avi cdr cups dvdemacs encode esd gnome gphoto2 gtk gtk2java jpeg -kde -leim mbox mozilla mpeg -mule-nls oggvorbis opengl -oss png readlinesamba sse tcpd tetex tiff truetype usbX xmms xv x86 zlib"
I felt compelled to emerge grub, because "emerge blackdown-jdk" finished with the following error message: >>> original instance of package unmerged safely. >>> Regenerating /etc/ld.so.cache... * Caching service dependencies... [ ok ] >>> dev-java/blackdown-jdk-1.4.1 merged. >>> clean: No packages selected for removal. >>> Regenerating /etc/ld.so.cache... * Caching service dependencies... [ ok ] >>> Auto-cleaning packages ... ['sys-apps/grub', '0.93.20030118', 'r0'] ['sys-apps/grub-0.92-r1', 'sys-apps/grub-0.93.20030118'] !!! COUNTER file is missing for sys-apps/grub-0.93.20030118 in /var/db. !!! Please run /usr/lib/portage/bin/fix-db.pl or !!! Please run /usr/lib/portage/bin/fix-db.py or !!! remerge the package. /usr/lib/portage/bin/fix-db.pl failed as follows: Grabbing db contents... Grabbing mtimes... fix-db: fatal: insufficient data for gnome-base/gnome-2.4 Remove this package's directory from /var/db/pkg to fix this, then start this script again. If everything worked correctly, you must remerge gnome-base/gnome-2.4 to not mess up any dependencies.
To avoid confusing the installation by /boot being a symlink, I now mounted my vfat boot patition directly on /boot. This resulted in failure too, so that it seems impossible to install grub on a vfat boot partition. I have changed the bug summary to reflect this. >>> Completed installing into /var/tmp/portage/grub-0.93.20030118/image/ >>> Merging sys-apps/grub-0.93.20030118 to / * * Your boot partition was detected as being mounted as /boot. * Files will be installed there for grub to function correctly. * --- /bin/ >>> /bin/mbchk --- /usr/ --- /usr/share/ --- /usr/share/doc/ --- /usr/share/doc/grub-0.93.20030118/ >>> /usr/share/doc/grub-0.93.20030118/grub.conf.sample.gz >>> /usr/share/doc/grub-0.93.20030118/README.gz >>> /usr/share/doc/grub-0.93.20030118/THANKS.gz >>> /usr/share/doc/grub-0.93.20030118/TODO.gz >>> /usr/share/doc/grub-0.93.20030118/NEWS.gz >>> /usr/share/doc/grub-0.93.20030118/COPYING.gz >>> /usr/share/doc/grub-0.93.20030118/AUTHORS.gz >>> /usr/share/doc/grub-0.93.20030118/BUGS.gz >>> /usr/share/doc/grub-0.93.20030118/ChangeLog.gz --- /usr/share/man/ --- /usr/share/man/man1/ >>> /usr/share/man/man1/mbchk.1.gz --- /usr/share/man/man8/ >>> /usr/share/man/man8/grub-install.8.gz >>> /usr/share/man/man8/grub-md5-crypt.8.gz >>> /usr/share/man/man8/grub.8.gz >>> /usr/share/man/man8/grub-terminfo.8.gz --- /usr/share/grub/ --- /usr/share/grub/i386-pc/ >>> /usr/share/grub/i386-pc/e2fs_stage1_5 >>> /usr/share/grub/i386-pc/jfs_stage1_5 >>> /usr/share/grub/i386-pc/xfs_stage1_5 >>> /usr/share/grub/i386-pc/minix_stage1_5 >>> /usr/share/grub/i386-pc/fat_stage1_5 >>> /usr/share/grub/i386-pc/vstafs_stage1_5 >>> /usr/share/grub/i386-pc/stage1 >>> /usr/share/grub/i386-pc/stage2 >>> /usr/share/grub/i386-pc/reiserfs_stage1_5 >>> /usr/share/grub/i386-pc/ffs_stage1_5 --- /usr/share/info/ >>> /usr/share/info/grub.info-1.gz >>> /usr/share/info/grub.info-2.gz >>> /usr/share/info/grub.info-3.gz >>> /usr/share/info/multiboot.info.gz >>> /usr/share/info/grub.info.gz --- /boot/ Traceback (most recent call last): File "/usr/bin/emerge", line 2153, in ? mydepgraph.merge(mydepgraph.altlist()) File "/usr/bin/emerge", line 1357, in merge retval=portage.doebuild(y,"merge",myroot,edebug) File "/usr/lib/python2.2/site-packages/portage.py", line 1836, in doebuild return merge(settings["CATEGORY"],settings["PF"],settings["D"],settings["BUI LDDIR"]+"/build-info",myroot,myebuild=settings["EBUILD"]) File "/usr/lib/python2.2/site-packages/portage.py", line 1955, in merge return mylink.merge(pkgloc,infloc,myroot,myebuild) File "/usr/lib/python2.2/site-packages/portage.py", line 5035, in merge return self.treewalk(mergeroot,myroot,inforoot,myebuild) File "/usr/lib/python2.2/site-packages/portage.py", line 4685, in treewalk if self.mergeme(srcroot,destroot,outfile,secondhand,"",cfgfiledict,mymtime): File "/usr/lib/python2.2/site-packages/portage.py", line 4942, in mergeme if self.mergeme(srcroot,destroot,outfile,secondhand,offset+x+"/",cfgfiledict ,thismtime): File "/usr/lib/python2.2/site-packages/portage.py", line 4938, in mergeme os.chown(mydest,mystat[4],mystat[5]) OSError: [Errno 1] Operation not permitted: '/boot/grub'
Im not doing grub these days guys...
MJC, feel free to take it if you can solve it. It might be however that the stuff to mount /boot fails due to the vfat bug, although I am not sure if it was present before 2.6.0-test9 ?
grub 0.92-r1 installed fine on my vfat partition. Comparing the ebuilds, the cause of the problem becomes clear: 0.92-r1 used "make install" and a "cp" command to install grub, whereas 0.93.20030118 uses einstall, insinto and doins to install. Obviously, the latter mechanisms fail on vfat partitions, while the former ones work. Reverting the install mechanism to the old one should fix the problem. (In general, it is probably correct for einstall, insinto and doins to fail when they cannot set file ownership or make symlinks as intended, because that helps ensure that the ebuild installations are correct. But this feature makes them inappropriate to install on not-fully-capable filesystems, which should be possible for grub.)
marius, nick, nakano -- thoughts?
We cannot make exlusions like this. Portage cannot verify the installation is acceptable or reasonable on vfat. It simply isn't possible. Permissions cannot be maintained, so the system cannot be sure it has completed the installation. Detecting vfat and ignoring this is a possibility, but I really do not see this as an option worth exploring. It's dangerous to system health to allow data to be mismanaged. My opinion is no. Nothing wrong with using vfat for permissionless tasks, but portage isn't a permissionless system and should not ignore it to allow this.
> Portage cannot verify the installation is acceptable or reasonable > on vfat. It simply isn't possible. That's why I suggest that you do not use the normal portage mechanism to install grub, i.e., revert to the way version 0.92-r1 did it (see Comment #5). My system happens to have a vfat boot partition. This is perfectly normal on systems that dual-boot with Windows. Until this bug is fixed, I have no way to update grub any more. What do you suggest I do to work around this problem? Another argument: since the non-checking install on 0.92-r1 produces a system that works correctly, the checks done currently check more than is really necessary. Since this means grub won't install in certain system configurations, the checks should be relaxed - not for portage in general, but for this particular package, which is special because it may need to be installed in a specific partition, perhaps a non-Linux one. To repeat what appears to have been misunderstood: I am not talking about portage in general, but about this package in particular. Hence I find the general arguments in the preceding comment insufficient. BTW. grub-0.94-r1 again fails to install: --- /usr/share/info/ >>> /usr/share/info/multiboot.info.gz >>> /usr/share/info/grub.info.gz --- /boot/ --- /boot/grub/ !!! Failed to chown/chmod/unlink in movefile() !!! /boot/grub/splash.xpm.gz !!! [Errno 1] Operation not permitted: '/boot/grub/splash.xpm.gz' It seems I now have a semi-installed package, i. e. a potentially unbootable system. This makes this problem a blocker for me, and I will try to set this severity.
To satisfy my own curiosity... Why would having a vfat /boot be normal for systems that're dual-booting Windows? This is the first time I've seen somebody doing that.
> Why would having a vfat /boot be normal for systems that're > dual-booting Windows? This is the first time I've seen somebody > doing that. Some reasons: 1. If you break your Linux boot, you can still boot into Windows and fix your boot setup from there, 2. The BIOS 1024 cylinder limit for boot partitions can make it necessary for Windows to also have a boot partition separate from its main system partition. Rather than setting up a separate boot partition for each operating system, it seems more elegant to have only a single initial boot partition on each disk. 3. My system came preinstalled with Windows, including a small VFAT partition with Windows "recovery" data. This partition serves perfectly well as a boot partition, so I did not consider it necessary to make yet another one. Grub is designed to be installed on FAT partitions, and the gentoo grub ebuilds had no problems with VFAT up to 0.92-r1. 4. The current restriction of the grub ebuilds must be documented in the gentoo installation instructions, lest other users fall into the trap of building a working system that breaks on each following grub update (perhaps months later - an ugly time bomb). All I am asking for is that the regression introduced in the ebuild between 0.92-r1 and 0.93.20030118 be fixed (I am not asking for a change in the way portage works). But I have found a work-around for my setup: [/boot is a symlink to /mnt/dev/hda8/boot, where /mnt/dev/hda8 is the mount point of my boot partition] mv /boot /realboot emerge -Du grub [Now there is a new directory /boot/grub on my root partition with the files installed by the ebuild] (cd /boot/grub && tar cf - . ) | (cd /realboot/grub && tar xvpf -) [Now the files have been copied over to the boot partition] diff -r /boot /realboot rm -rf /boot mv /realboot /boot So this is not a blocker for me any more, and I will downgrade the severity.
Even though I feel that your argument in favor of having a vfat /boot are valid, I don't think we should even recommend users to have /boot as a vfat partition. This due to two (imho) strong reasons: 1/ We don't mount /boot for security reasons, but if Windows can see the partition (as it's vfat) viruses can easily destroy/alter data on it. 1.bis/ A special virus is a humanoid -- we don't want him to accidentally remove the grub configuration file, stages or any other important files. Having this directory not be seen by a Windows system is an important aspect 2/ There are many limitations to the vfat filesystem. One of them is the absence of symlinks (they use .lnk files) which is frequently used on Linux systems to point to the most recent kernel, initrd and system map. The other ones are of course permissions and such. I feel those are stronger than your points, because breaking a Linux boot is a bit more difficult, especially because we don't have the user mount his /boot, so he really has to mount /boot before fubaring his Linux boot. And if he does manage to do this, chances are he will fubar his Windows settings as well (the NTLDR or the config files on the boot partition).
> I don't think we should even recommend users to have /boot > as a vfat partition. Agreed, but I do not want my setup to be recommended, but only not to be time-bombed (especially not as a regression after previous ebuilds worked fine). Grub is designed to be installed on many file systems, including VFAT, so the weakness of that file system is not a problem. There is another argument against the current ebuild given by the grub authors in Bug #46828: They advise that the grub files should not simply be installed by copying, but by the grub-install script. If that is true for the original installation, it is equally true for the upgrade done by an ebuild.
grub-install is not for the stage files, it's for GRUB itself (i.e. the installation into the MBR).
> grub-install is not for the stage files, it's for GRUB itself > (i.e. the installation into the MBR). Did you look at the script? The version I have is 467 lines long and *does* install the stage files: # Copy the GRUB images to the GRUB directory. for file in ${grubdir}/stage1 ${grubdir}/stage2 ${grubdir}/*stage1_5; do rm -f $file || exit 1 done for file in \ ${pkgdatadir}/stage1 ${pkgdatadir}/stage2 ${pkgdatadir}/*stage1_5; do cp -f $file ${grubdir} || exit 1 done
Okay, true, but the script just copies the stage files which isn't different from what is done now, no?
Portage won't make super special exceptions. It can't verify that the files are proper on a fat FS, and it won't assume so any time in the near future.
I have had a look at the current ebuild (grub-0.94-r1.ebuild) and noticed a few peculiarities: - The stage files get installed first into /usr/lib/grub and are later copied into /boot grub. However, the file /splash.xpm.gz and grub.conf.sample get installed directly into /boot. It would seem more logical to put all files into /usr/lib/grub first, from which they can then be installed onto a boot partition. - grub 0.94 looks for menu.lst as the menu file on boot and ignores grub.conf. However, the ebuild installs the menu file as grub.conf and makes a symlink to it from menu.lst. Thus, the boot process becomes dependent on symlinks, for no good reason. (It also introduces a gratuitous incompatibility getween gentoo and other Linux systems.) - After installing the files, if /boot/grub/grub.conf exists, the script calls /usr/sbin/grub \ --batch \ --device-map=/boot/grub/device.map \ < /boot/grub/grub.conf > /dev/null 2>&1 This is wrong for several reasons: (1) the command is /sbin/grub, not /usr/sbin/grub; (2) the grub.conf file is unsuitable as command input for grub, as it contains menu-only commands (resulting in lots of error messages) and typically no setup command (which would presumably be the purpose of this step). The ebuild does not have sufficient information to decide where a boot block should be written, and it is a dangerous operation. Hence it seems advisable to not let the ebuild write a boot block, but to let the user do it. Instead of calling the grub shell, the user may just as well call grub-install, which installs the files on a boot partition. Thus my suggestion for the grub ebuild is the following: - The ebuild installs all files in /usr/lib/grub, but does not manipulate any boot partition. - The user is asked to make a boot partition with grub-install. - The grub-install script may be patched by the ebuild to copy over additional files provided by gentoo, such as splash.xpm.gz. Advantages: (1) The user can perform the boot partition setup at his discretion, and repeat it as often as he likes. (2) The ebuild does not attempt to write a boot block. (3) The extra consistency checks in grub-install are performed. (4) grub-install can handle more types of boot partition than portage; thus we do not constrain the system configuration. (5) No change to portage and its consistency checks is required.
Until we get a version of coreutils that provides a fixed df (not yet, but soon) we cannot fix this. grub-install must be avoided, and automation must be maintain. Please change status to RESOLVED LATER.
> Until we get a version of coreutils that provides > a fixed df (not yet, but soon) we cannot fix this Is the problem recorded as a bug? If so, we should add a dependency on that bug here. That would make it clear what we are waiting for and is thus preferrable to the status LATER.
It appears that swift has come up with a dirty hack ;-) Check the latest handbook. We can go back to using grub-install now, which TBH is probably preferable. A proper fix will hopefully follow if and when I take over maintainership of grub (which has been mooted by seemant) as long as coreutils has been fixed. I can't verify whether or not coreutils is still broken.
Closing. Whilst the current solution isn't perfect, it's as good as we can manage without breaking things I don't want to break. The contents of /boot should be managed by portage if possible, and that is how it shall stay. If you really need to keep that VFAT partition, there's nothing to stop you from keeping that for what you need it for and creating another partition for /boot which doesn't have VFAT's limitations.
If there is any meaning to the status WONTFIX, this bug should get it rather than FIXED.
Status is WONTFIX, as the problem remains unsolved (grub still fails installation on a VFAT boot partition). Comment #17 explains why this is not a good decision. The reason given not to fix this (Comment #21) is rather vague in comparison: "breaks things I don't want to break".
Re: Comment #21, by "breaks things I don't want to break" I'm on about Comment #7. VFAT is a sufficiently limited filesystem that it is impossible to verify a correct installation. The workaround exists for this, in that the manual use of grub-install is now documented in the Gentoo Handbook. If you reckon that's a WONTFIX, then fine - whatever makes you happy.
