kernel page fault trap
40 views
Skip to first unread message
Nikos Skalkotos
Nov 11, 2014, 8:18:23 AM11/11/14
to mi...@openbsd.org, synnef...@googlegroups.com
Hello all,
I have a kernel page fault in OpenBSD 5.6 100% reproducible (I think I
can reproduce it in older versions too).
I've created an OpenBSD installation in Linux through kvm on a 1GB hard
disk with just a root partition (a), by booting the install56.iso cdrom
with a command like this:
kvm -smp 1 -m 2048 -boot d -drive \
file=/dev/images/openbsd-5.6,format=raw,cache=none,if=virtio -cdrom
/tmp/install56.iso -vnc :0
The system boots fine with a command like this:
kvm -m 2048 -drive file=/dev/images/openbsd,format=raw,cache=none,if=virtio
If I then copy it into a 100GB volume:
dd if=/dev/images/openbsd of=/dev/images/tmp1 bs=4M
And try to boot it, it still boots fine. I then boot into the VM's
rescue disk:
> boot bsd.rd
and press S to get a shell
I mount the root partition and grab growfs program:
# mount /dev/sd0a /mnt
# cp /mnt/sbin/growfs .
# umount /mnt
Fix the MBR to use the entire disk:
# fdisk -i wd0
And change the disklabel:
disklabel -E sd0
Change the OpenBSD boundaries to cover the whole disk:
> b
Starting sector: [64]
Size ('*' for entire disk):[] *
and then grow the root partition to make it 100GB log:
> c
partition to change size: [] a
Then grow the underlying FFS file system:
growfs /dev/sd0a
If I then reboot, the ffs driver crashes with errors like this:
uvm_fault(0xffffffff81dcddc0, 0xc000068, 0, 2) -> e
kernel: page fault trap, code=0
Stopped at ffs_vget+0x115: addb %al, 0(%rcx,%rax,1)
ddb>
Am I missing something or is this a kernel/growfs bug?
Nikos Skalkotos
I have a kernel page fault in OpenBSD 5.6 100% reproducible (I think I
can reproduce it in older versions too).
I've created an OpenBSD installation in Linux through kvm on a 1GB hard
disk with just a root partition (a), by booting the install56.iso cdrom
with a command like this:
kvm -smp 1 -m 2048 -boot d -drive \
file=/dev/images/openbsd-5.6,format=raw,cache=none,if=virtio -cdrom
/tmp/install56.iso -vnc :0
The system boots fine with a command like this:
kvm -m 2048 -drive file=/dev/images/openbsd,format=raw,cache=none,if=virtio
If I then copy it into a 100GB volume:
dd if=/dev/images/openbsd of=/dev/images/tmp1 bs=4M
And try to boot it, it still boots fine. I then boot into the VM's
rescue disk:
> boot bsd.rd
and press S to get a shell
I mount the root partition and grab growfs program:
# mount /dev/sd0a /mnt
# cp /mnt/sbin/growfs .
# umount /mnt
Fix the MBR to use the entire disk:
# fdisk -i wd0
And change the disklabel:
disklabel -E sd0
Change the OpenBSD boundaries to cover the whole disk:
> b
Starting sector: [64]
Size ('*' for entire disk):[] *
and then grow the root partition to make it 100GB log:
> c
partition to change size: [] a
Then grow the underlying FFS file system:
growfs /dev/sd0a
If I then reboot, the ffs driver crashes with errors like this:
uvm_fault(0xffffffff81dcddc0, 0xc000068, 0, 2) -> e
kernel: page fault trap, code=0
Stopped at ffs_vget+0x115: addb %al, 0(%rcx,%rax,1)
ddb>
Am I missing something or is this a kernel/growfs bug?
Nikos Skalkotos
Nikos Skalkotos
Nov 11, 2014, 8:44:06 AM11/11/14
to mi...@openbsd.org, synnef...@googlegroups.com
Nikos Skalkotos
Janne Johansson
Nov 12, 2014, 3:17:43 AM11/12/14
to Nikos Skalkotos, Philip Guenther, Nikos Skalkotos, OpenBSD misc, synnef...@googlegroups.com
Can't you make the kvm run the console as a "serial" and then telnet or something to get that serial output from the guest?
2014-11-11 22:12 GMT+01:00 Nikos Skalkotos <skal...@gmail.com>:
Hello,
Is there a way to output the rescue disk console on a serial port? It
will help for the copy-paste because I don't have physical access to
the server I'm running the VM's and I'm using VNC to grab the console.
> On Tue, Nov 11, 2014 at 5:43 AM, Nikos Skalkotos <skal...@grnet.gr> wrote:
>> I have a kernel page fault in OpenBSD 5.6 100% reproducible (I think I
>> can reproduce it in older versions too).
>>
>> I've created an OpenBSD installation in Linux through kvm on a 1GB hard
>> disk with just a root partition (a), by booting the install56.iso cdrom
>> with a command like this:
>>
>> kvm -smp 1 -m 2048 -boot d -drive \
>> file=/dev/images/openbsd-5.6,format=raw,cache=none,if=virtio -cdrom
>> /tmp/install56.iso -vnc :0
>>
>> The system boots fine with a command like this:
>> kvm -m 2048 -drive file=/dev/images/openbsd,format=raw,cache=none,if=virtio
>>
>> If I then copy it into a 100GB volume:
>> dd if=/dev/images/openbsd of=/dev/images/tmp1 bs=4M
>>
>> And try to boot it, it still boots fine. I then boot into the VM's
>> rescue disk:
> ...
>> Fix the MBR to use the entire disk:
>> # fdisk -i wd0
>>
>> And change the disklabel:
>>
>> disklabel -E sd0
> ...
>
> To make it easier to analyze and reproduce this, can you provide the
> output of fdisk and disklabel both before changing anything and then
> again afterwards?
>
> Hmm, and how about the output of
> dumpfs /dev/rsd0a | head -23
> before and after too?
>
>
> Philip Guenther
May the most significant bit of your life be positive.
Theo de Raadt
Nov 12, 2014, 3:17:43 AM11/12/14
to mi...@openbsd.org, skal...@grnet.gr, synnef...@googlegroups.com
>I have a kernel page fault in OpenBSD 5.6 100% reproducible (I think I
>can reproduce it in older versions too).
>
>I've created an OpenBSD installation in Linux through kvm on a 1GB hard
>disk with just a root partition (a), by booting the install56.iso cdrom
>with a command like this:
>
>kvm -smp 1 -m 2048 -boot d -drive \
>file=/dev/images/openbsd-5.6,format=raw,cache=none,if=virtio -cdrom
>/tmp/install56.iso -vnc :0
>
>The system boots fine with a command like this:
>kvm -m 2048 -drive file=/dev/images/openbsd,format=raw,cache=none,if=virtio
>
>If I then copy it into a 100GB volume:
>dd if=/dev/images/openbsd of=/dev/images/tmp1 bs=4M
>
>And try to boot it, it still boots fine. I then boot into the VM's
>rescue disk:
>can reproduce it in older versions too).
>
>I've created an OpenBSD installation in Linux through kvm on a 1GB hard
>disk with just a root partition (a), by booting the install56.iso cdrom
>with a command like this:
>
>kvm -smp 1 -m 2048 -boot d -drive \
>file=/dev/images/openbsd-5.6,format=raw,cache=none,if=virtio -cdrom
>/tmp/install56.iso -vnc :0
>
>The system boots fine with a command like this:
>kvm -m 2048 -drive file=/dev/images/openbsd,format=raw,cache=none,if=virtio
>
>If I then copy it into a 100GB volume:
>dd if=/dev/images/openbsd of=/dev/images/tmp1 bs=4M
>
>And try to boot it, it still boots fine. I then boot into the VM's
>rescue disk:
>> boot bsd.rd
>
>and press S to get a shell
>
>I mount the root partition and grab growfs program:
># mount /dev/sd0a /mnt
># cp /mnt/sbin/growfs .
># umount /mnt
>
>
>and press S to get a shell
>
>I mount the root partition and grab growfs program:
># mount /dev/sd0a /mnt
># cp /mnt/sbin/growfs .
># umount /mnt
>
>Fix the MBR to use the entire disk:
># fdisk -i wd0
>
>And change the disklabel:
>
>disklabel -E sd0
>
># fdisk -i wd0
>
>And change the disklabel:
>
>disklabel -E sd0
>
>Change the OpenBSD boundaries to cover the whole disk:
>> b
>Starting sector: [64]
>Size ('*' for entire disk):[] *
>
>and then grow the root partition to make it 100GB log:
>
>> c
>partition to change size: [] a
>
>Then grow the underlying FFS file system:
>
>growfs /dev/sd0a
>
>If I then reboot, the ffs driver crashes with errors like this:
>
>uvm_fault(0xffffffff81dcddc0, 0xc000068, 0, 2) -> e
>kernel: page fault trap, code=0
>Stopped at ffs_vget+0x115: addb %al, 0(%rcx,%rax,1)
>ddb>
>
>Am I missing something or is this a kernel/growfs bug?
Didn't you read the manual page?
>> b
>Starting sector: [64]
>Size ('*' for entire disk):[] *
>
>and then grow the root partition to make it 100GB log:
>
>> c
>partition to change size: [] a
>
>Then grow the underlying FFS file system:
>
>growfs /dev/sd0a
>
>If I then reboot, the ffs driver crashes with errors like this:
>
>uvm_fault(0xffffffff81dcddc0, 0xc000068, 0, 2) -> e
>kernel: page fault trap, code=0
>Stopped at ffs_vget+0x115: addb %al, 0(%rcx,%rax,1)
>ddb>
>
>Am I missing something or is this a kernel/growfs bug?
Currently growfs can only enlarge unmounted file systems. Do not try
enlarging a mounted file system - your system may panic and you will not
be able to use the file system any longer. Most of the newfs(8) options
cannot be changed by growfs. In fact, you can only increase the size of
the file system. Use tunefs(8) for other changes.
Philip Guenther
Nov 12, 2014, 3:17:43 AM11/12/14
to Nikos Skalkotos, OpenBSD misc, synnef...@googlegroups.com
On Tue, Nov 11, 2014 at 5:43 AM, Nikos Skalkotos <skal...@grnet.gr> wrote:
> I have a kernel page fault in OpenBSD 5.6 100% reproducible (I think I
> can reproduce it in older versions too).
>
> I've created an OpenBSD installation in Linux through kvm on a 1GB hard
> disk with just a root partition (a), by booting the install56.iso cdrom
> with a command like this:
>
> kvm -smp 1 -m 2048 -boot d -drive \
> file=/dev/images/openbsd-5.6,format=raw,cache=none,if=virtio -cdrom
> /tmp/install56.iso -vnc :0
>
> The system boots fine with a command like this:
> kvm -m 2048 -drive file=/dev/images/openbsd,format=raw,cache=none,if=virtio
>
> If I then copy it into a 100GB volume:
> dd if=/dev/images/openbsd of=/dev/images/tmp1 bs=4M
>
> And try to boot it, it still boots fine. I then boot into the VM's
> rescue disk:
...
> can reproduce it in older versions too).
>
> I've created an OpenBSD installation in Linux through kvm on a 1GB hard
> disk with just a root partition (a), by booting the install56.iso cdrom
> with a command like this:
>
> kvm -smp 1 -m 2048 -boot d -drive \
> file=/dev/images/openbsd-5.6,format=raw,cache=none,if=virtio -cdrom
> /tmp/install56.iso -vnc :0
>
> The system boots fine with a command like this:
> kvm -m 2048 -drive file=/dev/images/openbsd,format=raw,cache=none,if=virtio
>
> If I then copy it into a 100GB volume:
> dd if=/dev/images/openbsd of=/dev/images/tmp1 bs=4M
>
> And try to boot it, it still boots fine. I then boot into the VM's
> rescue disk:
> Fix the MBR to use the entire disk:
> # fdisk -i wd0
>
> And change the disklabel:
>
> disklabel -E sd0
> # fdisk -i wd0
>
> And change the disklabel:
>
> disklabel -E sd0
Nikos Skalkotos
Nov 12, 2014, 3:17:43 AM11/12/14
to Philip Guenther, Nikos Skalkotos, OpenBSD misc, synnef...@googlegroups.com
Hello,
Is there a way to output the rescue disk console on a serial port? It
will help for the copy-paste because I don't have physical access to
the server I'm running the VM's and I'm using VNC to grab the console.
On 11 November 2014 22:21, Philip Guenther <guen...@gmail.com> wrote:
Is there a way to output the rescue disk console on a serial port? It
will help for the copy-paste because I don't have physical access to
the server I'm running the VM's and I'm using VNC to grab the console.
On 11 November 2014 22:21, Philip Guenther <guen...@gmail.com> wrote:
Nikos Skalkotos
Nov 12, 2014, 3:17:43 AM11/12/14
to Theo de Raadt, mi...@openbsd.org, skal...@grnet.gr, synnef...@googlegroups.com
Hello,
Sorry, what do you mean by mounted file system? The file system was
not mounted when I tried to enlarge it. I booted with bsd.rd, mounted
the file system just to copy the growfs utility, unmounted the
filesystem and then tried to enlarge it.
Nikos
P.S. This post was sent by 2 mail accounts (skal...@grnet.gr and
skal...@gmail.com). For some strange reason the mails from
skal...@grnet.gr did not reach the list for hours and I tried the
other account. Sorry about this.
Sorry, what do you mean by mounted file system? The file system was
not mounted when I tried to enlarge it. I booted with bsd.rd, mounted
the file system just to copy the growfs utility, unmounted the
filesystem and then tried to enlarge it.
Nikos
P.S. This post was sent by 2 mail accounts (skal...@grnet.gr and
skal...@gmail.com). For some strange reason the mails from
skal...@grnet.gr did not reach the list for hours and I tried the
other account. Sorry about this.
Nikos Skalkotos
Nov 12, 2014, 6:15:17 AM11/12/14
to Philip Guenther, Nikos Skalkotos, OpenBSD misc, synnef...@googlegroups.com
Hello, here is the complete output:
# fdisk sd0
Disk: sd0 geometry: 13054/255/63 [209715200 Sectors]
Offset: 0 Signature: 0xAA55
Starting Ending LBA Info:
#: id C H S - C H S [ start: size ]
-------------------------------------------------------------------------------
0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
*3: A6 0 1 2 - 129 254 63 [ 64: 2088386 ] OpenBSD
# disklabel sd0
# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: Block Device
duid: d920b14a5a56ad5f
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 130
total sectors: 209715200
boundstart: 64
boundend: 2088450
drivedata: 0
16 partitions:
# size offset fstype [fsize bsize cpg]
a: 2088384 64 4.2BSD 2048 16384 1
c: 209715200 0 unused
#fdisk -i sd0
Do you wish to write new MBR and partition table? [n] y
Writing MBR at offset 0.
# fdisk sd0
Disk: sd0 geometry: 13054/255/63 [209715200 Sectors]
Offset: 0 Signature: 0xAA55
Starting Ending LBA Info:
#: id C H S - C H S [ start: size ]
-------------------------------------------------------------------------------
0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
*3: A6 0 1 2 - 13053 254 63 [ 64: 209712446 ] OpenBSD
# disklabel -E sd0
Label editor (enter '?' for help at any prompt)
> b
Starting sector: [64]
Size ('*' for entire disk): [2088386] *
size of 209715136 sectors.
size: [2088384] 209715136
> q
Write new label?: [y] y
# disklabel sd0
# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: Block Device
duid: d920b14a5a56ad5f
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 130
total sectors: 209715200
boundstart: 64
boundend: 209715200
drivedata: 0
16 partitions:
# size offset fstype [fsize bsize cpg]
a: 209715136 64 4.2BSD 2048 16384 1
c: 209715200 0 unused
# umount /mnt
# mount
/dev/rd0a on / type ffs (local)
# dumpfs /dev/sd0a | less
^magic 11954 (FFS1) time Wed Nov 12 10:13:55 2014
id [ 545cc5cf 7a01be79 ]
cylgrp dynamic inodes 4.4BSD fslevel 3
ncg 6 ncyl 6 size 522096 blocks 512247
bsize 16384 shift 14 mask 0xffffc000
fsize 2048 shift 11 mask 0xfffff800
frag 8 shift 3 fsbtodb 2
minfree 5% optim time symlinklen 60
maxbpg 4096 maxcontig 1 contigsumsize 0
nbfree 36554 ndir 1011 nifree 141082 nffree 208
cpg 1 bpg 12958 fpg 103664 ipg 25984
nindir 4096 inopb 128 nspf 4 maxfilesize 1126174852055039
sbsize 2048 cgsize 16384 cgoffset 0 cgmask 0xffffffff
csaddr 1648 cssize 2048
rotdelay 0ms rps 60 interleave 1
nsect 414656 npsect 414656 spc 414656
sblkno 8 cblkno 16 iblkno 24 dblkno 1648
cgrotor 0 fmod 0 ronly 0 clean 1
avgfpdir 64 avgfilesize 16384
flags updated
fsmnt /mnt
volname swuid 0
# growfs /dev/sd0a
We strongly recommend you to make a backup before growing the Filesystem
Did you backup your data (Yes/No) ? yes
new filesystem size is: 52428784 frags
Warning: 313856 sector(s) cannot be allocated.
growfs: 102246.7MB (209401280 sectors) block size 16384, fragment size 2048
using 505 cylinder groups of 202.47MB, 12958 blks, 25984 inodes.
super-block backups (for fsck -b #) at:
....
....
# dumpfs /dev/sd0a | less
^magic 11954 (FFS1) time Wed Nov 12 10:19:09 2014
id [ 545cc5cf 7a01be79 ]
cylgrp dynamic inodes 4.4BSD fslevel 3
ncg 505 ncyl 505 size 52350320 blocks 51522108
bsize 16384 shift 14 mask 0xffffc000
fsize 2048 shift 11 mask 0xfffff800
frag 8 shift 3 fsbtodb 2
minfree 5% optim time symlinklen 60
maxbpg 4096 maxcontig 1 contigsumsize 0
nbfree 6412786 ndir 1011 nifree 13107098 nffree 213
cpg 1 bpg 12958 fpg 103664 ipg 25984
nindir 4096 inopb 128 nspf 4 maxfilesize 1126174852055039
sbsize 2048 cgsize 16384 cgoffset 0 cgmask 0xffffffff
csaddr 1648 cssize 8192
rotdelay 0ms rps 60 interleave 1
nsect 414656 npsect 414656 spc 414656
sblkno 8 cblkno 16 iblkno 24 dblkno 1648
cgrotor 0 fmod 0 ronly 0 clean 0
avgfpdir 64 avgfilesize 16384
flags updated
fsmnt /mnt
volname swuid 0
# fsck -f /dev/sd0a
** /dev/rsd0a
** Last Mounted on /mnt
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
14820 files, 219607 used, 51302501 free (213 frags, 6412786 blocks, 0.0% fragmen
tation)
MARK FILE SYSTEM CLEAN? [Fyn?] y
***** FILE SYSTEM WAS MODIFIED *****
# dumpfs /dev/sd0a | less
^magic 11954 (FFS1) time Wed Nov 12 10:19:09 2014
id [ 545cc5cf 7a01be79 ]
cylgrp dynamic inodes 4.4BSD fslevel 3
ncg 505 ncyl 505 size 52350320 blocks 51522108
bsize 16384 shift 14 mask 0xffffc000
fsize 2048 shift 11 mask 0xfffff800
frag 8 shift 3 fsbtodb 2
minfree 5% optim time symlinklen 60
maxbpg 4096 maxcontig 1 contigsumsize 0
nbfree 6412786 ndir 1011 nifree 13107098 nffree 213
cpg 1 bpg 12958 fpg 103664 ipg 25984
nindir 4096 inopb 128 nspf 4 maxfilesize 1126174852055039
sbsize 2048 cgsize 16384 cgoffset 0 cgmask 0xffffffff
csaddr 1648 cssize 8192
rotdelay 0ms rps 60 interleave 1
nsect 414656 npsect 414656 spc 414656
sblkno 8 cblkno 16 iblkno 24 dblkno 1648
cgrotor 0 fmod 0 ronly 0 clean 1
avgfpdir 64 avgfilesize 16384
flags none
fsmnt /mnt
volname swuid 0
When I reboot I get this:
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
fd1 at fdc0 drive 1: density unknown
uvm_fault(0xffffffff81d97be0, 0xffffffff8d2a5811, 0, 2) -> e
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>
Hope it helps,
Nikos
# fdisk sd0
Disk: sd0 geometry: 13054/255/63 [209715200 Sectors]
Offset: 0 Signature: 0xAA55
Starting Ending LBA Info:
#: id C H S - C H S [ start: size ]
-------------------------------------------------------------------------------
0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
*3: A6 0 1 2 - 129 254 63 [ 64: 2088386 ] OpenBSD
# disklabel sd0
# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: Block Device
duid: d920b14a5a56ad5f
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 130
total sectors: 209715200
boundstart: 64
boundend: 2088450
drivedata: 0
16 partitions:
# size offset fstype [fsize bsize cpg]
a: 2088384 64 4.2BSD 2048 16384 1
c: 209715200 0 unused
#fdisk -i sd0
Do you wish to write new MBR and partition table? [n] y
Writing MBR at offset 0.
# fdisk sd0
Disk: sd0 geometry: 13054/255/63 [209715200 Sectors]
Offset: 0 Signature: 0xAA55
Starting Ending LBA Info:
#: id C H S - C H S [ start: size ]
-------------------------------------------------------------------------------
0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
*3: A6 0 1 2 - 13053 254 63 [ 64: 209712446 ] OpenBSD
# disklabel -E sd0
Label editor (enter '?' for help at any prompt)
> b
Starting sector: [64]
Size ('*' for entire disk): [2088386] *
> c
partition to change size: [] a
Partition a is currently 2088384 sectors in size, and can have a maximum
partition to change size: [] a
size of 209715136 sectors.
size: [2088384] 209715136
> q
Write new label?: [y] y
# disklabel sd0
# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: Block Device
duid: d920b14a5a56ad5f
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 130
total sectors: 209715200
boundstart: 64
boundend: 209715200
drivedata: 0
16 partitions:
# size offset fstype [fsize bsize cpg]
a: 209715136 64 4.2BSD 2048 16384 1
c: 209715200 0 unused
# mount /dev/sd0a /mnt
# cp /mnt/sbin/growfs .
# cp /mnt/sbin/dumpfs .
# cp /mnt/sbin/growfs .
# umount /mnt
# mount
/dev/rd0a on / type ffs (local)
# dumpfs /dev/sd0a | less
^magic 11954 (FFS1) time Wed Nov 12 10:13:55 2014
id [ 545cc5cf 7a01be79 ]
cylgrp dynamic inodes 4.4BSD fslevel 3
ncg 6 ncyl 6 size 522096 blocks 512247
bsize 16384 shift 14 mask 0xffffc000
fsize 2048 shift 11 mask 0xfffff800
frag 8 shift 3 fsbtodb 2
minfree 5% optim time symlinklen 60
maxbpg 4096 maxcontig 1 contigsumsize 0
nbfree 36554 ndir 1011 nifree 141082 nffree 208
cpg 1 bpg 12958 fpg 103664 ipg 25984
nindir 4096 inopb 128 nspf 4 maxfilesize 1126174852055039
sbsize 2048 cgsize 16384 cgoffset 0 cgmask 0xffffffff
csaddr 1648 cssize 2048
rotdelay 0ms rps 60 interleave 1
nsect 414656 npsect 414656 spc 414656
sblkno 8 cblkno 16 iblkno 24 dblkno 1648
cgrotor 0 fmod 0 ronly 0 clean 1
avgfpdir 64 avgfilesize 16384
flags updated
fsmnt /mnt
volname swuid 0
# growfs /dev/sd0a
We strongly recommend you to make a backup before growing the Filesystem
Did you backup your data (Yes/No) ? yes
new filesystem size is: 52428784 frags
Warning: 313856 sector(s) cannot be allocated.
growfs: 102246.7MB (209401280 sectors) block size 16384, fragment size 2048
using 505 cylinder groups of 202.47MB, 12958 blks, 25984 inodes.
super-block backups (for fsck -b #) at:
....
....
# dumpfs /dev/sd0a | less
^magic 11954 (FFS1) time Wed Nov 12 10:19:09 2014
id [ 545cc5cf 7a01be79 ]
cylgrp dynamic inodes 4.4BSD fslevel 3
ncg 505 ncyl 505 size 52350320 blocks 51522108
bsize 16384 shift 14 mask 0xffffc000
fsize 2048 shift 11 mask 0xfffff800
frag 8 shift 3 fsbtodb 2
minfree 5% optim time symlinklen 60
maxbpg 4096 maxcontig 1 contigsumsize 0
nbfree 6412786 ndir 1011 nifree 13107098 nffree 213
cpg 1 bpg 12958 fpg 103664 ipg 25984
nindir 4096 inopb 128 nspf 4 maxfilesize 1126174852055039
sbsize 2048 cgsize 16384 cgoffset 0 cgmask 0xffffffff
csaddr 1648 cssize 8192
rotdelay 0ms rps 60 interleave 1
nsect 414656 npsect 414656 spc 414656
sblkno 8 cblkno 16 iblkno 24 dblkno 1648
cgrotor 0 fmod 0 ronly 0 clean 0
avgfpdir 64 avgfilesize 16384
flags updated
fsmnt /mnt
volname swuid 0
# fsck -f /dev/sd0a
** /dev/rsd0a
** Last Mounted on /mnt
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
14820 files, 219607 used, 51302501 free (213 frags, 6412786 blocks, 0.0% fragmen
tation)
MARK FILE SYSTEM CLEAN? [Fyn?] y
***** FILE SYSTEM WAS MODIFIED *****
# dumpfs /dev/sd0a | less
^magic 11954 (FFS1) time Wed Nov 12 10:19:09 2014
id [ 545cc5cf 7a01be79 ]
cylgrp dynamic inodes 4.4BSD fslevel 3
ncg 505 ncyl 505 size 52350320 blocks 51522108
bsize 16384 shift 14 mask 0xffffc000
fsize 2048 shift 11 mask 0xfffff800
frag 8 shift 3 fsbtodb 2
minfree 5% optim time symlinklen 60
maxbpg 4096 maxcontig 1 contigsumsize 0
nbfree 6412786 ndir 1011 nifree 13107098 nffree 213
cpg 1 bpg 12958 fpg 103664 ipg 25984
nindir 4096 inopb 128 nspf 4 maxfilesize 1126174852055039
sbsize 2048 cgsize 16384 cgoffset 0 cgmask 0xffffffff
csaddr 1648 cssize 8192
rotdelay 0ms rps 60 interleave 1
nsect 414656 npsect 414656 spc 414656
sblkno 8 cblkno 16 iblkno 24 dblkno 1648
cgrotor 0 fmod 0 ronly 0 clean 1
avgfpdir 64 avgfilesize 16384
flags none
fsmnt /mnt
volname swuid 0
When I reboot I get this:
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
fd1 at fdc0 drive 1: density unknown
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>
Hope it helps,
Nikos
Philip Guenther
Nov 23, 2014, 3:39:37 PM11/23/14
to Nikos Skalkotos, Nikos Skalkotos, OpenBSD misc, synnef...@googlegroups.com
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.
> Hello, here is the complete output:
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.
> 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>
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 Skalkotos
Nov 24, 2014, 5:57:48 AM11/24/14
to Philip Guenther, OpenBSD misc, synnef...@googlegroups.com
Hello,
On 23/11/14 06:27, Philip Guenther 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.
Nikos
On 23/11/14 06:27, Philip Guenther 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.
>
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.
Nikos
Nikos Skalkotos
Nov 24, 2014, 7:26:51 AM11/24/14
to Philip Guenther, OpenBSD misc, synnef...@googlegroups.com
Hello,
On 23 November 2014 at 06:27, Philip Guenther <guen...@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.
>
P.S. I tried sending the same mail from skal...@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.
On 23 November 2014 at 06:27, Philip Guenther <guen...@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.
>
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
>> 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
P.S. I tried sending the same mail from skal...@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.
Philip Guenther
Nov 24, 2014, 8:22:30 AM11/24/14
to Nikos Skalkotos, OpenBSD misc, synnef...@googlegroups.com
On Monday, November 24, 2014, Nikos Skalkotos <skal...@grnet.gr> wrote:
On 23/11/14 06:27, Philip Guenther wrote:
...
> 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.
...
I tried zeroing the space first, and then copying the openbsd image
into the zeroed space like this:
...
But I get the very same error after resizing. I don't think this is it.
Was that with rerunning installboot after the fsck?
Philip Guenther
Nikos Skalkotos
Nov 24, 2014, 8:58:09 AM11/24/14
to Philip Guenther, OpenBSD misc, synnef...@googlegroups.com
I just tried this too. Same result.
Anyway, it is 100% replicable here. Can anybody else confirm this? I
just did an 1G installation of OpenBSD, then I dd-ed the 1G file
(logical block device) to a 100G one. I did all the steps I mentioned
above in rescue mode and corrupted the file system.
Nikos
Anyway, it is 100% replicable here. Can anybody else confirm this? I
just did an 1G installation of OpenBSD, then I dd-ed the 1G file
(logical block device) to a 100G one. I did all the steps I mentioned
above in rescue mode and corrupted the file system.
Nikos
Reply all
Reply to author
Forward
0 new messages