Fedora 16 with BTRFS - kernel panic

[dally_z]

Hi guys,

your help would be really appreciated.

I have a fresh installation of F16 64 bit. Decided to use BTRFS file system. The oldest kernel is alright, can boot to the system. Any new one gives me an error in pictures.

Bootable one is 3.3.1

Non-bootable ones are 3.3.4, 3.3.5

Also root partition has size of 300 MB, but values in used/avaliable doesn't give me summary of 300 MB.

Thank you.

Dali

[Gareth Jones]

What does /boot/grub2/grub.cfg look like?

[sea]

Why have you cut out so much of the text of the panic screen?
As its not working, that text might be required -> only 'blur' those areas that are sensitive.

[dally_z]

Thanks guys for reply.

@Sea, sorry, was limited by picture size

@Gareth, here is a part of my grub.cfg file. I am currently running the latest kernel, was able to boot it.

menuentry 'Fedora (3.3.5-2.fc16.x86_64)' --class fedora --class gnu-linux --class gnu --class os {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod btrfs
set root='(hd0,msdos3)'
search --no-floppy --fs-uuid --set=root 7ed51ac6-b21a-4bf8-87df-dd6835fe3b56
echo 'Loading Fedora (3.3.5-2.fc16.x86_64)'
linux /vmlinuz-3.3.5-2.fc16.x86_64 root=UUID=fa1ce61c-94f0-42b7-9294-75e069637c15 ro rd.md=0 rd.lvm=0 rd.dm=0 SYSFONT=latarcyrheb-sun16 KEYTABLE=uk rd.luks=0 LANG=en_US.UTF-8
echo 'Loading initial ramdisk ...'
initrd /initramfs-3.3.5-2.fc16.x86_64.img
}
menuentry 'Fedora (3.3.4-1.fc16.x86_64)' --class fedora --class gnu-linux --class gnu --class os {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod btrfs
set root='(hd0,msdos3)'
search --no-floppy --fs-uuid --set=root 7ed51ac6-b21a-4bf8-87df-dd6835fe3b56
echo 'Loading Fedora (3.3.4-1.fc16.x86_64)'
linux /vmlinuz-3.3.4-1.fc16.x86_64 root=UUID=fa1ce61c-94f0-42b7-9294-75e069637c15 ro rd.md=0 rd.lvm=0 rd.dm=0 SYSFONT=latarcyrheb-sun16 KEYTABLE=uk rd.luks=0 LANG=en_US.UTF-8
echo 'Loading initial ramdisk ...'
initrd /initramfs-3.3.4-1.fc16.x86_64.img
}

---------- Post added at 07:24 PM ---------- Previous post was at 07:22 PM ----------

Maybe this part is interesting from boot.log:

systemd-fsck[946]: fsck: fsck.btrfs: not found
systemd-fsck[946]: fsck: error 2 while executing fsck.btrfs for /dev/sda5
systemd-fsck[881]: fsck: fsck.btrfs: not found
systemd-fsck[881]: fsck: error 2 while executing fsck.btrfs for /dev/sda3
Started File System Check on /dev/disk/by-uuid/0f52c8dd-5184-44dd-a270-9bbc51b4ff73

---------- Post added at 07:28 PM ---------- Previous post was at 07:24 PM ----------

Also

/dev/sda3 300M 51M 19M 74% /boot

[stevea]

Should work. I *suspect* when you did a yum install of the newer kernels that the btrfs.ko loadable file system was not included in the initramfs created.

You can list the modules included and look for loadables like this ...
gzip -d </boot/initramfs-3.3.0.XXXX.img | cpio -itv | grep ko #fill-n YOUR initramfs file name


I thought dracut was 'sposed to examine your fstab and loaded modules for fs types. Unclear.


p.s. your grub looks good, but that insmod is just for grub and doesn't replace the initramfs.

[dally_z]

Hi Stevea,

thanks for your reply.

Don't know what to look at. The output from your command is in attached file.

Dali.

[marko]

It's kind of weird that the boot.log shows it looking for fsck.btrfs, the fsck tool for btrfs is called /sbin/btrfsck

[stevea]

Originally Posted by dally_z

Don't know what to look at. The output from your command is in attached file.

-rwxr--r-- 1 root root 1079056 May 8 12:59 run/initramfs/lib/modules/3.3.5-2.fc16.x86_64/kernel/fs/btrfs/btrfs.ko

So the 'driver' is included and I see the default dracut udev config loads btrfs,ko as needed. That's not the problem.

Originally Posted by marko

It's kind of weird that the boot.log shows it looking for fsck.btrfs, the fsck tool for btrfs is called /sbin/btrfsck

Not strange. systemd calls systemd-fsck which call "fsck -t fstype" which tries to call /sbin/fsck.$fstype (like fsck.ext4 or fsck.vfat). But there is no /sbin/fsck.btrfs Maybe this is b/c the btrfs fsck is incomplete or doesn't take the 'standard' arguments.

Personally I'd create a dummy script at /sbin/fsck.btrfs, like:
#!/bin/bash
return 0

just to shutup systemd.

[marko]

Originally Posted by stevea

Personally I'd create a dummy script at /sbin/fsck.btrfs, like:
#!/bin/bash
return 0

just to shutup systemd.

another good way might be:

ln -s /bin/true /sbin/fsck.btrfs

[dally_z]

Thanks a lot for your explanation.

Do you recommend to reinstall the system or it's possible to do something with btrfs components.

As I mentioned before, there is something wrong with this partition:

/dev/sda3 300M 51M 19M 74% /boot (used/available gives me 70MB)

Installation went alright all the way, computer is brand new one.

Thinking to reinstall it with F17 and ext4 in a week time.

[Gareth Jones]

btrfs looks like it is included in the initramfs from the file you posted.

If the problem is the missing fsck.btrfs (which wouldn't explain why it appears to be kernel-dependent), you could try symlinking fsck.btrfs to btrfsck (risky!), or change the last number on the corresponding lines in /etc/fstab from 1 to 0, to disable automatic checking for the btrfs volumes.

I can't see anything wrong with the GRUB config either.

[dally_z]

Another update for kernel. This time it's version 3.3.6. And again I was not able to boot, getting errors mentioned above.

I have found a solution to recreate image:

# dracut /boot/initramfs-3.3.6-3.fc16.x86_64.img 3.3.6-3.fc16.x86_64

After this command execution I am able to boot to the latest kernel.

However, there is still remaining problem with displaying/using boot partition (BTRFS file system).

/dev/sda3 300M 51M 19M 74% /boot (used/available gives me 70MB in total, not 300MB) - where is the rest of space

Therefore I can keep only 2 kernel installations.

Any ideas?

Thank you.

Dali.

[Gareth Jones]

It might make your life easier to reformat /boot as ext4. There's not really any benefit to using btrfs on /boot, at least until Red Hat etc. make it the official default for their systems and it can be considered 'final'. There are potential disadvantages in that btrfs uses more space for meta-data (file-system structure etc.), and if /boot is snapshotted by yum when updating, the old kernels probably aren't really being removed.

[dally_z]

Hi Gareth,

thanks a lot for your feedback/help.

I will reformat boot partition as you recommend.

Thanks again.

Dali.