Description of problem: This problem exists in fedora 20, 21 and 22 but not CentOS 7 If you have an ext2 volume and it uses the ext4 driver (by having lvm or some ext4 volumes as well), if you fsfreeze then unfreeze the ext2 partition, the UUID dissappears from blkid for that ext2 volume. blkid -p on the specific volume yields nothing. To fix it, before you reboot, if you umount and mount the partition again, it will fix the UUID and the machine will boot ok. We also found that if you only have ext2 volumes you will get a 'not supported' error if you try to fsfreeze the ext2 volume, so we're thinking it's the ext4 driver that, when used to fsfreeze ext2, causes the problem. When you run fsfreeze the UUID is still there, it's when you fsfreeze --unfreeze that the problem happens. After you unfreeze, blkid will not show the UUID, but lsblk -f will. If you then refreeze the volume, the UUID will reappear in blkid while it's frozen, but disappear again when you unfreeze. Version-Release number of selected component (if applicable): We saw this in util-linux 2.24 and 2.25 How reproducible: Consistently. Steps to Reproduce: 1. install fedora core 20, 21 or 22 2. create an lvm or some ext4 volumes on the same disk 3. create a /boot volume with ext2 4. blkid (note the UUID) 5. fsfreeze --freeze /boot 6. fsfreeze --unfreeze /boot 7. blkid (note the lack of UUID) Actual results: No UUID for the ext2 volume Expected results: UUID should still exist for ext2 volume. Additional info: If you make ext2 volumes on one disk, and ext4 volumes on another disk, the problem will not happen. It seems to happen if there are ext2 and ext4 volumes mixed on the same block device, definitely happens if there's an lvm on the same disk. This was all tested on virtual machines (virtualbox) with fedora 20, 21 and 22 for different tests. The behavior was the same.
Ok, that's pretty weird. (I can see it here, too). Not sure what's up yet.
the needs_recovery feature is set when the fs is unfrozen (which is an odd thing to set on a filesystem w/o a journal) It's not set on the original mount, but is set after the filesystem is frozen & unfrozen. This probably confuses blkid's probing. Yup, derp: static int ext4_unfreeze(struct super_block *sb) { if (sb->s_flags & MS_RDONLY) return 0; /* Reset the needs_recovery flag before the fs is unlocked. */ EXT4_SET_INCOMPAT_FEATURE(sb, EXT4_FEATURE_INCOMPAT_RECOVER); it's setting it unconditionally. This shouldn't be set if it doesn't have a journal, I'll see how that regressed, and send a patch upstream. It looks like: commit 9ca92389c5312a51e819c15c762f0abdc7f3129b Author: Theodore Ts'o <tytso> Date: Fri May 1 12:52:25 2009 -0400 ext4: Use separate super_operations structure for no_journal filesystems By using a separate super_operations structure for filesystems that have and don't have journals, we can simply ext4_write_super() --- which is only needed when no journal is present --- and ext4_freeze(), ext4_unfreeze(), and ext4_sync_fs(), which are only needed when the journal is present. Signed-off-by: "Theodore Ts'o" <tytso> followed by: commit f6e63f90809946d410c42045577cb159fedabf8c Author: Theodore Ts'o <tytso> Date: Thu Sep 18 17:12:30 2014 -0400 ext4: fold ext4_nojournal_sops into ext4_sops There's no longer any need to have a separate set of super_operations for nojournal mode. Signed-off-by: Theodore Ts'o <tytso> messed this up. -Eric
I've sent a patch upstream for this.
Thanks, you rock, this was driving us nuts. Much appreciated.
(In reply to Eric Sandeen from comment #3) > I've sent a patch upstream for this. Got a URL to the thread?
http://www.spinics.net/lists/linux-ext4/msg48688.html
(In reply to Eric Sandeen from comment #6) > http://www.spinics.net/lists/linux-ext4/msg48688.html Should probably CC stable? I'd reply on-list, but I'm not subscribed to the fs-specific lists.
I suppose; it's kind of a corner case, but probably worth fixing up.
Has the fix been pushed to stable kernels yet?
It's had no response on the ext4 list yet. :(
(In reply to Eric Sandeen from comment #10) > It's had no response on the ext4 list yet. :( Right. Not that I don't trust Eric entirely, but I at least wanted to see if upstream had a comment before backporting.
Would it be possible to introduce this fix into the Fedora kernels while we wait for it to be upstreamed?
Oops, it has been reviewed and declared good[0]. So backporting should be okay too. [0]: http://www.spinics.net/lists/linux-ext4/msg48740.html
Added in Fedora git.
kernel-4.2.0-0.rc8.git0.1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-14151
kernel-4.2.0-0.rc8.git0.1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
kernel-4.1.6-201.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-15130
kernel-4.1.6-201.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-15130
kernel-4.1.6-201.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
kernel-4.1.7-100.fc21 has been submitted as an update to Fedora 21. https://bodhi.fedoraproject.org/updates/FEDORA-2015-15933
kernel-4.1.7-100.fc21 has been pushed to the Fedora 21 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-15933
kernel-4.1.7-100.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.