Problem adding hardrive

    • OMV 4.x
    • Resolved
    • 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
    • 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

      The post was edited 1 time, last by Scorp21 ().

    • 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
    • crashtest wrote:

      Scorp21 wrote:

      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.
      Try this:

      - Disconnect the data drive
      - Boot into OMV (no data drives connected)
      - On the command line, type update-grub
      - shut down
      - connect the data drive
      - boot up
      OP, this is the answer you seek. I've yet to see this NOT fix this problem.
      Air Conditioners are a lot like PC's... They work great until you open Windows.

    • crashtest wrote:

      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!)
      Odroid HC2 - armbian - OMV5.x | Asrock Q1900DC-ITX - Intenso SSD 120GB - OMV5.x
      :!: Backup - Solutions to common problems - OMV setup videos - OMV5 Documentation - user guide :!:
    • crashtest wrote:

      Scorp21 wrote:

      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.
      Try this:

      - Disconnect the data drive
      - Boot into OMV (no data drives connected)
      - On the command line, type update-grub
      - shut down
      - connect the data drive
      - boot up
      Great !!!! Problem Solved...
      Can you explain me succintly the origin of my problem and how you're solution have fixed it...I want to understand

      Thank's
    • 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.

      The post was edited 2 times, last by crashtest: edit ().

    • crashtest wrote:

      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
      grub-update

      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.
      Air Conditioners are a lot like PC's... They work great until you open Windows.

    • KM0201 wrote:

      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 post was edited 1 time, last by crashtest: Edits ().

    • crashtest wrote:

      KM0201 wrote:

      Thankfully, it's fairly easy to resolve,
      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.

      The post was edited 2 times, last by KM0201 ().

    • KM0201 wrote:

      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.)
    • Users Online 1

      1 Guest