Bug 437567 - anaconda: ext3->ext4 migration problems
Summary: anaconda: ext3->ext4 migration problems
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda   
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: F9Blocker
TreeView+ depends on / blocked
Reported: 2008-03-14 21:55 UTC by Eric Sandeen
Modified: 2008-04-09 14:54 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-09 14:54:32 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Eric Sandeen 2008-03-14 21:55:37 UTC
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 22:12:57 UTC
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 22:24:57 UTC
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 22:36:11 UTC
Fixed in git

Comment 4 Eric Sandeen 2008-03-17 15:06:13 UTC
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 15:24:33 UTC
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 21:38:32 UTC
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 15:17:44 UTC
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 15:27:07 UTC
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 15:57:10 UTC
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 16:09:51 UTC
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 14:54:32 UTC
Haven't actually tested, but "if 0" looks pretty foolproof.


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