Description of problem: I have failed to install fedora 30 on 2 different PC that use bcache (SSD + HDD). After installation, fsck in initramfs declares that the root file system is corrupted (clean flag is set in superblock, but journal contains data). Therefore the system cannot boot. Used manually, fsck find errors in ext4 filesystem (or create ones). the only way I found to get back was a clean reinstall of Fedora 29. The problem for me is clearly fsck, that finds unexisting erros, and eventually creates new ones. This bug is critical !!! Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Please provide actual e2fsck output or other logs, so we know what is actually happening here.
We'll also need to know how you set up your storage, as it seems quite likely that the root cause may be storage related. If Fedora 30 failed to install on a standard storage setup, we'd have many more bug reports.
On both PCs, I use a bcache frontend in a SDD. The bache backend is in one case case a hDD partition, in the other case a raid array (mdadm raid1) Bcache devices are used as a physical volumes for an LVM volume group. Then logical volumes are created in the volume group. There are all ext4 except a swap volume. I agree with you, the problem comes probably from this complex approach. But it has been working perfectly for several years (at least since fc23), and no problem during upgrades. It still works after going back to fc29 (home partition is OK, after apperaring corrupted with fsck/fc30). Il will reinstall fc30 and send you logs.
I have big trouble in doing a fresh install of fedora 30 on my configuration. I have defined a simple configuration : a new logical volume (new_root), and I reuse /boot, /boot/efi. Anaconda fails during storage definition (formating the new volume, new-root). When I restart under fc29, the boot process stops in emergency mode, with the same issue, on /root, which shouldn't have been impacted : fsck says the clean bit is set in the superblock, but the journal contains data. Running fsck (fc29) finds orphaned inodes, and inconsistencies in the bitmap (pass 5). fsck (fc29) is able to correct everything, and restart, but there is a big big problem in my storage configuration, with fsck/mkfs (ext4) on fc30.
We're not going to be able to do much without actual logs. I can't translate a verbal narrative of fsck behavior into the actual e2fsck code. As far as I know, e2fsck never emits the message "clean bit is set in the superblock, but the journal contains data" If anaconda is failing, please attach all of the anaconda logs.
Created attachment 1566387 [details] Install log of Fedora 30
Created attachment 1566388 [details] Fsck (script command) of home filesystem
Created attachment 1566389 [details] Fsck (script command) of new_root filesystem Sorry, it's in French
That's what I did : 1/ Try to install Fedora 30 from live USB 2/ Failed after creating the ext4 fs on new_root, in the process of creation of swap -> See Install log 3/ mounted my home partition to save Install log and cleanly unmounted it 4/ rebooted under Fedora 29 5/ Boot process exited in emergency mode because home fs was not clean 6/ Fsck home filesystem -> See log 7/ Ended boot 8/ Fsck the new_root filesystem, created under Fedora 30, under Fedora 29 ; many errors, see log Clearly there is a problem in my configuration : as soon a a filesystem is created / written in Fedora 30, it appears as corrupted. Ps : that's what I saw many times on my first PC and yesterday : /dev/....: recovering journal Superblock needs_recovery flag is clear, but journal has data. Run journal anyway? yes See : https://ubuntuforums.org/showthread.php?t=2282368
The new root filesystem doesn't even have a proper magic value: > ext2fs_open2: Numéro magique invalide dans le super-bloc this really points to a storage problem, not an ext4 problem. I would suggest installing without bcache; if that works, you know the problem lies with storage, and you'll need to find someone who understands bcache to help you with your bug.
*** This bug has been marked as a duplicate of bug 1708315 ***