Unable to create bootable USB for installation of 4.1.3 on LInux

    • OMV 4.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Unable to create bootable USB for installation of 4.1.3 on LInux

      I am not able to create a USB stick that is recognized by the BIOS and bootable. I tried Unetbootin, the terminal command dd and also mkusb. I tried several USB sticks and tested for recognition by the BIOS on a Shuttle Barebone PC and also an ASUS laptop, both with Linux 18.04 on them. Both are not able to recognise the USB as bootable, or if recognised, trying to boot from the USB results in the BIOS startup menu just re-appearing.

      I was successfull creating a bootable USB with clonezilla to check whether my laptop has a problem with recognizing USB sticks in general, which is obviously not the case.

      Creating the clonezilla USB involved special commands for making the USB bootable (here).

      I especially wonder why copying the .iso from here with dd to /dev/sda (without partition number) and /dev/sda1 (e.g. to the first partition) is not working.

      Is there a definite way to create a bootable USB with the .iso for 4.1.3. which is bulletproof?
    • bvrulez wrote:

      Is there a definite way to create a bootable USB with the .iso for 4.1.3. which is bulletproof?
      The same as with every other installation on flash storage:

      1. Always check your flash storage for counterfeit products. It's strongly recommended to always test USB thumb drives and SD cards with either F3 or H2testw first
      2. Only burn with Etcher (Etcher takes care about the most common issues when burning to flash media, especially it implements a verify which is important)
    • bvrulez wrote:

      My Kingston 16 GB and 8 GB USB storage both are "damaged".

      Welcome to reality ;)

      Seriously: A lot of people if not even the majority of flash storage users suffers from exactly this problem. And it's really sad that installation tutorials and advice given in forums never mentions the real problems: that's counterfeit stuff (faked capacity), damaged flash or simply 'burning went wrong' (in an awful lot of cases the media is OK but something goes wrong when writing)

      See these examples: forum.armbian.com/topic/7360-b…findComment&comment=57564

      I don't know why this information is not added to installation tutorials for flash media. It would save users a lot of time.
    • I used a third key yesterday, also Kingston 8GB. It was labeled "the real thing" by F3 and I used Etcher to put the Iso on it. I veryfied the checksum of the downloaded iso as gderf suggested. It is not appearing as boot media in my Asus laptop and in my Shuttle PC.


      EDIT: I just tested a fourth key, also fine according to F3 and successfull flash according to Ether, but also not showing up in both boot menus. Boot from USB works, I tested it with the working key with clonezilla on it.

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

    • I just found another 8GB key with a working GParted on it, meaning I am able to boot to GParted-live with this key on my laptop and my PC. I checked this key with F3probe, which gave "the real thing" and then flashed the OMV413.iso with the correct checksum onto the key using Etcher. Now, the key is not recognized by both computers' BIOS.
    • I've not anything like a PC with BIOS around any more (accessing 'big iron' only virtually and settled to performant ARM servers for small storage projects). But flashing ISOs with Etcher and then booting any of my Macs worked flawlessly all the time.

      I remember that there were some issues with the OMV installer not able to cope with EFI but since you're not talking about EFI but BIOS instead you shouldn't be affected anyway. Most probably I would now try to burn a Debian 9 ISO and if that works follow this tutorial to install OMV on top.
    • By BIOS I mean the UEFI setup menu on boot. I am 37 years old, for me this is still the BIOS. :) But I am not running it in legacy mode, thus it's UEFI.

      To summarize this thread: I have a working USB flash with 8GB that is able to boot GParted live. I used this one to put the OMV4.iso on it using a tool called Tuxboot for Linux.

      This results in the stick showing up in the boot menu but upon chosing it the menu will just re-appear. No booting from the USB. I also tried using the disk utility, Unetbootin and mkusb to create the bootable USB and always the same result.

      Afterwards I put GParted onto this USB again using Tuxboot and now it is booting up again.

      So I suspect that there are differences in the .iso between GParted and OMV4 that make OMV4 non-bootable for me. But since it is obviously only me having this issue I wonder what the problem is. I will try to built a working stick with a Mac next that will boot a Linux system.
    • tkaiser wrote:

      bvrulez wrote:

      I am not running it in legacy mode, thus it's UEFI.
      Unable to install/boot OMV from my new setup
      Thanks for the suggestion. I actually had it running in legacy mode for some years now because I had the original HDD just cloned back then. But I am definitely running in UEFI mode now and the Asus F205 laptop is also running in UEFI mode, or at least there is no option to change it. And even if I had legacy running then booting should be possible because I tested to create bootable storage on both devices and cross and thus it should create a bootable device that would work.
    • bvrulez wrote:

      I also now put GParted live onto one of the broken devices (broken according to F3). It works fine
      F3 as well as H2testw test the whole surface of a flash memory and report this as 'broken' if just a single bit flip occurs (and they're right since a few bit flips are way more evil than a flash medium failing totally. Those bit flips result in unrecognized data corruption immediately or over time and symptoms almost always look like strange software issues. You'll waste huge amounts of time with such broken storage).

      If you burn a small ISO on a flash medium that shows just a single error at 'address 3 GB' then this will work of course. But once you write more to this image later data corruption will occur. Also due to the nature of flash storage there is no direct mapping between logical and physical addresses at all (there's an abstraction layer in between you can't avoid with this type of flash storage -- FTL: flash translation layer). So if you know you have broken flash media it's gambling to re-use it since data corruption can occur at any time.

      Back to your original problem: it seems the first showstopper is OMV ISOs not being UEFI capable.
    • Yes exactly, thank you very much for elaborating! It never crossed my mind that UEFI is not supported. Is this common knowledge? My RAID5 with 9 disks is inside the housing of my original PC tower. That's actually the reason for my PC's HDD beeing in legacy mode, because I just took it out there and put it into my Shuttle Barebone back then. It took me two days now to find the problem. But at least I learned a lot. Thank you very much again! I never tested the USB with the OMV because I wanted to make sure they work before I do.
    • bvrulez wrote:

      It never crossed my mind that UEFI is not supported. Is this common knowledge?
      Don't think so. And I'm still not entirely sure since neither a (missing) readme.txt at download location or the FAQ mentions anything: openmediavault.readthedocs.io/en/latest/faq.html

      (disclaimer: I never used OMV on x86 hardware so really not familiar at all with those platform specific topics)