Problem adding hardrive

1. offizieller Beitrag

    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

    Proxmox PVE 7.2-11 + OMV 5.6.26-1 + extras
    Mainboard Fujitsu D3417-B; CPU Xeon E3-1245v5; RAM 32GB

    • Offizieller Beitrag
    Zitat von Scorp21

    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

    • Offizieller Beitrag

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

    • Offizieller Beitrag
    Zitat von KM0201

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

    Now that you mention it, and put it that way, maybe this should be added into the build guide/process somewhere. It's a fairly common build problem.

    • Offizieller Beitrag
    Zitat von crashtest

    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!)

    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

    • Offizieller Beitrag

    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.

    • Offizieller Beitrag

    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.

    • Offizieller Beitrag
    Zitat von KM0201

    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.

    • Offizieller Beitrag
    Zitat von crashtest

    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.

    • Offizieller Beitrag
    Zitat von 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.)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden