Patched grub will not boot from EXT4 partition

Hi Dean,

1) Can you attach your /boot/grub/menu.lst file
2) Can you inform me how you created the ext4 partition?

Thanks! Colin

Hi Colin--

Have sent the conversion information to your personal E---menu.lst follows...

# menu.lst - See: grub(8), info grub, update-grub(8)
# grub-install(8), grub-floppy(8),
# grub-md5-crypt, /usr/share/doc/grub
# and /usr/share/doc/grub-doc/.

## default num
# Set the default entry to the entry number NUM. Numbering starts from 0, and
# the entry number 0 is the default if the command is not used.
#
# You can specify 'saved' instead of a number. In this case, the default entry
# is the entry saved with the command 'savedefault'.
# WARNING: If you are using dmraid do not use 'savedefault' or your
# array will desync and will not let you boot your system.
default 0

## timeout sec
# Set a timeout, in SEC seconds, before automatically booting the default entry
# (normally the first entry defined).
timeout 10

## hiddenmenu
# Hides the menu by default (press ESC to see the menu)
#hiddenmenu

# Pretty colours
#color cyan/blue white/blue

## Splash image!
splashimage=/boot/grub/splashimages/bluefractal.xpm.gz

## password ['--md5'] passwd
# If used in the first section of a menu file, disable all interactive editing
# control (menu entry editor and command-line) and entries protected by the
# command 'lock'
# e.g. password topsecret
## password --md5 $1$gLhU0/$aW78kHK1QfV3P2b2znUoe/
# password topsecret

#
# examples
#
# title Windows 95/98/NT/2000
# root (hd0,0)
# makeactive
# chainloader +1
#
# title Linux
# root (hd0,1)
# kernel /vmlinuz root=/dev/hda2 ro
#

#
# Put static boot stanzas before and/or after AUTOMAGIC KERNEL LIST

### BEGIN AUTOMAGIC KERNELS LIST
## lines between the AUTOMAGIC KERNELS LIST markers will be modified
## by the debian update-grub script except for the default options below

## DO NOT UNCOMMENT THEM, Just edit them to your needs

## ## Start Default Options ##
## default kernel options
## default kernel options for automagic boot options
## If you want special options for specific kernels use kopt_x_y_z
## where x.y.z is kernel version. Minor versions can be omitted.
## e.g. kopt=root=/dev/hda1 ro
## kopt_2_6_8=root=/dev/hdc1 ro
## kopt_2_6_8_2_686=root=/dev/hdc2 ro
# kopt=root=UUID=a6e2a3b0-2ede-4e9d-b21e-a4c77fb36972 ro rootfstype=ext4

## default grub root device
## e.g. groot=(hd0,0)
# groot=a6e2a3b0-2ede-4e9d-b21e-a4c77fb36972

## should update-grub create alternative automagic boot options
## e.g. alternative=true
## alternative=false
# alternative=true

## should update-grub lock alternative automagic boot options
## e.g. lockalternative=true
## lockalternative=false
# lockalternative=false

## additional options to use with the default boot option, but not with the
## alternatives
## e.g. defoptions=vga=791 resume=/dev/hda5
# defoptions=quiet splash vga=794 elevator=deadline

## should update-grub lock old automagic boot options
## e.g. lockold=false
## lockold=true
# lockold=false

## Xen hypervisor options to use with the default Xen boot option
# xenhopt=

## Xen Linux kernel options to use with the default Xen boot option
# xenkopt=console=tty0

## altoption boot targets option
## multiple altoptions lines are allowed
## e.g. altoptions=(...

Just adding more history to this bug report:

On Tue, 13 Jan 2009 17:48:54 -0800 (Wed, 01:48 GMT) Dean wrote:

> In any case, I went directly to the EXT4 Wiki & converted as per these instructions:
>
> To convert an existing ext3 filesystem to use ext4, use the command
>
> $ tune2fs -O extents,uninit_bg,dir_index /dev/DEV
>
>
> WARNING: Once you run this command, the filesystem will no longer be mountable using the ext3 filesystem!
>
> After running this command, you MUST run fsck:
>
> $ fsck -pf /dev/DEV
>
>NOTE: by doing so, new files will be created in extents format, but this will not convert existing files.
>However, they can be transparently read by Ext4.
>
>Wiki page: http://ext4.wiki.kernel.org/index.php/Ext4_Howto
>
>I wonder if I need to "recreate" my /boot & files within as EXT4--as I read this, I would "seem" to have a blend >of EXT3 & 4 that can only be read as EXT4....
>
>As for what grub reports--It looks like grub has not been setup--I just get a grub prompt with the normal >verbage that one sees when you are setting up grub. I'm going to delete & redo my /boot & then re-setup >grub on the partition--if it fails again, I will take a shot of the screen & send it to you......if it boots a normal, >we will know that the patch needs a "real" EXT4 set of files...either way...this is looking like a corner-case......

Just adding more history to this bug report:

Tue, 13 Jan 2009 18:36:58 -0800 (Wed, 02:36 GMT) Dean wrote:

More information (all good)--I backed up my /boot to a different
drive--then deleted it & re-installed it--thought was to recreate it as
a "real" EXT4 section & it worked that way--I reset grub to use it & it
had no problem once the /boot was done in "real" EXT4....I foresee many
problems that can spring from this with novice users that want the
"latest & greatest" & do not leave themselves a backdoor out...... ;)

Looks like grub needs to "tolerate" EXT3 within EXT4 partitions.....at
least within the /boot folder.....

I hope this has helped you a bit....

I've tried to reproduce this:

1. Installed Jaunty from daily build ISO of Wednesday 14th January 2009.
2. Installed with ext3 for /
3. Rebooted using the same live CD ISO image and then converted / to ext4 using:

tune2fs -O extents,uninit_bg,dir_index /dev/sda1
fsck -pf /dev/sda1

4. Rebooted, grub detects an ext4 partition and boots correctly.

and also:

So this simple case of converting / to ext4 seems to work for me. Now I will try and re-create Dean's set up and retry.

Still cannot reproduce this with i386 and AMD64 installations.

I'm going to install with alpha 3 tonight & see if I have any
problems....Maybe I just have a "funny" install......I'll post after I get
the new install going.

Cheers!!
Dean

On Thu, Jan 15, 2009 at 7:17 AM, Colin King <email address hidden> wrote:

> Still cannot reproduce this with i386 and AMD64 installations.
>
> --
> Patched grub will not boot from EXT4 partition
> https://bugs.launchpad.net/bugs/316872
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Got Alpha 3 installed--clean / partition as EXT4 & converted the existing /home from 3 to 4. Boots just fine with a fresh EXT4---So I know that my system did not have a problem---the install I had converted was a upgraded Intrepid install that was quite heavy with apps & custom bits.....My guess is that something did not take to the conversion well......I still have it--is there anything I need to look into log-wise or???

Cheers!!!!
Dean

I have the same problem today when I tried to migrate to ext4.

1. Up-to date jaunty with new grub
2. Used jaunty alpha 3 liveCD to convert partition
3. Via live-cd:
  tune2fs -O extents,uninit_bg,dir_index /dev/sda1
  fsck -pf /dev/sda1
  mount -t ext4 /dev/sda1 /disk
  vi etc/fstab (ext3 -> ext4)
  vi boot/grub/menu.lst (add rootfstype=ext4)
4. Reboot
5. Observing a grub prompt
6. grub>setup (hd0) doesn't help

I have only one partitions for boot, root and home.

I tested the Kubuntu 9.04 Alpha 3 (desktop CD x86).
I tried clean install.

Install setting (manual partition)
 /dev/sda5 is /boot as EXT4.
 /dev/sda6 is / as EXT4.
 /dev/sda7 is swap.

The grub was able to boot the kernel from /boot (EXT4).

I've re-tested with the following:

Jaunty amd64 Alpha3, installed with ext3:

/dev/sda1 /boot (ext3)
/dev/sda5 swap
/dev/sda6 / (ext3)

upgraded to ext4 and it works fine.

Vladimir: I did not add "rootfstype=ext4" to grub menu.lst. What happens when you comment out or remove this?

Colin

Colin, result is the same.

I've noticed that files stage1/2 on my machine are too old

  /boot/grub/e2fs-stage1_5 8660 modified:30 jan 2008 12:00:38
  /boot/grub/stage2 110292 modified:30 jan 2008 12:00:40

I suppose that it's not ok and these these files should be changed in grub...-ubuntu47. Right?

Another strange thing is that file /boot/grub/installed-version contains "0.97-29ubuntu4".

Vladimir,

You are correct - the stage1/2 fimages are way too old - hence the issue. The older grub will detect ext4 but will not be able to read any files on an ext4 filesystem.

I suggest re-running grub-install - I believe this will re-install the latest versions of stage1_5 and stage2 etc..

I've just checked the version of these files on another box (I have two with Jaunty) and it shows 0.97-29ubuntu47 installed (and it's good) but version of these files are the same: 30 jan 2008 (and that's not so good). I want to mention that these boxes are in continuos updating from Gutsy.

I resolved it by moving the files from liveCd (/usr/lib/grub/i386-pc) to /boot/grub and it works flawlessly.

Probably this issue was because neither post-install nor me invokes update-grub after updating.

update-grub wouldn't do it; it only deals with menu.lst. grub-install is not generally something that's safe to run automatically on upgrades; for one thing, it's entirely legitimate to have the grub package installed but not to have it installed in your MBR.

To be honest, this seems like a documentation issue more than anything else? If upgrading to ext4 (which already involves several manual steps), you need to rerun grub-install, and we should document that.

Just to clarify:

This is not a bug in the ext4 support in the grub boot loader, it's more of an issue that the update is not installing the new version of the grub stage1.5 and stage2 images. I'm not sure if this an issue of grub-update not doing this when it should or not.

grub-install should copy the latest grub stage1.5 and stage2 images from /usr/lib/grub/i386-pc to /boot/grub.

As explained in previous comments (and discussed in person with Colin King), this is not something we feel we can safely fix in grub; as such, I'm opening a task on ubuntu-release-notes so that we document this as part of any documentation about upgrading in-place to ext4.

Added this text:

Ext4 support in GRUB was provided by Colin King. If you choose to upgrade your `/` or `/boot` filesystem in place from ext2 or ext3 to ext4 (as documented on the [[http://ext4.wiki.kernel.org/index.php/Ext4_Howto#Converting_an_ext3_filesystem_to_ext4|ext4 wiki]]), then you ''must'' also use the `grub-install` command after upgrading to Ubuntu 9.04 Beta to reinstall your boot loader. If you do not do this, then the version of GRUB installed in your boot sector will not be able to read the kernel from the ext4 filesystem and your system will fail to boot.

keeping this task open since it will also need to be documented in the release notes, not just the technical overview.

Fix Committed for issues addressed in technical overview errata but not yet in release notes, as agreed with Steve on IRC.

copied the text to the release notes.

I've run into this same problem after converting root to ext4 after a Lucid upgrade.
As soon as any files used by grub (kernels, stage1, etc) get converted to extents, grub fails.

Running grub-install from a Lucid livecd CD did not help:

mount -t ext4 /dev/sda2 /mnt
grub-install --root-directory=/mnt /dev/sda

What seems to have fixed it was to boot from a Lucid livecd and do the following:

mount -t ext4 /dev/sda2 /mnt
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
chroot /mnt
grub-install /dev/sda

The 'rootfstype=ext4' kernel option does not seem to be necessary.

Upgrading to grub2 is not an option for me yet because of Bug #392158.