Dashboard opens with blank only

[fvdw]

Thank you Jocko for this info I didn't remember that.
About xfs_repair. It is included un the tools of standalone kernel
You could run it without doing actual repairs by using the -n option

Code: Select all

xfs_repair -n /dev/md4

Without the -n option it will try to repair faults if found

[Jocko]

In addition with fvdw's message.

I think xfs_repair may run without issue when you use the option '-n' (just information level) but as soon as you try to repair (so without the option '-n') a fs via fvdw-sl console there is no enough memory and then you have to set a swap memory.

Then :
You need to assemble another raid

Code: Select all

mdadm --assemble /dev/md3 /dev/sd[abcde]5
mkswap /dev/md3
swapon /dev/md3

[fariaslcfs]

The results asked follow:

Code: Select all

root@fvdw-sta-kirkwood:/ # busybox mount -t xfs /dev/md4 /md4
mount: mounting /dev/md4 on /md4 failed: Function not implemented


Code: Select all

root@fvdw-sta-kirkwood:/ # dmesg | tail
[ 1686.108852] NTFS-fs error (device md4): ntfs_fill_super(): Not an NTFS volume.
[ 1686.129282] XFS (md4): device supports 512 byte sectors (not 0)
[75373.223865] md: md4: recovery done.
[75373.453720] RAID conf printout:
[75373.453734]  --- level:5 rd:5 wd:5
[75373.453743]  disk 0, o:1, dev:sda2
[75373.453752]  disk 1, o:1, dev:sdb2
[75373.453760]  disk 2, o:1, dev:sdc2
[75373.453768]  disk 3, o:1, dev:sdd2
[75373.453776]  disk 4, o:1, dev:sde2


Code: Select all

root@fvdw-sta-kirkwood:/ # xfs_repair -n /dev/md4
Phase 1 - find and verify superblock...
bad primary superblock - bad magic number !!!

attempting to find secondary superblock...
........................................................................................................................................


(... and continues ad eternum ...)

Code: Select all

root@fvdw-sta-kirkwood:/ # mdadm --assemble /dev/md3 /dev/sd[abcde]5
mdadm: /dev/md3 has been started with 5 drives.
root@fvdw-sta-kirkwood:/ # mkswap /dev/md3
Setting up swapspace version 1, size = 263057408 bytes
UUID=f4244cf7-56ee-4117-be00-70357a8ea920
root@fvdw-sta-kirkwood:/ # swapon /dev/md3


Code: Select all

root@fvdw-sta-kirkwood:/ # dmesg | tail
[78114.819094] md: md3 stopped.
[78114.914225] md: bind<sde5>
[78114.924494] md: bind<sdd5>
[78114.927788] md: bind<sdc5>
[78114.934463] md: bind<sdb5>
[78114.944465] md: bind<sda5>
[78114.964175] md/raid1:md3: active with 5 out of 5 mirrors
[78114.969629] md3: detected capacity change from 0 to 263061504
[78130.265387]  md3: unknown partition table
[78141.315355] Adding 256892k swap on /dev/md3.  Priority:-1 extents:1 across:256892k


[fariaslcfs]

One interesting thing is that md4 has not a UUID, but md3 does:

Code: Select all

root@fvdw-sta-kirkwood:/ # blkid
/dev/sdd9: UUID="37b5c79e-faf4-5ee9-ab16-76e2e1f564b8"
/dev/sdd8: UUID="c62f8bc8-06d9-66bd-2547-c94e9470d8fd"
/dev/sdd7: UUID="c316df4c-6a93-643b-b0f2-e3fd5956e2d3"
/dev/sdd5: UUID="f8f78aaa-5bca-cab1-3a0f-f28c490e093e"
/dev/sde9: UUID="37b5c79e-faf4-5ee9-ab16-76e2e1f564b8"
/dev/sde8: UUID="c62f8bc8-06d9-66bd-2547-c94e9470d8fd"
/dev/sde7: UUID="c316df4c-6a93-643b-b0f2-e3fd5956e2d3"
/dev/sde5: UUID="f8f78aaa-5bca-cab1-3a0f-f28c490e093e"
/dev/sda9: UUID="37b5c79e-faf4-5ee9-ab16-76e2e1f564b8"
/dev/sda8: UUID="c62f8bc8-06d9-66bd-2547-c94e9470d8fd"
/dev/sda7: UUID="c316df4c-6a93-643b-b0f2-e3fd5956e2d3"
/dev/sda5: UUID="f8f78aaa-5bca-cab1-3a0f-f28c490e093e"
/dev/sda2: UUID="7ff08b14-9061-45b9-9a0b-fd927901ff88"
/dev/sdb9: UUID="37b5c79e-faf4-5ee9-ab16-76e2e1f564b8"
/dev/sdb8: UUID="c62f8bc8-06d9-66bd-2547-c94e9470d8fd"
/dev/sdb7: UUID="c316df4c-6a93-643b-b0f2-e3fd5956e2d3"
/dev/sdb5: UUID="f8f78aaa-5bca-cab1-3a0f-f28c490e093e"
/dev/sdc9: UUID="37b5c79e-faf4-5ee9-ab16-76e2e1f564b8"
/dev/sdc8: UUID="c62f8bc8-06d9-66bd-2547-c94e9470d8fd"
/dev/sdc7: UUID="c316df4c-6a93-643b-b0f2-e3fd5956e2d3"
/dev/sdc5: UUID="f8f78aaa-5bca-cab1-3a0f-f28c490e093e"
/dev/md3: UUID="f4244cf7-56ee-4117-be00-70357a8ea920"
root@fvdw-sta-kirkwood:/ # blkid /dev/md4
root@fvdw-sta-kirkwood:/ # blkid /dev/md3
/dev/md3: UUID="f4244cf7-56ee-4117-be00-70357a8ea920"


[Mijzelf]

Code: Select all

[ 1686.129282] XFS (md4): device supports 512 byte sectors (not 0)

That is an intriguing message. I looked in the source code to see what is means, and found this:

Code: Select all

/*
 * xfs_readsb
 *
 * Does the initial read of the superblock.
 */
int
xfs_readsb(
        struct xfs_mount *mp,
        int             flags)
{
        unsigned int    sector_size;
        struct xfs_buf  *bp;
        struct xfs_sb   *sbp = &mp->m_sb;
        int             error;
        int             loud = !(flags & XFS_MFSI_QUIET);
        const struct xfs_buf_ops *buf_ops;

        ASSERT(mp->m_sb_bp == NULL);
        ASSERT(mp->m_ddev_targp != NULL);

        /*
         * For the initial read, we must guess at the sector
         * size based on the block device.  It's enough to
         * get the sb_sectsize out of the superblock and
         * then reread with the proper length.
         * We don't verify it yet, because it may not be complete.
         */
        sector_size = xfs_getsize_buftarg(mp->m_ddev_targp);
        buf_ops = NULL;

        /*
         * Allocate a (locked) buffer to hold the superblock. This will be kept
         * around at all times to optimize access to the superblock. Therefore,
         * set XBF_NO_IOACCT to make sure it doesn't hold the buftarg count
         * elevated.
         */
reread:
        error = xfs_buf_read_uncached(mp->m_ddev_targp, XFS_SB_DADDR,
                                      BTOBB(sector_size), XBF_NO_IOACCT, &bp,
                                      buf_ops);
        if (error) {
                if (loud)
                        xfs_warn(mp, "SB validate failed with error %d.", error);
                /* bad CRC means corrupted metadata */
                if (error == -EFSBADCRC)
                        error = -EFSCORRUPTED;
                return error;
        }

        /*
         * Initialize the mount structure from the superblock.
         */
        xfs_sb_from_disk(sbp, XFS_BUF_TO_SBP(bp));

        /*
         * If we haven't validated the superblock, do so now before we try
         * to check the sector size and reread the superblock appropriately.
         */
        if (sbp->sb_magicnum != XFS_SB_MAGIC) {
                if (loud)
                        xfs_warn(mp, "Invalid superblock magic number");
                error = -EINVAL;
                goto release_buf;
        }

        /*
         * We must be able to do sector-sized and sector-aligned IO.
         */
        if (sector_size > sbp->sb_sectsize) {
                if (loud)
                        xfs_warn(mp, "device supports %u byte sectors (not %u)",
                                sector_size, sbp->sb_sectsize);
                error = -ENOSYS;
                goto release_buf;
        }


So as far as I can read it: On base of the sectorsize of the block device the superblock is found and read. It has the right CRC and right magic number, and so you can assume it's the right sector(s). Yet somehow it specifies maximum sector size of 0, which is smaller than the actual sector size of the device.

I wonder if this is some xfs change? Google can't tell me. I remember vaguely that there was an issue with mounting of old xfs filesystems on modern kernels. But I can't remember details or solutions.

About blkid, AFAIK it shows the UUID stored in filesystem metadata. But if the filesystem is not recognized, it can't read the UUID.

/Edit: I checked a Lacie kernel for the 2Big2, 2.6.31.14-svn7195, and it contains the same error message:

Code: Select all

~/Lacie/_2big_NAS_2.5.6.3.capsule.extracted/_uImage.extracted$ strings 32A9 | grep "device support"
XFS: device supports only %u byte sectors (not %u)


So it's not something new, but maybe 0 had a wildcard status, or something like that.

[Jocko]

Code: Select all

root@fvdw-sta-kirkwood:/ # xfs_repair -n /dev/md4
Phase 1 - find and verify superblock...
bad primary superblock - bad magic number !!!

attempting to find secondary superblock...
........................................................................................................................................


(... and continues ad eternum ...)

But did you try to run xfs_repair command without the option -n ?

Code: Select all

xfs_repair /dev/md4

with the option '-n' it repairs nothing.

Then after performing xfs_repair (without the option -n), you should try again to mount md4

[fariaslcfs]

Code: Select all

root@fvdw-sta-kirkwood:/ # xfs_repair -n /dev/md4
Phase 1 - find and verify superblock...
bad primary superblock - bad magic number !!!

attempting to find secondary superblock...
........................................................................................................................................


(... and continues ad eternum ...)

But did you try to run xfs_repair command without the option -n ?

Code: Select all

xfs_repair /dev/md4

with the option '-n' it repairs nothing.

Then after performing xfs_repair (without the option -n), you should try again to mount md4

I'll try this command next monday morning (but I'm afraid that already did that before without success).

[fvdw]

Thank you mijzelf, it makes clear something us wrong with the file system

We also see this

root@fvdw-sta-kirkwood:/ # xfs_repair -n /dev/md4
Phase 1 - find and verify superblock...
bad primary superblock - bad magic number !!!

attempting to find secondary superblock.

I suggest you run xfs_repair without the -n option and let it run to try to repair the file system, without a valid superblock it cannot be mounted . It can take a long time to complete looking to size of the array

[fvdw]

Oops Jocko alreadty suggested it

[fariaslcfs]

Hi again,

Last friday the following command was executed:

Code: Select all

 xfs_repair -v /dev/md4

producing the result:

Code: Select all

... Sorry, could not valid secondary superblock
Exiting now.

Today, I've just entered the same command above, but without the -v option.
However, I'm afraid that the result will be same.

Perhaps we should recreate it with a command such as below?

Code: Select all

mdadm --create --chunk=64 --level=5 --raid-devices=5 /dev/md4 /dev/sd[abcde]2