Bugzilla – Bug 433980
Installation on XFS root partition freezes when installing grub package
Last modified: 2009-05-04 06:51:12 UTC
The installation procedure on a soft RAID1- XFS root filesystem freezes when installing the GRUB-rpm package.
Please attach y2logs. If you are in doubt follow: http://en.opensuse.org/Bugs/YaST Thanks!
Created attachment 244858 [details] output of save_y2log After the package installation freezes, this is what the log files contain. Hope this helps!
Are there any log messages on the console? How about /var/log/messages?
The consoles are free, no apparent error. That doesn't mean, though, that there couldn't be some when it would have come to my mind to call tail /var/log/messages... Yet, I have repeated that procedure many times now and it is 100% reproducible, at least with the Beta 2 DVD. I can't verify if it is related to the IDE drives I use, due to a lack of a SATA machines. Installation on a softRAID 1 on XFS works flawlessly with SLES 10 on SATA drives. We very much hope that the upcoming SLES 11 will support this, too. This is mainly why I filed this bug report. Thanks in advance!
Still the very same behavior with Beta3. With ext3 as filesystem for the softRAID 1 the installation finishes (I haven't babysitted it, though) but leaves me with a panicked shell after the first boot. Will attach screenies. The errors look similar to bug #429121, btw...
Created attachment 247592 [details] screenshot of the system state after the installation I have not interfered with the installation after starting it, so this is what you get after returning to the computer after 40mins or so.
Created attachment 247593 [details] screenshot with some more details
More info on the issue: out of curiosity I installed on a regular IDE partition with XFS as filesystem. No softRAID. And the package installation freezes at the very same time, i.e. when the grub package is to be installed. So, this looks like GRUB with XFS is severely broken. I will change the title to reflect this.
Also, this is on a totally different machine (was: Celeron desktop PC - is: Pentium M laptop), so it is not a hardware issue.
I ran into this, too. The grub maintainer says that installing grub into XFS is not (or at least no longer) supported. There is a bug open to fix the options available in the YaST partitioner. See bug #438757. Possible workarounds are installing grub into the MBR or adding a non-XFS /boot partition.
Just wanted to drop a line to mention that installing grub into MBR does *not* change anything at all: the installation freezes again when installing the grub package.
When you get the message: invalid root filesystem -- exiting to /bin/sh could you try lsmod to see if the 'xfs' module is loaded mount /dev/md0 /root to see if you can mount manually mount -t xfs /dev/md0 /root to see if you can mount by explicitly giving the filesystem type. This looks like it might be the same bug as bug #435778
I have no authorization to check on bug #435778. But since that XFS grub bug is now very official, I think this bug can be closed: it is impossible to boot from an XFS root partition, anyway, and the installer puts a prominent warning to try to do so. All I am worrying about now is our SLES 10 setup: it boots from an XFS softRAID1 and we have no extra EXT3 /boot partition, so I'm afraid that an upgrade to upcoming SLES11 will break the system. With all the given limitations and hassles of grub (especially on a system with mixed SATA/IDE drives), wouldn't it be a good idea to look for better alternatives?
Just wanted to follow up on this bug... I just ran across this attempting to install openSUSE 11.1. I have /dev/md0 as my boot partition formatted with ext3 (I saw the warnings about XFS using sector 0, thus not workable with GRUB), /dev/md1 as swap, and /dev/md2 as my root partition formatted with XFS. The first phase of the install completed without error, but now that the system rebooted to complete the install, I see exactly the behaviour described above... and no, the installer did not warn me of anything whatsoever.
Sorry, after a bunch more digging... it appears to have to do with udev rules not filling in the ID_FS_xxxx fields - looks very similar to bug #222471, except that bug claims to have been fixed ages ago.
...dig dig dig... Turns out it's actually bug #445490, sorry for the noise.
this bug has been marked as a duplicate of bug #445490 *** This bug has been marked as a duplicate of bug 445490 ***