Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.

Bug 437567

Summary: anaconda: ext3->ext4 migration problems
Product: [Fedora] Fedora Reporter: Eric Sandeen <esandeen>
Component: anacondaAssignee: Jeremy Katz <katzj>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-04-09 10:54:32 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 235706    

Description Eric Sandeen 2008-03-14 17:55:37 EDT
Just quickly filing a bug, haven't had time to look into it yet.

Wanted to try an F8/ext3 -> F9/ext4 migration.

First slight oddity is that when I chose the upgrade path, it told me all about
how it could migrate from ext2 to ext3... and let me select my existing ext3
filesystems to migrate(!)  I guess it needs different text for ext3->ext4 migration.

Also, /boot should be excluded from this option since grub doesn't (yet?) grok ext4.

Finally when I said yes, please migrate / (which was on ext3) I got a traceback:
"Trying to migrate ext3 to something other than ext4" ... ?

So maybe it's trying to migrate ext3 to ext3.  :)
Comment 1 Eric Sandeen 2008-03-14 18:12:57 EDT
Probably need:

--- anaconda-
+++ anaconda-
@@ -745,7 +745,7 @@ class ext3FileSystem(extFileSystem):
         if not entry.fsystem or not entry.origfsystem:
             raise RuntimeError, ("Trying to migrate fs w/o fsystem or "
                                  "origfsystem set")
-        if entry.fsystem.getName() != "ext3":
+        if entry.fsystem.getName() != "ext4":
             raise RuntimeError, ("Trying to migrate ext3 to something other "
                                  "than ext4")

but also, UpgradeMigrateFSWindow in iw/upgrade_migratefs_gui.py looks like maybe
it needs to be taught about other types of migration:

        for (cb, entry) in self.cbs:
            if cb.get_active():

Comment 2 Jeremy Katz 2008-03-14 18:24:57 EDT
Err, the first chunk is very out of date.  For the second, yeah we need to do
something.  I'll see if I can cook something simple up for the beta, if not
we'll deal with it post-beta
Comment 3 Jeremy Katz 2008-03-14 18:36:11 EDT
Fixed in git
Comment 4 Eric Sandeen 2008-03-17 11:06:13 EDT
Jeremy, thanks... minor nit on the text:

+       text = (_("This release of %s supports "
+                 "the an updated file system, which has several "
+                 "benefits over the file system traditionally shipped "
+                 "in %s.  This installation program can migrate "
+                 "formatted partitions without data loss.\n\n"
+                 "Which of these partitions would you like to migrate?") %

"the an updated file system..."

Would it make any sense to put this help text into each filesystem's migration
method, so it can be differentiated?

Comment 5 Jeremy Katz 2008-03-17 11:24:33 EDT
The problem is you could have an ext2 filesystem, an ext3, a something else to
be migrated, etc.  Which makes adding text for each a little less appealing.  So
I just made the text generic instead
Comment 6 Eric Sandeen 2008-03-31 17:38:32 EDT
So, it appears that this still fails.

It looks like anaconda mounts /mnt/sysimage and all the relevant subdirs, and
*then* runs the migrate routine... which means we'll be ext4 on the *next*
mount, but not on this one, which means that our chance to replace most ext3
files in ext4 format during the upgrade is lost.

Any chance this can be fixed, or is it too much of an architectural change at
this point... I couldn't see how to unmount the system, frob the filesystems we
wish to upgrade, and then remount it....

Comment 7 Jeremy Katz 2008-04-01 11:17:44 EDT
Hmmmm...  I see what's going on.  I fixed it for the migrate on an install case,
but not the migrate on upgrade.  And I now vaguely remember this being a problem
for migrations to ext3 even.  The right fix is to move some things around a bit,
but that's not really safe to do at this point.

I've filed something (bug 440055) to track this for F10.  But the basics do
work, you do get migrated, etc.  Even if it's not ideal.  It's still hidden
away, so the people getting it in theory will already somewhat know what they're
getting into.
Comment 8 Eric Sandeen 2008-04-01 11:27:07 EDT
Ok, I expected that it was probably too latea.

So migrate on install means installing to a partition which is already formatted
as ext3, with an existing root fs, and not re-formatting  during install?  Hm,
do people do that..? :)

For ext3 it was a bit better, because the files' on-disk format didn't change;
when you rebooted you truly had your OS on ext3.

In this case, not so much.  Until you have yum updated most of your system
you've got mostly ext3, slowly inching towards ext4...

I think I'd rather just disallow this path for now; I'm not sure it adds much,
and bugs will be time bombs....

People could manually upgrade by turning their root fs into ext4 via the rescue
disk or something, then launching an upgrade, and it'd accomplish this goal better.

What do you think?

Comment 9 Jeremy Katz 2008-04-01 11:57:10 EDT
It's more common with filesystems that aren't / like /home and /usr/local.

If you want, it's easy enough to disable the migration to ext4, but it'd be for
both the install and the upgrade case.
Comment 10 Eric Sandeen 2008-04-01 12:09:51 EDT
I think it makes sense to just disable it.

I don't think there's a lot of benefit to simply setting the flag in "migration"
- cutting-edge users can do this on their own.  If it had worked for the root,
it was worthwhile because most files would be replaced in ext4 format.  Simply
setting the fs as ext4 for the *next* mount of /home really doesn't need to be
done in the installer, IMHO.
Comment 11 Eric Sandeen 2008-04-09 10:54:32 EDT
Haven't actually tested, but "if 0" looks pretty foolproof.