Red Hat Bugzilla – Bug 437567
anaconda: ext3->ext4 migration problems
Last modified: 2008-04-09 10:54:32 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. :)
@@ -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 "
- if entry.fsystem.getName() != "ext3":
+ if entry.fsystem.getName() != "ext4":
raise RuntimeError, ("Trying to migrate ext3 to something other "
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:
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
Fixed in git
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?
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
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....
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
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?
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.
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.
Haven't actually tested, but "if 0" looks pretty foolproof.