Ask Your Question

Kernel 3.11 & BTRFS: system doesn't boot

asked 2013-09-21 05:26:59 -0500

Jmlevick gravatar image

updated 2014-09-28 21:10:23 -0500

mether gravatar image

Today I ran a regular "sudo yum -y update" and Fedora just "blew up in my face" with the following screen after a reboot:

if I issue the "journalctl" command I can see a BTRFS error:

(My system's root partition is in BTRFS).

And as far as I've googled no one had this issue before and to be honest, I don't know how to solve it...

The "sosreport.txt" file just doesn't copy anywhere, I plug a USB in and then run:

cp /run/initramfs/sosreport.txt /dev/sdc1

and the command apparently runs successfully but when I check the USB it is empty, same if I save it to "/var" "/var/log" or "/usr", the file just doesn't appear anywhere. I ran "cat" on such file and it is enormous to photograph it, but I took another pic that might be helpful:

It's worth to mention that I don't have any propietary drivers running on this system and if I boot with the last kernel before the update (which is 3.10.11-200.fc19.x86_64) everything works normally. The problematic kernel version is the 3.11.1-200.fc19.x86_64 one.

Here you have my partition table:

And my lspci output is here:

Does anyone know how to solve this?


P.S. With kernel 3.12.0-0.rc1.git3.1.fc21.x86_64 (a debug kernel from rawhide) the problem is not present.

edit retag flag offensive close merge delete

2 Answers

Sort by » oldest newest most voted

answered 2013-09-21 13:39:35 -0500

Jmlevick gravatar image

I've solved it, My process was the following:

1) Reboot into an older kernel, remove the problematic kernel's individual packages as root with rpm -e --nodeps once per package (The removed packages were kernel, kernel-devel, kernel-headers, kernel-modules-extra).

2) Install a newer kernel (a debug one) from rawhide

3) Boot into the debug kernel

4) Ran a 'yum -y update kernel-* --enablerepo=updates-testing', This step updated the older kernel to the problematic one.

5) Install the problematic kernel's individual packages from "updates-testing" repo (in case something was missing. For example in this case, kernel-headers-3.11.x-xxx.fc19.x86_64 did not installed with the update).

6) Remove Rawhide's kernel individual packages and reboot.

7) Booting in the previously problematic kernel (which now works!) And cleaning up the system with:

su -
yum-complete-transaction --cleanup-only
package-cleanup --orphans
package-cleanup --cleandupes
yum repolist
yum clean all
yum makecache
yum -y update

And that's all, now my computer is hapilly booting with 3.11.1-200.fc19.x86_64 I hope this helps anyone who stumbles upon this issue ;)

edit flag offensive delete link more

answered 2013-09-21 12:32:16 -0500

harald gravatar image

updated 2013-09-21 12:48:38 -0500

cp /run/initramfs/sosreport.txt /dev/sdc1

don't do that!! you have to mount it first!!

# mkdir -p /mnt
# mount /dev/sdc1 /mnt 
# cp /run/initramfs/sosreport.txt /mnt
# umount /mnt

If you copy it to /usr or /var that will not work, because the disk is not yet mounted.

edit flag offensive delete link more


Thanks for the tip! I already fixed the actual issue but it's good to know how to correctly copy the sosreport.txt file ;)

Jmlevick gravatar imageJmlevick ( 2013-09-21 13:41:18 -0500 )edit

Indeed, if you have privileges to write to sdc1, that command will write sosreport.txt’s contents directly over the partition table and super block, corrupting the device’s file-system. I hope it was already blank!

Gareth Jones gravatar imageGareth Jones ( 2013-09-22 18:03:40 -0500 )edit

Question Tools


Asked: 2013-09-21 05:26:59 -0500

Seen: 1,344 times

Last updated: Sep 21 '13