Unexpected XFS SB number 0x00000000
Hello!
I'm running a home file server with Debian GNU/Linux 4.0 4.0r1 etch (2.6.18-5-amd64 Kernel) and an Areca ARC-1220 hardware RAID controller. I used to have 4 750GB HDDs connected and set up as RAID 5 array, single volume, single XFS partition (set up during the installation of Debian). No problems so far.
Now I added another 750GB HDD to the array, online capacity/volume expansion by the controller finished just fine.
My plan was to add the extra space to the above mentioned XFS partition. So I unmounted the partition, started cfdisk, removed the partition table and wrote a new one that included the new free space.
After rebooting the partition wasn't mounted, so I couldn't use xfs_growth to expand the filesystem.
xfs_check: unexpected XFS SB magic number 0x00000000
xfs_repair -n:
Phase 1 - find and verify superblock...
bad primary superblock - bad magic number !!!
attempting to find secondary superblock.......[...].............found candidate secondary superblock...unable to verify superblock, continuing..........[...]................
.......Sorry, could not find valid secondary superblock Exciting now.
I realize the magic number 0x00000000 is probably not a good thing and maybe using fdisk to write a new table was not the way to do it?
Any suggestions on restoring the old partition table / magic number or how to proceed? Is there an easy fix or is this a serious problem?
Kind Regards,
Chris
Quoted 27 lines · Chris
Hello!
I'm running a home file server with Debian GNU/Linux 4.0 4.0r1 etch (2.6.18-5-amd64 Kernel) and an Areca ARC-1220 hardware RAID controller. I used to have 4 750GB HDDs connected and set up as RAID 5 array, single volume, single XFS partition (set up during the installation of Debian). No problems so far.
Now I added another 750GB HDD to the array, online capacity/volume expansion by the controller finished just fine.
My plan was to add the extra space to the above mentioned XFS partition. So I unmounted the partition, started cfdisk, removed the partition table and wrote a new one that included the new free space.
After rebooting the partition wasn't mounted, so I couldn't usexfs_growthto expand the filesystem.
xfs_check: unexpected XFS SB magic number0x00000000
xfs_repair-n:
Phase 1 - find and verify superblock...
bad primary superblock - bad magic number !!!
attempting to find secondary superblock.......[...].............found candidate secondary superblock...unable to verify superblock, continuing..........[...]................
.......Sorry, could not find valid secondary superblock Exciting now.
Quoted 9 lines
I realize the magic number
0x00000000is probably not a good thing and maybe using fdisk to write a new table was not the way to do it?
Any suggestions on restoring the old partition table / magic number or how to proceed? Is there an easy fix or is this a serious problem?Kind Regards,
Chris
When I grew mine, I used mdadm/raid5, expanded the array and then you run xfs_growfs on the mounted filesystem and it worked.
Wiping out the partition is not the way to do it.
Justin.
Quoted 16 lines · Chris
Hello!
I'm running a home file server with Debian GNU/Linux 4.0 4.0r1 etch (2.6.18-5-amd64 Kernel) and an Areca ARC-1220 hardware RAID controller. I used to have 4 750GB HDDs connected and set up as RAID 5 array, single volume, single XFS partition (set up during the installation of Debian). No problems so far.
Now I added another 750GB HDD to the array, online capacity/volume expansion by the controller finished just fine.
My plan was to add the extra space to the above mentioned XFS partition. So I unmounted the partition, started cfdisk, removed the partition table and wrote a new one that included the new free space.
After rebooting the partition wasn't mounted, so I couldn't usexfs_growthto expand the filesystem.
Quoted 1 line
xfs_check: unexpected XFS SB magic number0x00000000
Did your new partition table start in exactly the same place?
Can you find the string "XFSB" anywhere near where your old partition started?
-Eric
Quoted 2 lines
Did your new partition table start in exactly the same place?
I assumed it would be in the same place...
I guess there is no way to find out what the old one looked like?
Quoted 3 lines
Can you find the string "XFSB" anywhere near where your old partition started?
I can try to do so...how? :)
When I look into the partition with cfdisk, I can see what cylinders/heads/sectors it uses. But I'm sure there are other tools?
Interestingly, after a reboot cfdisk shows me a 801575.31 MB partition and 2199023.26 MB free space, although I wrote a single partition of 3000598.57 MB into the table before rebooting.
Quoted 10 lines · Chris
Quoted 2 lines
Did your new partition table start in exactly the same place?
I assumed it would be in the same place...
I guess there is no way to find out what the old one looked like?Quoted 3 lines
Can you find the string "XFSB" anywhere near where your old partition started?
Quoted 7 lines
I can try to do so...how? :)
When I look into the partition with cfdisk, I can see what cylinders/heads/sectors it uses. But I'm sure there are other tools?Interestingly, after a reboot cfdisk shows me a 801575.31 MB partition and 2199023.26 MB free space, although I wrote a single partition of 3000598.57 MB into the table before rebooting.
fat partitions can't be > 2T
-Eric
Quoted 6 lines
Quoted 2 lines
Did your new partition table start in exactly the same place?
I assumed it would be in the same place...
I guess there is no way to find out what the old one looked like?
Quoted 6 lines
Quoted 3 lines
Can you find the string "XFSB" anywhere near where your old partition started?
I can try to do so...how? :)
When I look into the partition with cfdisk, I can see what
cylinders/heads/sectors it uses. But I'm > sure there are other tools?
Quoted 2 lines
Interestingly, after a reboot cfdisk shows me a 801575.31 MB partition and
2199023.26 MB free space, > although I wrote a single partition of 3000598.57 MB into the table before rebooting.
I just tested some more and using parted found out the following:
(parted) print
Warning: /dev/sdb contains GPT signatures, indicating that is has a GPT table. However, it does not have a valid fake msdos partition table, as it should. Perhaps it was corrupted -- possibly by a program that doesn't understand GPT partition tables. Or perhaps you deleted the GPT table, and are now using an msdos partition table. Is this a GPT partition table? Yes/No? y
Disk /dev/sdb: 3001GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name
Flags
1 17.4kB 22250GB 22250GB xfs
So it seems that parted can still "see" the old table. But it doesn't have support for resizing xfs partitions...
Quoted 14 lines · Chris
I just tested some more and using parted found out the following:
(parted) print
Warning:/dev/sdbcontains GPT signatures, indicating that is has a GPT table. However, it does not have a valid fake msdos partition table, as it should. Perhaps it was corrupted -- possibly by a program that doesn't understand GPT partition tables. Or perhaps you deleted the GPT table, and are now using an msdos partition table. Is this a GPT partition table? Yes/No? yDisk
/dev/sdb: 3001GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Quoted 7 lines
Number Start End Size File system Name
Flags
1 17.4kB 22250GB 22250GB xfsSo it seems that parted can still "see" the old table. But it doesn't have support for resizing xfs partitions...
So, did you originally have a gpt or an msdos partition table?