Problem adding hardrive

  • Hello everybody, I m Lost...when you are windowsian :thumbdown: ...it s very difficult... :/
    OMV is install on USB stick,and it s ok .
    My New problem appear when I want to add hardisk...if I plug a SATA hardisk, grub is normally launch ans a screen appear with


    Mdadm:error opening /.dev/me?*
    Gave up waiting for Root file système device
    Common problème:
    -boot args (cat /proc/cmdline)
    -check Root delay=
    -missing modules (cat /proc/modules; ls / dev)
    ALERT! /Dev/sda1 dors not exist .dropping to a shell.


    OMV is install on a stick (sda1) ,I don t understand why ,if hardisk are plugged ,this message appear.
    If I unplug hardisk,the system start.
    If I start the system and I Hotplug SATA hardisk, I can configure all the hardisk but I cannot restart as long as SATA hardisk are plugged ,I must unplug and plug another Time all hardisk.


    For testing ,all my hardisk are hold and contained old version of Windows,so ,before testing with OMV I erase properly all partition ,so I think it s not the problem.


    Thank for help

  • your system expects to boot from /dev/sda1


    when you plug the sata drive in, it is becoming /dev/sda unless you hot plug it.


    can you paste your /etc/fstab file?
    and the result of 'blkid' command?


    your fstab should reference your boot drive using UUID so that things like this don't happen.

  • Hello, thank's for your reply


    In "Initramfs" when I write "blkid" I have :


    /dev/sda: type="isw_raid_member"
    /dev/sdc :type="isw_raid_member"
    /dev/sdb: ptuuid="b831c3f8" pttype="dos"
    /dev/sdd1 : uuid =" number and letter" type "ext 4" partuuid="f690a31-01"
    /dev/sdd5 : uuid =" number and letter" type "swamp" partuuid="f690a31-05"


    But I "initramfs" if I write /etc/fstab I have "permission denied"


    I see with "blkid" that my USB stick wich is normally "Sda1" change "Sdd1"
    For testing, I change "/sda1" by "/sdd1" in grub launcher and the system launch normally.
    I don't understand why, when I plug SATA disk my USB stick which are as "Sda1" change, in this case, in "Sdd1" ???
    How can I fix It ?
    Each time we want to change a hardisk, we have this problem?


    Thanks

  • I had problems adding a HDD as well. Then I formated the HDD on a Desktop-Linux-PC, replaced it into my omc-server, wiped it (Disks / Wipe), created a file system (File Systems / Create), mounted it (File Systems / Mount), now is workes well.
    Peter

    omv 5.2.5-1 + extras
    Mainboard Fujitsu D3417-B
    CPU Xeon E3-1245v5; RAM 32GB
    System SSD M.2 PCIex4 128GB
    2x HDD WD Red 8TB; 1x extern USB HDD Toshiba 16TB (MG08ACA16TE)
    PowerSupply 300W 80+
    USV Schneider APC CS 350
    idle 27W, nominal 35W, max 150W

  • OP, this is the answer you seek. I've yet to see this NOT fix this problem.

  • As memory serves, I think I stole that little process from one of his posts.

    Which in turn was stolen from ....shit, I do not find it....


    Found it: @LegerD
    Unable to boot after installation (Dropping to a shell!)

  • Explain it succinctly... Really, all I can do is speculate because I don't have a PC that has this particular problem - I can't test it. But I believe it's BIOS related and I can describe what "I think" is happening. (Anyone that has tested this, please chime in.)
    ____________________________


    In the initial setup, the boot drive is set by device path. The BIOS of the server, which handles hardware, is a factor in determining which physical devices are offered to the operating system and in what order.


    In Linux, running on amd64 platforms, the first SATA port (port 0) is usually offered to the OS, where the device found is named /dev/sda by Linux. (/dev/sda is both the device name and the path.)


    In some instances, if there's only one drive connected, BIOS will offer the port the drive is connected to (SATA port 2 as an example) as the first port, where it's named /dev/sda by Linux. Then, the user connects a second hard drive for data. This is where the problem comes into it. If the data drive is connected to a lower sata port, the data drive becomes /dev/sda and the original boot drive becomes /dev/sdb (or some other letter in the order).


    As drives are scanned for being bootable, the drive OMV is installed on (now /dev/sdb) begins to boot. Grub, the boot loader, is the first stop. Grub directs to /dev/sda which is now non-bootable (this is the new data drive), the boot stalls, and the initramfs comes up. Why? Grub doesn't know that the drive it's installed on, the boot drive, has a new device name.


    Running
    update-grub


    changes drives from from device name/path to UUID (Universally Unique IDentifier) in Grub's configuration.
    A drive designation will look something like this: UUID=f64641e7-5368-4bf6-ab0a-fda36237962e
    UUID's eliminate changing boot drive device names, so port order connections no longer matter.
    ____________________________


    Since this issue crops up from time to time, I'm guessing a future release of Grub will fix this or the install process will run the grub-update command as a matter of process.

  • That's about as good (and logical) an explanation as I've seen for this issue.


    Thankfully, it's fairly easy to resolve, but it can be alarming to a new user, especially when their installation went w/o issue.

  • Thankfully, it's fairly easy to resolve,

    The scripted build runs update-grub, but that would only apply to i386 builds, or other affected users that install OMV-Extra's before installing a data drive. Now we'll see if Volker will add the command to the install script in amd64 iso's.

  • The scripted build runs grub-update, but that would only apply to i386 builds, or other affected users that install OMV-Extra's before installing a data drive. Now we'll see if Volker will add the command to the install script in amd64 iso's.

    Well, another thing... Installation instructions. I've not read them in a while, but I believe the official installation instructions say to disconnect all hard drives except the OS drive, and the installation media. They should clearly state after installing to boot the machine and install all updates. Then after all your updates are installed, shutdown and connect your storage drives. That would solve this problem since the OMV update will pull a kernel upgrade, it will run update-grub and resolve the issue. The only time this wouldn't fix the problem, is if the update did not pull a kernel update for some reason. However since Volker doesn't usually update the ISO's, this shouldn't be an issue except for when the ISO's are very new.


    To me, it's pretty clear a lot of folks are installing, *MAYBE* logging in to the webUi, then shutting down and connecting their storage drives, then this issue crops up on their first boot.

    Air Conditioners are a lot like PC's... They work great until you open Windows.


    Edited 2 times, last by KM0201 ().

  • Since the OMV update will pull a kernel upgrade, it will run update-grub and resolve the issue. The only time this wouldn't fix the problem, is if the update did not pull a kernel update for some reason.

    ryecoaaron pointed that out, when I mentioned this.
    _____________________________________________________


    (Noting that this issue doesn't apply to SBC's - no BIOS.)
    As part of the scripted installs for i386, users are sent to the net install version of Debian which is fully up to date, and the scripted install runs grub-update as part of the integrated OMV-Extras install.


    It's the amd64 build (the ISO) that is the question.
    The software update process is in the New User Guide and it recommends the installation of OMV-Extras (either would trigger a grub-update), before configuring a data drive. But a lot of users don't use the guide. They go direct to the download page and have at it.


    For those users, today, I put an issue in on Git-hub asking for the addition of grub-update to the ISO install.
    This is also important for users that use a USB thumbdrive as a software source, and install to a 2nd USB thumbdrive as the boot drive. The same thing can happen. If grub-update is part of the ISO install, the problem should be solved.
    (We'll see what happens.)

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!