Bug 505846 - After upgrading root partition to ext4, Fedora will not boot
After upgrading root partition to ext4, Fedora will not boot
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
11
All Linux
low Severity low
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-14 05:56 EDT by Alexandr Kara
Modified: 2010-01-12 11:25 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-01-12 11:25:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
sasakara: fedora_requires_release_note?


Attachments (Terms of Use)

  None (edit)
Description Alexandr Kara 2009-06-14 05:56:44 EDT
* Description of problem:

After upgrading root filesystem to ext4, the system will not boot.

* How reproducible:

Possibly always (haven't tried multiple times)

* Steps to Reproduce:

change ext3 to ext4 in /etc/fstab for the root partition
# telinit 1
# mount -o remount,ro /
# tune2fs -O extents,uninit_bg,dir_index /dev/device
# fsck -pf /dev/device
# reboot

* Actual results:

Doesn't boot with a message like: "Cannot mount root filesystem, unsupported options(40)".

* Expected results:

Normal boot

* Additional info:

To solve the problem, I modified the initrd image manually - I changed "-t ext3" to "-t ext4" inside the "/init" file of the image.

I didn't run mkinitrd after filesystem upgrade, this might have helped.

I am adding this info in case somebody uses the same HOWTO and runs into problems.
Comment 1 Hans de Goede 2010-01-12 10:30:59 EST
This is a mass edit of all mkinitrd bugs.

Thanks for taking the time to file this bug report (and/or commenting on it).

As you may have heard in Fedora 12 mkinitrd has been replaced by dracut. In Fedora 12 the mkinitrd package is still around as some programs depend on
certain libraries it provides, but mkinitrd itself is no longer used.

In Fedora 13 mkinitrd will be removed completely. This means that all work
on initrd has stopped.

Rather then keeping mkinitrd bugs open and giving false hope they might get fixed we are mass closing them, so as to clearly communicate that no more work will be done on mkinitrd. We apologize for any inconvenience this may cause. 

If you are using Fedora 11 and are experiencing a mkinitrd bug you cannot work around, please upgrade to Fedora 12. If you experience problems with the initrd in Fedora 12, please file a bug against dracut.
Comment 2 udo 2010-01-12 10:49:05 EST
Are we yet sure the core issue is a mkinitrd one?
And that it won't harm dracut?
Please explain.
Comment 3 Hans de Goede 2010-01-12 11:25:18 EST
(In reply to comment #2)
> Are we yet sure the core issue is a mkinitrd one?
> And that it won't harm dracut?
> Please explain.    

The core issue in this case is that the user changed its rootfs type, without regenerating the initrd, so the initrd will still try to mount / as ext3, which fails as the kernel ext3 code does not support ext4 filesystems.

So you are right in this case, that this is not a case of closed -> wontfix, but a case of closed notabug.

Note that dracut does not suffer from this as the dracut generated initrd is
much more flexible and will happily deal with a change such as going from ext3 to ext4 without requiring the initrd to be regenerated.

Note You need to log in before you can comment on or make changes to this bug.