Solved Kernel panic when copying from ext4 partition to UFS

willbprog127

willbprog127

Greetings everyone,

I already submitted a bug report for this, (PR 205932) but thought I'd post here anyway.

After a fresh, clean install of FreeBSD 10.2 amd64 on modern hardware, before installing any ports or packages, I mounted an ext4 partition read-only from device ada1 on /mnt/adisk on my root FreeBSD partition (UFS), which is on device ada0.

I issued the following commands, which causes a kernel panic every time:

Code: 
# mount -t ext2fs -o ro /dev/ada1p4 /mnt/adisk

# cd /mnt/adisk

# ls
lost+found will

# cp -Rnv will /home/will
After about 100 files are copied (very rough estimate), that's when the kernel panic happens. The kernel panic string is:

Code: 
__lockmgr_args: recursing on non recursive lockmgr getblk @ (null):0
I checked if the kernel panic happens right after booting into the new install, as well as after performing freebsd-update(8) and the kernel panic happened in both instances.

I have mounted the same exact partition before and copied the same exact files using mc and pcmanfm and have not regularly experienced kernel panics that way. The last kernel panic I had was on other hardware almost seven months ago and that was during a long file copy.

Has anyone else experienced this issue? Any ideas?

freebsd-cp-kernel-panic-2016-01-05.jpg


EDIT - 2016-01-05 - 21:13
Testing the same ext4->UFS copy with FreeBSD 10.2 amd64 on VirtualBox also yields the same kernel panic with the same panic type, so it appears to rule out hardware.
 
Last edited by a moderator:
willbprog127 said:
Any ideas?
Click to expand...
The last time I moved some data from ext* to UFS I made a tar archive of the relevant data. Then I used a FAT partition as transfer section. It can be that at this time ext* access from FreeBSD was not considered 100% stable. It was not ext4. I made the archives for back up , too. And as far as I remember I had a FAT partition anyhow at this time. By the way, I do not know the difference between ext2/ext3 and ext4. But as far as I know today ext2 or ext3 should be fine for transfer, too. This is no solution, just an idea ;).
 
chrbr said:
The last time I moved some data from ext* to UFS I made a tar archive of the relevant data. Then I used a FAT partition as transfer section. It can be that at this time ext* access from FreeBSD was not considered 100% stable. It was not ext4. I made the archives for back up , too. And as far as I remember I had a FAT partition anyhow at this time. By the way, I do not know the difference between ext2/ext3 and ext4. But as far as I know today ext2 or ext3 should be fine for transfer, too. This is no solution, just an idea ;).
Click to expand...
Thanks for that :)

I actually can copy just fine using Midnight Commander and PCManFM, however I wanted to post this to see if anyone else had seen this before, and to bring it to everyone's attention. I mean, wow, a kernel panic just because I'm copying some files? That's kinda stinky...

Thanks again chrbr! :)
 
The handbook https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/filesystems-linux.html says
Code: 
This driver can also be used to access ext3 and ext4 file systems. However, ext3 journaling, extended attributes, and inodes greater than 128-bytes are not supported. Support for ext4 is read-only.
Therefore there should be no kernel panic. On the other hand mount (8) says
Code: 
BUGS -  It is possible for a corrupted file system to cause a crash.
Therefore it might be safe to check the health of the ext4 file system and may be of the disk. Depending on the result you can still de-assert the alert and the problem report.

If there is an issue with sane file systems you have saved a lot of potential new users a lot of headaches.
 
chrbr said:
If there is an issue with sane file systems you have saved a lot of potential new users a lot of headaches.
Click to expand...
Yes, the ext4 partition I'm accessing is fine and has been checked. It's most definitely something to do with FreeBSD itself as I've created the same conditions in a virtual machine and it does the exact same kind of kernel panic as on real metal. :(
 
tingo said:
I have seen this before, unfortunately it seems I forgot to document it and report a bug on it. :-/
Click to expand...
It happens. There are many times I don't report bugs with various projects because 1) It's too much like real work signing up and filing the report and 2) They usually ignore my reports. In this case, I reported for me and you. ;)
 
You must log in or register to reply here.
Back
Top