How avoid broken installation

  • Hi all,


    I'm very frustrated at the moment. I tried to reinstall OMV, since I can not upgrade from 2.x to 4.x.
    I already had OMV running on a 32 GB Stick for some years (this one).
    I have a second stick from the same manufacturer with 64 GB and a noname 1 GB stick. One of the sticks should be the boot drive for the NAS (as it was before). I tried already every possible combination of sticks to get an clean installation, but I always run into the error which you can see in the screenshot.
    I used the here suggested Etcher and H2testw to verify all involved sticks (All is OK), but I still get the same error.


    Is it possibly something else? Can I fix the installation from that point on? Am I doing something wrong? Should I use a live-stick to flash everything via Linux?


    Thank you very much for your suggestions :-).

    • Offizieller Beitrag

    There's not enough info to be sure of anything - however;


    If you're using one of your USB drives as an installation source and installing to a 2nd USB drive, that's supposed to become your boot drive, try building OMV using a CD as the source.


    (I'll be out of town starting tomorrow. If you need more help - perhaps someone else can chime in.)

  • I installed omv from /dev/sde1 (a 8 gig flash drive) to /dev/sdf1 (a 32 gig flash drive)


    Removing the 8 gig flash drive after install turned the 32 gig flash drive into /dev/sde1


    On reboot grub loaded with no problems, pressed enter to load omv
    Ended up having the /dev/sdf1 does not exist message


    The work around for me was to edit the file /boot/grub/grub.cfg
    changed everything
    sdf1 to sde1
    hd5 to hd4
    ahci5 to ahci4


    The grub.cfg can be edited at startup by pressing the e key on your keyboard when the grub menu appears, edit each line replacing sdf1 to sde1, hd5 to hd4 and ahci5 to ahci4 and press F10 on your keyboard to boot to the changes (keep in mind the changes are not saved)


    If works for you then edit the file /boot/grub/grub.cfg with your favourite text editor

    • Offizieller Beitrag

    Again, installing from a CD (where the device name is /dev/sr0, leaving all /dev/sd? devices available) prevents this problem from happening.


    But, it's good that you found the Grub work around. All is well that ends well.

  • There's not enough info to be sure of anything - however;


    If you're using one of your USB drives as an installation source and installing to a 2nd USB drive, that's supposed to become your boot drive, try building OMV using a CD as the source.


    (I'll be out of town starting tomorrow. If you need more help - perhaps someone else can chime in.)

    I just have a CD-drive in my desktop, not in my NAS, haven't used it for ages and CDs which are a decade old. Seriously I would trust this CD method even less than any USB stick. But I think your hint triggered the right answer so thank you a lot :) !

    This is the solution! Thank you very very much :D:thumbup: .
    But strangely enough it was one up, not down for me, so sdg1 -> sdh1, hd6 -> dh7 and ahci6 -> ahci7.

  • If works for you then edit the file /boot/grub/grub.cfg with your favourite text editor

    What does the first line of text say in the file /boot/grub/grub.cfg ?

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • What does the first line of text say in the file /boot/grub/grub.cfg ?

    "#" so basically nothing :P
    No seriously, "Do not edit" (in the 2nd line), but when the entries are obviously wrong why not help grub a little bit?

  • What happens when your changes there are overwritten, as they will be every time you upgrade kernels?

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • What happens when your changes there are overwritten, as they will be every time you upgrade kernels?

    The only changes I noticed in my grub.cfg after last update was all sde1 entries have been removed (now uses root=UUID=xxx...)
    Not sure if changes occurred because of grub or that I changed SATA operation mode to AHCI in BIOS of this old DQ45CB motherboard

    Einmal editiert, zuletzt von ankle () aus folgendem Grund: big fingers pressed wrong key

  • I just have a CD-drive in my desktop, not in my NAS, haven't used it for ages and CDs which are a decade old. Seriously I would trust this CD method even less than any USB stick. But I think your hint triggered the right answer so thank you a lot :) !

    This is the solution! Thank you very very much :D:thumbup: .But strangely enough it was one up, not down for me, so sdg1 -> sdh1, hd6 -> dh7 and ahci6 -> ahci7.

    You are welcome

    • Offizieller Beitrag

    I just have a CD-drive in my desktop, not in my NAS, haven't used it for ages and CDs which are a decade old. Seriously I would trust this CD method even less than any USB stick.

    Ouch! (Maybe I dated myself.) Perhaps I should have suggested a "DVD"? In any case, you can trust old tech - it's reliable. Something that's been out for awhile tends to have all the bugs worked out. :) Given BIOS device recognition and subsequent device naming, using an optical drive as a source eliminates this particular issue.


    I've always built from optical drives because, after a disk is burnt, it stores well and is not easily corrupted. For PC's (and servers) that don't come with a CD/DVD, I bought a USB optical drive.

Jetzt mitmachen!

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