• Re: Repairing an XFS partition that uses V1 inodes....

    From Jaimie Vandenbergh@21:1/5 to i.love@spam.com on Wed Jul 19 12:28:20 2023
    XPost: alt.comp.misc, uk.comp.misc

    On 19 Jul 2023 at 11:45:38 BST, "SH" <i.love@spam.com> wrote:

    I have a CCTV recorder with 5 hard discs.

    First thing I'd suggest is find out what version of XFS is running on
    the recorder.

    Then use a VM to install an appropriate version of old (possibly very
    old) linux that can run the same version of XFS.

    Also, now you have a clone of the drive... you could try slapping it
    back into the recorder.

    Cheers - Jaimie
    --
    "If you can't make fun of it, it's probably not worth taking seriously"
    -- http://survivingtheworld.net/Lesson494.html

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From SH@21:1/5 to Jaimie Vandenbergh on Wed Jul 19 19:11:29 2023
    XPost: alt.comp.misc, uk.comp.misc

    On 19/07/2023 13:28, Jaimie Vandenbergh wrote:
    On 19 Jul 2023 at 11:45:38 BST, "SH" <i.love@spam.com> wrote:

    I have a CCTV recorder with 5 hard discs.

    First thing I'd suggest is find out what version of XFS is running on
    the recorder.

    Then use a VM to install an appropriate version of old (possibly very
    old) linux that can run the same version of XFS.

    Also, now you have a clone of the drive... you could try slapping it
    back into the recorder.

    Cheers - Jaimie


    the trouble with the clone of the drive, the new drive was formatted
    using a later version of XFS that no longer supports V1 inodes so I am
    not sure the DVR would support this drive if dropped back in.

    Plus the clone it contains a single test.img file as opposed to loads of
    txt files and avi files.

    I guess I could restore the TEST.IMG using DDrescue to another disc.....?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From SH@21:1/5 to All on Fri Jul 21 08:59:57 2023
    XPost: alt.comp.misc, uk.comp.misc

    On 19/07/2023 19:11, SH wrote:
    On 19/07/2023 13:28, Jaimie Vandenbergh wrote:
    On 19 Jul 2023 at 11:45:38 BST, "SH" <i.love@spam.com> wrote:

    I have a CCTV recorder with 5 hard discs.

    First thing I'd suggest is find out what version of XFS is running on
    the recorder.

    Then use a VM to install an appropriate version of old (possibly very
    old) linux that can run the same version of XFS.

    Also, now you have a clone of the drive... you could try slapping it
    back into the recorder.

         Cheers - Jaimie


    the trouble with the clone of the drive, the new drive was formatted
    using a later version of XFS that no longer supports V1 inodes so I am
    not sure the DVR would support this drive if dropped back in.

    Plus the clone it contains a single test.img file as opposed to loads of
    txt files and avi files.

    I guess I could restore the TEST.IMG using DDrescue to another disc.....?




    UPDATE!

    I discovered that GPartEd is available as a Live CD download and that
    previous versions were still available.

    So I downloaded GPartEd Live v0.23.0-1 which had support for XFS with v1 inodes.

    So I booted up this via Ventoy with the pulled 4 TB disc and another 4
    TB disc (formatted to XFS with inode version > 1.) as this disc had the
    IMG image of the pulled disc via DDrescue.

    GPartEd could see both hard discs.

    There was no yellow exclaimation marks against the pulled disc in
    GPartEd but it was unmountable.

    So I ran xfs_repair sda1 and xfs_repair sdz2.

    Both proceeded well and then I was able to mount both partitions and
    view the files within both partitions in a file explorer.

    GPartEd Live v0.23.0-1 reported it could not recognise the partition on
    the 2nd HDD.

    That is hardly surprising as this version of GPartEd live was compatible
    with v1 inodes, and thie version of GPartED Live v0.23.0-1 predates any
    later versions of XFS supporting inode versions > v1.

    (The 2nd HDD had been formatted to a later version of XFS using inode
    version > 1)

    I then put the pulled disc back into my DVR recorder and lo and behold,
    the 17 days of footga ei snow available!

    Several lessons from this:

    What caused the XFS superblock corruption in the first place? A failing
    PSU or momentary main supply glitch? I shall investigate puttign a UPS
    on it.

    The DVR clearly is unable to do its own hard disc housekeeping with
    xfs_repair or even FSCK and just reports check disc or failed disc.

    The DVR clearly running a version of Linux that predates 2007 (as thats
    when XFS with inode version > 1 came out.

    Theer is currently no means of backup from the DVR to say a Network NAS
    or an eSATA hard disc so that there is footage available should a HDD
    fail again. So I will have to investigate this.

    As it happens the DVR does have some eSATA ports on the back, so with
    the 5 x 4 TB drives within, I'm looking at a 20 TB external eSATA drive
    or working out how to get the DVR to back up over a network to a NAS.
    The video files within are of SSF format, but when backed up to CD/DVD
    or memory stick become AVI or SEC files. SO I'm not sure what it will
    get saved as if backed up to eSATA.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From SH@21:1/5 to All on Fri Jul 21 13:31:30 2023
    XPost: alt.comp.misc, uk.comp.misc

    On 19/07/2023 11:45, SH wrote:
    Right....

    I have a CCTV recorder with 5 hard discs.

    This recorder created 2 XFS partitions on every 1 of the 5 hard discs.

    The CCTV recorder started reporting that one of the hard discs had gone offline.

    I've pulled this disc out and placed another hard disc in its place. So
    the DVR is now back in business.

    Howver, the pulled disc contains 17 days worth of footage from 8 cameras
    that is no longer available to the DVR by virtue of being pulled out.

    The Pulled disc was then connected to a PC ruuning a Live instance of
    Ubuntu. There are two partitions on the pulled disc both XFS, as sdb1
    and sdb2.

    Using GParted to interrogate the SMART data and also used SMARTCTL in
    the terminal box indicates the hard disc has no defects at all.

    I then tried to mount both of the two XFS partitions.

    It reported that neither partition could be mounted as:

    Error mounting filesystem /dev/sdbN cant read superblock on /dev/sdbN

    Where N is 1 or 2.

    So I then tried to use xfs_repair on these two partitions in a terminal window.

    XFS-Repair comes back with V1 indoes unsupported, please try an older XFSprogs.

    I then downloaded Centos 5 Live CD as this has an older version of xfs-progs.  However, this will not laod on any PC as it ends with a
    Kernal panic and hangs with a page of text after the Centos splash screen.

    I then rebooted into ubuntu live with a another spare HDD I also
    happened to have to hand.

    I proceeded to use DDrescue to recover the data from the pulled disc.
    This has now completed with absolutely no errors and I now have a IMG
    file on the 2nd HDD.

    So it appears all my files are intact, its a bad superblock both of teh
    XFS partitions on the pulled hard disc

    So I would like ot be able to do one of two things:

    1. Somehow repair the XFS partition with a program that supports W1
    inodes with a linux distro that will (a) boot without a kernel panic and
    (b) has an old enough xfsprogs

    2. or somehow mount & open the test.img file on the 2nd HDD so I can
    then view the video files within. I tried to do this but it reports an unsupported FS even though both Debian and Ubuntu both support XFS partitions.

    Stephen.





    UPDATE!

    I discovered that GPartEd is available as a Live CD download and that
    previous versions were still available.

    So I downloaded GPartEd Live v0.23.0-1 which had support for XFS with v1 inodes.

    So I booted up this via Ventoy with the pulled 4 TB disc and another 4
    TB disc (formatted to XFS with inode version > 1.) as this disc had the
    IMG image of the pulled disc via DDrescue.

    GPartEd could see both hard discs.

    There was no yellow exclaimation marks against the pulled disc in
    GPartEd but it was unmountable.

    So I ran xfs_repair sda1 and xfs_repair sdz2.

    Both proceeded well and then I was able to mount both partitions and
    view the files within both partitions in a file explorer.

    GPartEd Live v0.23.0-1 reported it could not recognise the partition on
    the 2nd HDD.

    That is hardly surprising as this version of GPartEd live was compatible
    with v1 inodes, and thie version of GPartED Live v0.23.0-1 predates any
    later versions of XFS supporting inode versions > v1.

    (The 2nd HDD had been formatted to a later version of XFS using inode
    version > 1)

    I then put the pulled disc back into my DVR recorder and lo and behold,
    the 17 days of footga ei snow available!

    Several lessons from this:

    What caused the XFS superblock corruption in the first place? A failing
    PSU or momentary main supply glitch? I shall investigate puttign a UPS
    on it.

    The DVR clearly is unable to do its own hard disc housekeeping with
    xfs_repair or even FSCK and just reports check disc or failed disc.

    The DVR clearly running a version of Linux that predates 2007 (as thats
    when XFS with inode version > 1 came out.

    Theer is currently no means of backup from the DVR to say a Network NAS
    or an eSATA hard disc so that there is footage available should a HDD
    fail again. So I will have to investigate this.

    As it happens the DVR does have some eSATA ports on the back, so with
    the 5 x 4 TB drives within, I'm looking at a 20 TB external eSATA drive
    or working out how to get the DVR to back up over a network to a NAS.
    The video files within are of SSF format, but when backed up to CD/DVD
    or memory stick become AVI or SEC files. SO I'm not sure what it will
    get saved as if backed up to eSATA.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)