OpenVZ Forum: Support » checkpointing failed - Ubuntu hardy/xfs unkown inode mode 0

Home » General » Support » checkpointing failed - Ubuntu hardy/xfs unkown inode mode 0

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

checkpointing failed - Ubuntu hardy/xfs unkown inode mode 0 [message #30682]

Tue, 03 June 2008 01:48

davekempe
Messages: 12
Registered: March 2008

Junior Member

Hi,
I am getting this error:
#vzctl chkpnt 115
Setting up checkpoint...
suspend...
dump...
Can not dump VE: Invalid argument
Error: unknown inode mode 0, magic 0x9041934
Checkpointing failed

and in dmesg:
[1644794.657518] CPT ERR: ffff81003c3d5800,115 :unknown inode mode 0, magic 0x9041934

I have 115 on a RAID1 array from iSCSI, with xfs as the filesystem. Everything else works fine (aside from netstat -aun as reported in bugzilla). I would love checkpointing to work as its an important part of my migration plan. And it used to work on 2.6.18 (built that myself)

Kernel version:
2.6.24-17-openvz
vzctl version 3.0.22

#cat /proc/mounts |grep 115
/dev/md115 /var/lib/vz/private/115 xfs rw,relatime,ikeep,noquota 0 0
/var/lib/vz/private/115 /var/lib/vz/root/115 simfs rw,noatime,relatime 0 0
proc /var/lib/vz/root/115/proc proc rw,nosuid,nodev,noexec 0 0
sysfs /var/lib/vz/root/115/sys sysfs rw,nosuid,nodev,noexec 0 0
tmpfs /var/lib/vz/root/115/var/run tmpfs rw,nosuid,nodev,noexec 0 0
tmpfs /var/lib/vz/root/115/var/lock tmpfs rw,nosuid,nodev,noexec 0 0
/var/lib/vz/private/115 /var/lib/vz/root/115/dev/.static/dev simfs rw,noatime,relatime 0 0
udev /var/lib/vz/root/115/dev tmpfs rw,relatime 0 0
tmpfs /var/lib/vz/root/115/dev/shm tmpfs rw,relatime 0 0
devpts /var/lib/vz/root/115/dev/pts devpts rw,relatime 0 0
tmpfs /var/lib/vz/root/115/var/run tmpfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /var/lib/vz/root/115/var/lock tmpfs rw,nosuid,nodev,noexec,relatime 0 0

Any suggestions?

Report message to a moderator

Re: checkpointing failed - Ubuntu hardy/xfs unkown inode mode 0 [message #30683 is a reply to message #30682]

Tue, 03 June 2008 04:23

davekempe
Messages: 12
Registered: March 2008

Junior Member

On another machine also running hardy I get this error when trying to checkpoint:
vzctl chkpnt 102
Setting up checkpoint...
suspend...
dump...
Got signal 9

then this dump appears in the logs.

412147.397898] Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP:
[412147.397954] [<0000000000000000>]
[412147.398058] PGD 75110f067 PUD 6fe869067 PMD 0
[412147.398108] Oops: 0010 [1] SMP
[412147.398152] CPU: 4
[412147.398190] Modules linked in: vzcpt tun crc32c libcrc32c ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi scsi_transport_iscsi simfs vzethdev vznetdev vzmon af_packet ip_tables x_tables vzdquota vzdev ipv6 sr_mod cdrom bridge ext3 jbd mbcache aoe bonding parport_pc lp parport usb_storage iTCO_wdt serio_raw libusual tpm_infineon ata_generic iTCO_vendor_support i5000_edac edac_core tpm psmouse usbhid button shpchp tpm_bios hid evdev pci_hotplug pcspkr xfs ata_piix sg sd_mod ehci_hcd pata_acpi uhci_hcd libata aacraid usbcore e1000 scsi_mod raid10 raid456 async_xor async_memcpy async_tx xor raid1 raid0 multipath linear md_mod dm_mirror dm_snapshot dm_mod thermal processor fan
[412147.398789] Pid: 789, comm: vzctl.real Not tainted 2.6.24-17-openvz #1 ovz004
[412147.398869] RIP: 0010:[<0000000000000000>] [<0000000000000000>]
[412147.398921] RSP: 0018:ffff8106fe009ce0 EFLAGS: 00010296
[412147.398968] RAX: ffff8106fe009fd8 RBX: ffff810000000000 RCX: ffff8106fe009d68
[412147.399048] RDX: 0000000000001000 RSI: ffff8106fe094000 RDI: ffff810773ce2700
[412147.399128] RBP: ffff81077c9cf000 R08: 0000000000000400 R09: 0000000000000000
[412147.399208] R10: 0000000000000000 R11: 0000000000000000 R12: 00000000ffffffea
[412147.399288] R13: ffff810772e66760 R14: ffff810773ce2700 R15: ffff81076a06af00
[412147.399369] FS: 00007f3b65d096e0(0000) GS:ffff81077bb4e380(0000) knlGS:0000000000000000
[412147.399452] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[412147.399504] CR2: 0000000000000000 CR3: 00000006fe812000 CR4: 00000000000006e0
[412147.399587] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[412147.399667] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[412147.399748] Process vzctl.real (pid: 789, veid=0, threadinfo ffff8106fe008000, task ffff81077b5cf1c0)
[412147.399835] Stack: ffffffff884fa5e2 0000000000000c20 ffff8106fe009d60 ffff81077b5cf1c0
[412147.399925] ffff8106fe009d50 ffff81077481c300 0000000000000008 0000000000000000
[412147.400012] ffffffffffffffff ffff8106fe009d88 0000000000000010 0000000000000900
[412147.400071] Call Trace:
[412147.400145] [<ffffffff884fa5e2>] :vzcpt:dump_one_inode+0x2f2/0x10c0
[412147.400204] [<ffffffff884f3b7a>] :vzcpt:file_write+0x5a/0xb0
[412147.400259] [<ffffffff884fba5c>] :vzcpt:cpt_dump_files+0x8c/0x2e0
[412147.400315] [<ffffffff884f1a9d>] :vzcpt:cpt_dump+0x33d/0x5e0
[412147.400370] [<ffffffff884efa55>] :vzcpt:cpt_ioctl+0x5b5/0xd30
[412147.400424] [<ffffffff884ef4a0>] :vzcpt:cpt_ioctl+0x0/0xd30
[412147.400479] [<ffffffff80305759>] proc_reg_unlocked_ioctl+0xd9/0x110
[412147.400533] [<ffffffff802d02bf>] do_ioctl+0x2f/0xa0
[412147.400581] [<ffffffff802d0550>] vfs_ioctl+0x220/0x2c0
[412147.400630] [<ffffffff802c2879>] vfs_write+0x129/0x180
[412147.400679] [<ffffffff802d0639>] sys_ioctl+0x49/0x80
[412147.400730] [<ffffffff8020c45e>] system_call+0x7e/0x83
[412147.400781]
[412147.400815]
[412147.400815] Code: Bad RIP value.
[412147.400891] RIP [<0000000000000000>]
[412147.400937] RSP <ffff8106fe009ce0>
[412147.400978] CR2: 0000000000000000
[412147.401353] ---[ end trace fe3b05e47e004021 ]---

it seems the hardy kernel and checkpoints don't see to like each other.

dave

Report message to a moderator

Re: checkpointing failed - Ubuntu hardy/xfs unkown inode mode 0 [message #30684 is a reply to message #30683]

Tue, 03 June 2008 04:26

davekempe
Messages: 12
Registered: March 2008

Junior Member

btw, I am using vzctl.real because this is a shell wrapper that removes the destroy command and stop and starts various storage options for the VEs. I get the same problem with vzctl.real run directly.
I was snapshotting happily with the same vzctl wrapper before the kernel/hardy upgrade so I don't think thats the problem.

Report message to a moderator