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. :)
Probably need: --- anaconda-11.4.0.33.orig/fsset.py +++ anaconda-11.4.0.33/fsset.py @@ -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(): entry.setFileSystemType(fileSystemTypeGet("ext3")) entry.setFormat(0) entry.setMigrate(1)
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? Thanks, -Eric
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.... Thanks, -Eric
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.
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? Thanks, -Eric
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. Thanks, -Eric