Hello, On 23 November 2014 at 06:27, Philip Guenther <guent...@gmail.com> wrote: > On Wed, 12 Nov 2014, Nikos Skalkotos wrote: >> Hello, here is the complete output: > > okay, fdisk output and disklabel output look sane and match up. > > The diff of the dumpfs output is interesting: > > -^magic 11954 (FFS1) time Wed Nov 12 10:13:55 2014 > +^magic 11954 (FFS1) time Wed Nov 12 10:19:09 2014 > -ncg 6 ncyl 6 size 522096 blocks 512247 > +ncg 505 ncyl 505 size 52350320 blocks 51522108 > -nbfree 36554 ndir 1011 nifree 141082 nffree 208 > +nbfree 6412786 ndir 1011 nifree 13107098 nffree 213 > -csaddr 1648 cssize 2048 > +csaddr 1648 cssize 8192 > > Note the cssize (cylinder summary size) has grown but csaddr hasn't > changed. That means it probably had to relocate allocated blocks. This > being your root disk, it may have relocated blocks in /boot, which would > require re-running installboot. > > (FreeBSD has actually deleted the code to support that and made their > growfs always relocate the cylinder summary to the first of the new > cylinder groups; we may want to do that too; moving allocated blocks > around is a nasty wart.) > > There may also be bugs around growfs assuming the new area is zero-filled, > which it might not be. It may be a good test to try zeroing the new area > with dd before running growfs and see if that makes it behave correctly. >
I tried zeroing the space first, and then copying the openbsd image into the zeroed space like this: # lvcreate -L 100G -n test images Logical volume "test" created # dd if=/dev/zero of=/dev/images/test bs=4M dd: writing `/dev/images/test': No space left on device 25601+0 records in 25600+0 records out 107374182400 bytes (107 GB) copied, 172.191 s, 624 MB/s # dd if=/dev/images/openbsd-5.6 of=/dev/images/test bs=4M 256+0 records in 256+0 records out 1073741824 bytes (1.1 GB) copied, 5.06499 s, 212 MB/s But I get the very same error after resizing. I don't think this is it. > >> uvm_fault(0xffffffff81d97be0, 0xffffffff8d2a5811, 0, 2) -> e >> kernel: page fault trap, code=0 >> Stopped at worklist_print+0x26b: addb %al,acpi_pdirpa+0xbfeeac0 >> ddb> trace >> worklist_print() at worklist_print+0x26b >> ffs_init() at ffs_init+0xa4 >> vfs_register() at vfs_register+0x94 >> vfsinit() at vfsinit+0x80 >> main() at main+0x457 >> end trace frame: 0x0, count: -5 >> ddb> > > That's an odd place to crash, having nothing to do with the filesystem > itself; that's just where it hooks in the code to support FFS filesystems > at all. Being not directly related makes me wonder if growfs is > corrupting your kernel by its relocating of blocks from the first cylinder > group... > > > Philip Guenther Nikos P.S. I tried sending the same mail from skalk...@grnet.gr a few hours ago but It hasn't reached the list yet. I don't know what's going on. I 'll try to only answer from gmail from now on.
