Posts by datadigger

    If these two disks are a part of the raid don't forget to set them as failed and remove them before you wipe.
    mdadm --manage /dev/md0 --fail /dev/sdi
    mdadm --manage /dev/md0 --remove /dev/sdi
    and so on...otherwise the whole raid can break.


    Afterwards try to re-add them again.

    Hey good news, mdadm seems to have enough informations to start the rebuild. But I see a faulty spare, was there one before?


    I would let it rebuild without further action, then make a backup of all your data and start from scratch with a fresh installation of the whole box. And check all the hardware for other problems, such a thunderstorm can do a lot of not so funny things. That's why I have a UPS for all my boxes.


    Even if the raid is rebuilding you should see your shared folders from a windows box. Do you?

    @Wabun :


    Code
    root@OMV:~# mdadm --manage /dev/md127 --add /dev/sdi
    mdadm: Cannot open /dev/sdi: Device or resource busy
    root@OMV:~# mdadm --manage /dev/md127 --add /dev/sdj
    mdadm: Cannot open /dev/sdj: Device or resource busy
    root@OMV:~#


    sorry - same as before ;-/
    i will reinstall OMV agaian an check if there is any difference ...


    That may lead to the same situation. Now we have to check why these two disks cannot be added to the raid.
    Give the result of blkid. After all these actions to get the raid back they possibly belong to another raid definition (Like disk 8 to md126...). blkid will tell if this is the case.

    Until these two disks are not a part of the raid you can restart the box as long as you want, that won't bring it back.
    These two disks have "lost the race" while the raid was assembled, udev can avoid the completion. I would start over building the raid from scratch.
    At first check if these two disks responds:


    smartctl -a /dev/sdi and smartctl -a /dev/sdj

    to make sure that they are well-connected.

    Then start over:
    mdadm --stop /dev/md127 (This raid definition should now be removed from mdadm.conf)
    udevadm control --stop-exec-queue
    mdadm --assemble /dev/md127 /dev/sd[bcdefghijklm] --verbose --force


    (If these two disks are still missing try to add them manually as stated above.
    mdadm --manage /dev/md127 --add /dev/sdi
    mdadm --manage /dev/md127 --add /dev/sdj)


    If the raid is complete start udev:
    udevadm control --start-exec-queue


    Now check if the raid was build correctly:
    cat /proc/mdstat
    mdadm --detail --scan


    If mdadm starts to rebuild, run initramfs and look for errors. If the raid was named correctly in mdadm.conf then it shouldn't spit out any error.


    Just fought the same battle last weekend when I moved a raid from an old machine to a new installation, udevadm did the trick.

    No need to start initramfs before the raid is complete. When mdadm sees all the disks and the raid is complete, it automatically starts a rebuild. The initramfs command adds it to the boot image.


    @ahab: Stop that raid 126 with mdadm --stop /dev/md126, that kills the raid126 and frees the disk 8. Then add it manually to the raid 127 with mdadm --manage /dev/md127 --add /dev/sdi (Correct /dev/sd<letter> is important!).
    Then do the same with disk No. 7: mdadm --manage /dev/md127 --add /dev/sdj - when I read your posts right this shoud be sdj.
    If mdadm can read the disk correctly and it is ok then mdadm will start rebuilding, have a look at the web-ui.
    Then you can run the initramfs command as wabun suggested. If initramfs finds an error it will tell that.

    I always prefer testing programs made by the manufacturer of the disks at the first line, they are tailored for their products.
    After reading all the postings I believe that only one disk may have problems.


    ./edit: This thread should be moved to the /Storage/Raid subforum.

    A NAS without a NIC is useless, that's right. But I believe the TO has a NAS running on this laptop and due to a defective NIC he is not able to access it anymore. Is that right, littleliner?


    If so, there's not that much you can do. You can't open the web-gui from the NAS itself. You need another network adapter to connect it to your network. At Amazon they offer USB to LAN adaptors but I just don't know if they work with OMV.
    If there's no other way to connect it to a network via an USB or PCMCIA adaptor you can only rip off the disk and copy your data to another installation.

    Yes you can use different brands as long as they have the same size. I wouldn't mix up drives with very different capabilities, i.e. standard SATA drives with 7200rpm and drives with higher (Or lower) speeds.
    In a corporate environment I always use the same brand and type of drives with the same firmware for better performance and stability.

    That's right, but with only two drives your possibilities are very limited. Raid 0 or JBOD and Raid 1 are possible, for Raid 10 you need a minimum of four drives. Raid 10 is something I use in corporate environments for the sake of resilience, but not at home because the useable space is only half of the overall capacity of the drives.
    I would take my hands on another 2 TB drive and build a Raid 5 which is expansible up to the end of your money. If that's not possible then do it like KM suggested but in that case you have to move your data away if Raid comes into game.

    The mentioned ISO is the right one to start with (If your system is x64-capable). The current version is 1.9, that's right - but the developers do not frequently update the basic ISO and you can easily update to the current version via the web-gui clicking on update manager after the system is up and running.

    At the directory /usr/share/openmediavault/mkconf/proftpd
    ....
    Am i doing something wrong ?


    Yes. This path is wrong, you are one step too deep. /usr/share/openmediavault/mkconf is the right path and there you will find the proftpd config file for omv-mkconf proftpd.
    The anonymous block starts at line 169 and according to subzero's suggestion you should change the standard value Denyall at line 181 to AllowAll. After saving the file run omv-mkconf proftpd from the CLI and try again.
    If that doesn't work I can submit a version of how I managed it to allow uploads for anonymous users.

    Raids created by mdadm will be recognized. You should see the raid in the raid management tab in the web-gui and the file system, but no shared folders.
    You have to create them in the web-gui using the same names like they had before, set permissions and link them in the smb/cifs tab. The content should be there like on the former machine. I've done that before several times and it worked every time.

    Na prima. Wenn das mit Kodi und Port 8080 auch funktioniert, dann würde ich einen anderen Port für die Kommunikation auswählen, irgendeinen unbelegten in höheren Bereichen ab 40000. Port 8080 gehört zum Standardrepertoire eines Portscans und ist bereits belegt. Jeder Scan von außen auf diesen Port würde die Kiste aufwecken.
    Falls Du das nicht kennst, hier gibts eine ganz gute Übersicht über die Belegung der TCP Ports:
    http://de.wikipedia.org/wiki/L…er_standardisierten_Ports