Bugzilla – Bug 122547
grub problems with xfs
Last modified: 2006-05-05 10:29:35 UTC
Today I've updated my Computer at work from SUSE 9.3 with the SUSE 10.0 DVD (SUSE Linux Box). Theres only one big XFS partition (normaly I alwas create a little ext2 /boot) and grub didn't start. Started from DVD again using system repare, this wasn't able to find a SUSE installation. Started again form DVD, updating again, in this mode YaST finds the 10.0 installation, but after finish of the update, grub doesn't start again. I've booted from DVD and started the installed system, downloaded grub from SUSE 9.3, installed it, started yast, changed something in the bootloader configuration, changed it back and yast wrote a new mbr. After a reboot everything works fine. Looks like a problem in grub and the repare funktion in YaST.
What did you choose as "boot loader location"? Not the root partition by any chance?
Grub is installed in the MBR on the first IDE Harddisk (hda - there are two inside). It was the standard definition from SUSE 9.3 (first installation). The output is: GRUB Loading stage 1.5 GRUB loading, please wait ... Thats all. That's the disc is parted the following way: hda (ST340014A) | +-> hda1 ntfs, WinXP's C Partition hda2 extended | +-> hda5 ntfs WinXP's D Partiton, used the full rest of the Disc and was resized when installing SUSE 9.3 hda6 Linux swap partition hda7 Linux xfs / partition hda8 Linux xfs /home partition hdb (WDC-WD1200BB-00DA) | +-> hdb1 ntfs, WinXP's Z Partition Any more infos needed?
Bug is back in SUSE 10.1 rc1 I've updated two computers from beta9 to rc1 one with a separate /boot partition (ext2) and one without. / is both xfs formated. Without /boot "GRUB Loading stage2..." is the last thing I've seen. With /boot partition the GRUB menu is displayd, but every point ends in a reboot. After booting from install CD I can boot the installed system. I've switched to lilo and everything works fine. With grub it worked fine until beta9.
That's really strange. I didn't change the core code since beta9! Could this be a coincidence, or is it a BIOS limitation? Can you please paste `fdisk -l` output?
Notebook (sda is a external usb disk and I've tested with and without the disk): marvin2:/home/manfred # fdisk -l Platte /dev/hda: 60.0 GByte, 60011642880 Byte 255 heads, 63 sectors/track, 7296 cylinders Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes Gerät boot. Anfang Ende Blöcke Id System /dev/hda1 1 131 1052226 82 Linux Swap / Solaris /dev/hda2 132 1437 10490445 83 Linux /dev/hda3 * 1438 7296 47062417+ 83 Linux Platte /dev/sda: 30.0 GByte, 30005821440 Byte 255 heads, 63 sectors/track, 3648 cylinders Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes Gerät boot. Anfang Ende Blöcke Id System /dev/sda1 1 3648 29302528+ 83 Linux ----------------------------------------------------------------------- And my test computer with separate /boot partition: tester:~ # fdisk -l Platte /dev/hda: 8455 MByte, 8455200768 Byte 255 heads, 63 sectors/track, 1027 cylinders Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes Gerät boot. Anfang Ende Blöcke Id System /dev/hda1 * 1 2 16033+ 83 Linux /dev/hda2 3 35 265072+ 82 Linux Swap / Solaris /dev/hda3 36 1027 7968240 83 Linux Platte /dev/hdb: 6448 MByte, 6448619520 Byte 255 heads, 63 sectors/track, 784 cylinders Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes Gerät boot. Anfang Ende Blöcke Id System /dev/hdb1 1 33 265041 82 Linux Swap / Solaris /dev/hdb2 34 783 6024375 83 Linux
May I remark that none of these listings matches the layout from Comment #2, your initial report? Your test machine really should work. Can you paste ls -l of the /boot, hda1? On the notebook it might also be a BIOS problem. As a recommendation, a separate /boot partition should hold a "normal" ext2fs. Let's concentrate on your test machine; boot loader parts, kernel and initrd should be well below any BIOS limits. What does /etc/grub.conf look like? what's the output of grub --batch < /etc/grub.conf?
*** Bug 144279 has been marked as a duplicate of this bug. ***
Right, none of this machines matches the first one I've opend this bugreport first. It's the computer in the company, I'm not payed for betatesting. Hm, that's not right, we are using SAP XI, ok I'm not payed for betatesting SUSE Distros ;-) The two machines with SUSE 10.1 rc1 are my private ones. The separate /boot partition on "tester" is ext2, here's the ls -l output: tester:/boot # ls -l insgesamt 6794 -rw------- 1 root root 512 2006-04-14 22:45 backup_mbr lrwxrwxrwx 1 root root 1 2006-04-14 18:17 boot -> . -rw------- 1 root root 512 2006-04-14 22:45 boot.0300 -rw-r--r-- 1 root root 68265 2006-04-10 10:42 config-2.6.16-20-default drwxr-xr-x 2 root root 1024 2006-04-14 21:59 grub lrwxrwxrwx 1 root root 24 2006-04-14 21:59 initrd -> initrd-2.6.16-20-default -rw-r--r-- 1 root root 2456452 2006-04-14 21:59 initrd-2.6.16-20-default drwx------ 2 root root 12288 2006-02-24 19:50 lost+found -rw------- 1 root root 263168 2006-04-14 22:45 map -rw-r--r-- 1 root root 170496 2006-04-14 22:45 message -rw-r--r-- 1 root root 103379 2006-04-10 10:43 symsets-2.6.16-20-default.tar.gz -rw-r--r-- 1 root root 334797 2006-04-10 10:43 symtypes-2.6.16-20-default.gz -rw-r--r-- 1 root root 92181 2006-04-10 10:43 symvers-2.6.16-20-default.gz -rw-r--r-- 1 root root 676134 2006-04-10 10:37 System.map-2.6.16-20-default -rwxr-xr-x 1 root root 1498251 2006-04-10 10:42 vmlinux-2.6.16-20-default.gz lrwxrwxrwx 1 root root 25 2006-04-14 20:52 vmlinuz -> vmlinuz-2.6.16-20-default -rw-r--r-- 1 root root 1237821 2006-04-10 10:37 vmlinuz-2.6.16-20-default /etc/grub.conf: root (hd0,0) install --stage2=/boot/grub/stage2 /grub/stage1 (hd0,0) /grub/stage2 0x8000 (hd0,0)/grub/menu.lst quit The output of grub --batch < /etc/grub.conf: tester:/boot # grub --batch < /etc/grub.conf GNU GRUB version 0.97 (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> root (hd0,0) Filesystem type is ext2fs, partition type 0x83 grub> install --stage2=/boot/grub/stage2 /grub/stage1 (hd0,0) /grub/stage2 0x8000 (hd0,0)/grub/menu.lst grub> quit The result after rebooting: - grub menu is displayed - boots again with lilo, I've installed lilo on mbr - I've switched in YaST from lilo to grub with converting of the (working) lilo configuration: "Beim installieren von GRUB ist ein Fehler aufgetreten" no more information. Why should it be a BIOS Problem on my notebook? It worked fine with Beta 8, Beta 9 and with LILO in RC 1.
Second test: I let yast generate a new grub configuration, this one could be installed. Result: grub menu is displayed, and when it should starti SUSE, it reboots.
I've done a completely new installtion on "tester" with rc2. It boots with grub again. So maybe it was a beta9 -> rc1 update problem, or it's fixed in the new version. The update on "marvin2", my notebook is still running, I'll let you know the results there.
Dosen't work on my notebook after updating. Maybe after a complely new installation of rc2, I don't know. Can't do it in the moment, it's to much work to set up everything completely new. Lilo works fine and it doesn't make a different (only one OS, the I've disabled boot-menu).
*** Bug 168819 has been marked as a duplicate of this bug. ***
You're all having this problem on XFS on AMD64 (a.k.a x86_64 a.k.a EM64T), right? This seems strongly related to Bug #72973. If this is the case, /boot on XFS must be prohibited on x86_64, because grub works exclusively in 32-Bit mode. Alternatively, lilo must be forced, as it doesn't care about the file system. Thomas, heads up, this may become a blocker.
I can easily drop support for xfs from YaST2 again but last time I did this there was a lot of whining about this decision and I had to enable it again.
Forcing lilo after someone changes the /boot filesystem to XFS is not exactly nice either, but it can be done. I could block the workflow with a warning. To release it, the user needs to either - edit the bootloader config (and manually and/or automatically convert to lilo) or - change the filesystem to something else. But I am unsure how well-behaved the automatic conversion to lilo is. Anyway, if the result after conversion is not satisfactory to the user, he can always go back and then change the filesystem again.
Well in my case I am using a 32bits machine. model name : Intel(R) Pentium(R) M processor 1.60GHz So it's not a x86_64. I also upgraded an other machine to Suse 10 and as soon as updated the system with the YOU server the problem occur on the other machine it's easy to reproduce. PS. I am also using SLES10(beta) on IA32 and I don't have that problem so maybe you should look at the difference :)
No 64Bit extensions here: - computer at my company (the computer I've reported the bug first): Pentium IV 2,8 GHz, no EM64T - Tester, Pentium II 400 MHz - Marvin2, my notebook PentiumM (Banias) 1,6 GHz
Comment to Comment #14: I think, grub & xfs is a very common combination. We're using this with SLES in our company a long time without any problems. At home, the same people are using (Open)SUSE with this combination for a long time without any problems. What was changed in the source code between grub-0.96-6 and grub-0.97-2.1, that grub & xfs don't work together anymore?
Tested with RC3 and works fine. Closing in accordance with Comment #10
At #18: in particular the XFS code in grub hasn't changed significantly since 9.3!