Posts by tookys

    If you mean mean this https://pve.proxmox.com/wiki/P…sk_to_Virtual_Machine_(VM), then OMV does not have full control of your disks as access still passes through a "virtualisation layer". Disk SMART data is only available on the PVE host. A glitch on either PVE or in the OMV guest can easily upset a MD RAID array with potential filesystem/data loss. Was this your config when suffered previous RAID failures?


    If your only use of OMV is to create a storage array and share data, there are alternative ways to do this on PVE.

    Yeah, thats what I've been doing, I've been having failures each time i try to expand my raid since i started this method, so that would make since.


    I had opted to use a separate vm to handle the docker setup etc. Looks like the solution would be to pass through the SATA controller itself among other options. So I'll need to do some more digging into this to find a better solution.

    I've tried running the code 3 times now, keeps ending in this error. I guess this means its dead?

    Code
    Relocating group 119230's inode bitmap to 3906473501...
    Relocating group 119230's inode table to 3906473502...
    Resize inode (re)creation failed: Inode checksum does not match inode.Continue? yes
    ext2fs_read_inode: Inode checksum does not match inode while reading inode 7 in recreate inode
    /dev/md0: ***** FILE SYSTEM WAS MODIFIED *****
    Recreate journal? yes
    Creating journal (262144 blocks): Block bitmap checksum does not match bitmap: while trying to create journal
    e2fsck: aborted
    /dev/md0: ***** FILE SYSTEM WAS MODIFIED *****

    root@omv-main:~# fsck /dev/md0

    Should i just spam "yes" through all these questions?

    root@omv-main:~# fsck /dev/md0

    Code
    fsck from util-linux 2.38.1
    e2fsck 1.47.2 (1-Jan-2025)
    ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap
    fsck.ext4: Group descriptors look bad... trying backup blocks...
    Superblock has an invalid journal (inode 8).
    Clear<y>?

    Should I clear ? Or is there something else I should have done?

    So I currently have an issue where after adding a new drive to my raid 6, and expanding. The File system I had on the raid is no longer working in OMV.


    I made a full backup of all the data on the raid on a separate computer before attempting the expansion. (I've had these kinds of issues before) But I would like to avoid the headache and time delays of recovering from backup if possible.



    The raid some reason got confused when adding a drive, it lost contact with an existing drive in the process. and now thinks it has lost 2 drives.


    I have waited 4 days to allow it to finish reshaping to the new drive, and it is currently in the drive recovery phase.


    I plan to let it finish the recovery before starting to try and address the file system issue.


    When looking at the file systems tab in OMV shows that the FS still exists, but is missing its data or isn't found anymore.



    If i try and have it show more details it simply waits a long time and comes up with an error.




    Trying to mount a new drive doesn't give me an option to remount it.






    I'm not sure where to start trying to troubleshoot this.


    The system is on a custom built server, the server runs proxmox, and runs OMV as a virtual machine within the server to act as the raid manager.


    The HDD are passed through directly to the OMV VM. It is a qty of 5, 8tb Seagate Barracuda (Yes not ideal for a NAS/Raid but its where my budget is at)


    root@omv-main:~# root@omv-main:~# cat /proc/mdstat

    Code
    Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
    md0 : active raid6 sdf[6] sdb[0] sde[5] sdc[3] sdd[1]
          23441682432 blocks super 1.2 level 6, 512k chunk, algorithm 2 [5/3] [UU_U_]
          [===>.................]  recovery = 18.1% (1416663108/7813894144) finish=2175.7min speed=49003K/sec
          bitmap: 0/59 pages [0KB], 65536KB chunk
    
    
    
    unused devices: <none>


    root@omv-main:~# blkid

    Code
    /dev/sdf: UUID="46adc905-340c-0d45-14c7-713a61913d82" UUID_SUB="f873a232-74e5-8f73-d27b-742f185b26bb" LABEL="openmediavault:0" TYPE="linux_raid_member"
    /dev/sdd: UUID="46adc905-340c-0d45-14c7-713a61913d82" UUID_SUB="2efbbc23-2b02-34a2-fc6f-759c6bb5d013" LABEL="openmediavault:0" TYPE="linux_raid_member"
    /dev/sdb: UUID="46adc905-340c-0d45-14c7-713a61913d82" UUID_SUB="011ac530-9fbe-8f97-8a40-04dd3a770295" LABEL="openmediavault:0" TYPE="linux_raid_member"
    /dev/sr0: BLOCK_SIZE="2048" UUID="2024-02-17-11-39-02-00" LABEL="openmediavault 20240217-12:39" TYPE="iso9660" PTUUID="35659091" PTTYPE="dos"
    /dev/sde: UUID="46adc905-340c-0d45-14c7-713a61913d82" UUID_SUB="14356ed5-d411-a762-51e2-063f43b5cf8a" LABEL="openmediavault:0" TYPE="linux_raid_member"
    /dev/sdc: UUID="46adc905-340c-0d45-14c7-713a61913d82" UUID_SUB="1ee6b00e-4b3c-7c23-cd98-2d1887634a16" LABEL="openmediavault:0" TYPE="linux_raid_member"
    /dev/sda5: UUID="fee293ad-128d-4a5b-9d70-485cb6d3d5dc" TYPE="swap" PARTUUID="8dc0e770-05"
    /dev/sda1: UUID="718ac16e-c747-4f3f-bf42-8222b8998950" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="8dc0e770-01"
    /dev/md0: UUID="2355b0f0-4f07-4560-936f-b7b0f4e74b6f" BLOCK_SIZE="4096" TYPE="ext4"

    root@omv-main:~# fdisk -l | grep "Disk "

    root@omv-main:~# cat /etc/mdadm/mdadm.conf


    root@omv-main:~# mdadm --detail --scan --verbose

    Code
    ARRAY /dev/md0 level=raid6 num-devices=5 metadata=1.2 spares=2 name=openmediavault:0 UUID=46adc905:340c0d45:14c7713a:61913d82
       devices=/dev/sdb,/dev/sdc,/dev/sdd,/dev/sde,/dev/sdf

    Im not infront of my computer atm so i cant get then for you right this second, i was checking the debugfs right before i left for work this morning, so I shared what I had.


    Yes the raid was originally made in omv 6, and i updated it to 7.


    No i havent enabled email alerts


    What other logs are you needing? I can give you a paste bin from journalctl or dmesg when i get home.


    The whole point of a raid is if 1 disk fails the system should keep running, and a raid6 allows 2 disk failures. So a disk with a warning shouldnt be the end of the world.


    I dont think it has anything to do with the raid, from the beginning the raid itself has said it was fine, the individual disks have said they were fine, omv says the raid is fine, raid forms fine, everything to do with the raid has said its 100% ok.

    .


    Is it best practice no, is it what caused this issue, id have to say no. Has it caused my issues in the past? Again id say no.


    At this point ive accepted ive lost 4 years of work on my server.


    At this point, im going to be starting from scratch and trying to do things better.


    Yes i accept my own poor management has caused me to loose my work, and i have no one to blame but myself.


    I do have some backups but not complete backups sadly.

    Before i was able to use debugfs /dev/md127


    And ls


    I was able to see the internal folder structure of the raid even though it wasnt mounted.


    Apparently the

    rdump /path/to/copy /mounted/path/to/save


    Would have allowed me to syart moving data off the drive.


    Unfourtunately im no longer able to access the drive using debugfs im afraid something has happened and the data is lost now.


    Debugfs isnt able to mount the drive anymore saying the superblock checksum no longer matches. And i havent found a work around.

    cat /proc/mdstat




    The smart status says that all the drives are good, except sdf which is in warning, but its also always said that.



    cat /etc/mdadm/mdadm.conf


    omv-salt deploy run mdadm initramfs


    it still doesn't mount.

    tookys Probably need to wait until current activity on /dev/md127 is complete.


    Not seen that journalctl error before.

    It'll be a little under 24 hours for it to finish running its current check.


    I'll try running the omv-salt deploy run mdadm initramfs once its done doing its check and give an update.

    the journal command is returning different things when i run it


    journalctl -g fsck

    Code
    Failed to iterate through journal: Bad message
    Code
    -- Boot ec983f550bcb4a62b3c4d716008c1fdd --
    -- No entries --



    Going through all the individual drives everything looked fine with mdadm --examine /dev/mdX


    cat /etc/mdadm/mdadm.conf

    cat /proc/mdstat

    Right now it says its doing a check of the raid? should i let it finish before doing anything? could this fix itself?




    @Krisbee Should i try the omv-salt deploy run mdadm initramfs still, would it hurt anything if its not the right scenario?


    the error currently formed whne trying to moutn drive

    Apparenlty this issue is the superblock for the raid is missing.


    Code
    root@openmediavault:~# mdadm --examine /dev/md127
    mdadm: No md superblock detected on /dev/md127.

    I am debating if to grow the raid with an additional drive i have installed would trigger it to reform the superblock. But i don't know enough to just start doing things willy nilly.



    I'm not familiar with what good architecture for a raid setup would be. I would like to change it, but my server is already maxed out and im to scared to be making major changes.




    This post has something similiar, and i think its the right solution, but i'm to nervous to do it without a bit more guidance.

    https://serverfault.com/questi…ount-cant-read-superblock


    I really thought the raid 6 would save me this headache. I plan to make a offsite backup of everything soon as i can get this back up and running.

    dmesg | grep "mount"



    sudo fsck /dev/md127

    I tried running


    mdadm --stop /dev/md127 and rebooted, it still didn't want to mount after the reboote



    I don't see any auto/read-only, so should i just reboot?

    I ran the command, there was no output.

    Code
    root@openmediavault:~# mdadm --readwrite /dev/md127
    root@openmediavault:~#


    I tried to unmount and remount the raid in the gui, but it still has the same error.


    here is the error that happens when i try and tell it to mount again.