Help please with USB LiveAntix

Forum Forums General Software Help please with USB LiveAntix

This topic contains 10 replies, has 5 voices, and was last updated by geo3geo Jan 25-8:17 am.

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #17196
    Member
    geo3geo
    geo3geo

    Under Win10 I burned the latest Iso to a USB memory using Rufus and I can boot off the USB no problem. This has an Aptio 2008 bios. When I try it on another laptop (the one I want it to run on of course) it freezes with a message
    Could not open “\EFI\BOOT\fallback.efi”
    This second machine has an Aptio 2018 BIOS and is a GeoBook.

    Any pointers?

    • This topic was modified 2 months, 3 weeks ago by geo3geo.
    #17225
    Member
    christophe
    christophe

    I don’t have an EFI computer. That being said, I’m thinking that perhaps your problem springs from using Rufus to make your Live USB. (I assume) Rufus doesn’t create the live USB like antiX’s own Live-USB-maker (probably it’s made in “dd” mode). My (spitballing) advice is this: Use the working live usb (or antix on a CD-R) to boot antiX on the 2008 computer, and then use the Live-USB-creator program to make a new, fully-functional live usb.

    #17233
    Forum Admin
    BitJam
    BitJam

    Under Win10 I burned the latest Iso to a USB memory using Rufus and I can boot off the USB no problem. This has an Aptio 2008 bios. When I try it on another laptop (the one I want it to run on of course) it freezes with a message
    Could not open “\EFI\BOOT\fallback.efi”
    This second machine has an Aptio 2018 BIOS and is a GeoBook.

    Any pointers?

    Do you have a 2nd usb stick you can use? If so, I suggest that you boot the existing usb stick on the computer where it works and then plug in the 2nd stick and run “sudo live-usb-maker”. This will offer to clone your system to the new stick. The new stick might work better on the UEFI computer.

    Too many notes
    I imagine Rufus makes what is called a dd live-usb (or what I would call a dd-live-iso because the stick has the read-only iso filesystem copied to it) and some tricks are played (using hybridiso) to add a fat-32 file system so UEFI can read it and boot from it. But UEFI is generally pretty buggy and does strange things. If it boots Windows then it is assumed to be problem free. The cloned live-usb will be a “real” live-usb with read-write file system which might work better.

    That error message shows up when you boot our dd-live-iso with UEFI. Normally the system will continue to boot and after that message flashes by you will get to the Grub menu. Our “real” live-usb boots slightly differently so maybe the problem that you had with the dd-live-iso will not occur with the real live-usb you cloned.

    If you tell me the iso file you used, I will test here to make sure a dd-live-usb made from it boots via UEFI. Edit: The exact make and model of the computer that is not booting might help us see if other people are reporting similar problems on it.

    The live-usb-maker clone mode is part of our strategy to get people to use live-usbs made with our software. We believe this is the best live-usb you can get. The Most Extensive Live-usb on the Planet! We have no control over other software that makes live-usbs and the whole “hybridiso” plus “dd” thing is a kludge. UEFI is a messy, buggy kludge as well with lots of system specific crazy bugs. If UEFI is not working right, you always want to test it on another, different machine. I’ve got 4 machines here I test on. The most expensive one has the wackiest UEFI bugs.

    I also suggest that when you boot your existing live-usb you select the “checkmd5” option. This will verify that most of the bits written were written correctly. If an error is detected then it is possible there was also an error in the “dd” UEFI bootloader. You can do the same check on the cloned live-usb.

    PS: our live-usb works with secure boot even though our installed systems do not (yet). You could try disabling secure boot anyway and see if that helps.

    PS-2: Ninja’ed by christophe! Sorry christophe, I should have read your post more carefully before chiming in.

    • This reply was modified 2 months, 3 weeks ago by BitJam.
    • This reply was modified 2 months, 3 weeks ago by BitJam.

    Context is worth 80 IQ points -- Alan Kay

    #17240
    Member
    Avatar
    skidoo

    Although the OP may have encountered an edge case, we’ve seen multiple reports of “Rufus successfully created MX18 liveUSB”, right?
    .

    what_do_bootable_usb_makers_like_rufus_actually_do
    a Jan 2019 reply posted reddit by the author of Rufus

    Rufus developer here. Glad you asked, because a lot of people seem to think an utility like Rufus doesn’t do much (“Why use Rufus when you can just use diskpart?”), and fail to realize that there is usually a lot more happening behind the scenes because of all the many quirks that are inherent to what can mostly be described as trying to fit a round peg (an ISO image) into a smaller square hole (a USB drive).

    So, what does Rufus do. Well, that varies a lot depending on the type of source image you have and type of computer you are trying to boot.

    If the source is a DD (pure disk image) or ISOHybrid image (mixed ISO and disk image), then this is the simplest case: Rufus does write it, bit for bit, without any conversion, onto the USB drive… except (quirk #1) it also first needs makes sure that there doesn’t exist another process that is currently trying to access the drive in write mode, since, to reliably write to the drive, you really don’t want to leave the door open for something else to also have kept some write access opened, as there is no telling how they might arbitrarily change the data you just wrote behind your back, and screw up the boot. Also, you may have to work around some Windows own quirks (quirk #2, mostly seen with Windows 10), where Windows will prevent you to write whatever you want unless you first cleared the drive properly (and by properly, Microsoft means using one of the 3 methods that are supposed to clear the partition tables and whatnot, but that are temperamental enough so that only one tends to work as expected). Now, once you managed to clear the drive, write the data, and made sure that nothing should have been able to modify it behind your back, then you “should” be able to rely on the makers of the image to have sorted the USB boot, so your job is done (or at least, if it doesn’t work, it’s not your issue).

    However, not all ISOs are ISOHybrids. Especially the Windows ISOs aren’t, so the method above, which we call “DD Mode”, cannot be applied all the time. Besides, DD writing presents major drawbacks for Windows users in that the image may be written using a file system that Windows does not support, in which case many people are going to be confused as to why they are no longer able to see or access the content of their USB in File Explorer, or, in case the image contains an EFI System Partition, why they suddenly only see a super small FAT32 partition with next to no content, from what used to be a large USB… And even if the image does use a file system / partition mapping (remember, Windows version prior to Win10 1703 could not mount more than one partition from a drive with the “removable” attribute, which most USB Flash Drives will have) that lets users access the data from Windows, by writing in DD Mode, you are only ever going to be able to use your drive up to the maximum size of the original image. In other words, this means that if the people who created a DD/ISOHybrid image used a 4GB image, then, if it gets copied on a 32GB drive, there’s going to be 28GB of data that you can’t use at all, until you repartition and reformat your drive, which of course isn’t ideal… And I’m not even going to comment on how ISOHybrid is a major hack in the first place, by trying to combine two completely different file systems do stuff they were never designed to do, with all the problems that can ensue (which is why it’s very unlikely you’re ever going to see ISOHybrid versions of Windows ISOs. But then again, who knows…). For the record, this is the reason you can’t use Etcher to write a Windows ISO to an USB drive because Etcher can only cope with DD or ISOHybrid images. Despite what many people seem to believe, because it has become the norm to use it on recent popular Linux distros, ISOHybrid is the exception rather than the norm, so if you only support “DD Mode”, you’re going to be stuck at some stage…

    So, what do you do when you don’t have a DD or ISOHybrid image. Well, that is where things start to get a lot more “interesting”.

    A lot of people seem to think that, if that ISO is UEFI compatible, then it’s about as easy as writing a DD image, in that you simply need to copy the content of the ISO onto a FAT32 formatted partition, and you’re good to go… Except you may have a file on that ISO that is larger than 4 GB (For instance ALL of the recent retail versions of the Windows 10 1809 are like that), in which case you can’t use FAT32 (file system design limits the maximum size of a single file to 4GB or less), and you need to apply some workaround to boot from NTFS. So Rufus does detect that and applies the relevant quirk appropriately (quirk #3). Also, and it turns out that some Linux distros, such as Mandriva (which I’m calling out, because I have opened a bug with them on this for more than 6 months now, and despite repeated requests for updates, they have yet to acknowledge it), have drunk a bit too much of the ISOHybrid Kool-aid, and decided to remove the FAT32 file system driver from their custom GRUB bootloader, which of course wrecks havoc for the boot process of unsuspecting users… And that’s not even mentioning some of the Debian derivatives’ ISOHybrids that don’t bother having the UEFI bootloaders present on the ISO file system, so that they will get copied automatically if you duplicate the ISO content, but instead cram them into a virtual efi.img FAT image. So (quirk #4), Rufus must also extract the efi.img content so that, if you use ISO Mode and not DD Mode, the resulting drive should still boot. Oh, and then there’s Windows 7, which is UEFI compatible (at least for the x64 version), but only after you rename/copy the relevant EFI loader in the right place (quirk #5). Still, converting an UEFI bootable ISO to UEFI bootable USB is actually pretty straight forward (provided the people who created the ISO made sure their content could be booted in Hard Disk mode from a FAT32 or NTFS file system)…

    Things however get A LOT more complicated when you need to convert your ISO not for UEFI USB boot, but for BIOS USB boot, because that’s where you get submerged by the quirks. And there are still a lot of BIOS based machines out there. Your first problem being that, when you boot an ISO on a BIOS computer, you will be using a completely different method than when you boot an USB Flash Drive. In the first case, you don’t need to care about bootable attributes, partitions, boot records (such as the Master Boot Record, or “MBR” which you might have heard of) and whatnot. In the second, you very much do. So, when you are converting a BIOS bootable ISO image to a BIOS bootable USB image, there’s A LOT that needs to happen behind the scenes. First of all, because everybody can create their own custom way of booting an ISO from a CD/DVD drive, an application like Rufus must be able to provide the USB/HDD equivalent of whatever binary was used by the ISO. Thankfully, in the case of Linux distros, there only seems to exist 2 types of BIOS bootloaders being used: Syslinux or GRUB. So, what Rufus does is, detect whether the ISO version of GRUB or Syslinux is being used by the image and then write a HDD version of the same bootloader (because, once again, the ISO version of GRUB of Syslinux is absolutely hopeless at booting a USB or HDD, so you can’t even patch the existing binary to do so). So that’s why you may have to download some files from a remote server during the conversion process. And it gets even more “interesting” because (quirk #6) the Syslinux people have somehow managed to make their versions of Syslinux incompatible with one another, especially when it comes to modules (which thankfully, though not always — but this is a quirk that I’m not going to count, you can reuse from ISO to USB/HDD). For instance, you can’t use modules built for Syslinux 5.01 with Syslinux 5.02… or even between some pre-releases of the same version!), so you need to detect and handle that, rather than blindly copy whatever Syslinux binary you may have tried to include in Rufus. Oh, and some distros (Manjaro… why is it always them?) may decide to use custom build options for GRUB so (quirk #7) you need to sort that out as well. Oh and then there’s the whole issue of GRUB or Syslinux config files that may be looking for a media installation partition with a specific label… that can’t be converted to a FAT32 one, because FAT32 volumes are limited to 11 uppercase characters, so (quirk #8) you may want to fix that as well. Should I mention that that last quirk also applies to UEFI? But that’s still just for GRUB or Syslinux and as I said, everybody can write their custom ISO bootloader, for which Rufus will need to provide a USB equivalent, so having a conversion process for GRUB or Syslinux will only get you so far. And that is why we also have bootloaders for ReactOS or KolibriOS. Apart from that, we also had to write out own MBR (quirk #9), to emulate the Windows BIOS ISO bootloader, that asks the user to press for a key, so that the multi-reboot process of Windows installation in BIOS mode could be conducted unattended, as it can be from optical drive.

    [..]

    So, to answer your question, what Rufus is actually doing is a very straightforward bootable ISO → bootable USB conversion… while also trying not to bring too much attention to all the corner cases that need to be accounted for and that require extensive quirks to be applied, in order to make people wonder if there’s really that much happening behind the scenes…

    #17243
    Forum Admin
    dolphin_oracle
    dolphin_oracle

    with rufus you have a variety of settings you can use to produce the stick. It would be helpful to know what settings the OP used.

    For instance, while you can use a ‘dd’ type mode, you don’t have to. and you can also use gpt vs. msdos partition tables. I forget what the defaults are.

    • This reply was modified 2 months, 3 weeks ago by dolphin_oracle.
    #17329
    Member
    geo3geo
    geo3geo

    Having spent a few days on this I now realise that the problem is my new Win10 64bit GeoBook Bios – AMI Aptio 5.12. It does NOT offer legacy support! So the live USB must be produced to be fully UEFI compatible. So I guess that means doing it on my GeoBook.
    I tried RUFUS and it produced a live boot USB that did NOT bring up the “Could not open \EFI\BOOT\fallback.efi” message but it just froze with simply a cursor on the screen.
    Tried Etcher, UnetBootin but back to “Could not open \EFI\BOOT\fallback.efi”

    Any ideas on other ways of producing an EFI usb under Win 10 ?

    • This reply was modified 2 months, 3 weeks ago by geo3geo.
    • This reply was modified 2 months, 3 weeks ago by geo3geo.
    #17367
    Forum Admin
    BitJam
    BitJam

    Our developer fehlix is working on this now in the thread you posted to in the MX forums. He knows a lot more about Grub than I do. As soon as he comes up with a solution we will try to get it to you.

    Booting our live-usb via UEFI seemed very solid for a number of years. It even works with 32-UEFI and secure boot. Over the past few days we’ve gotten a number of complaints. Perhaps it’s just a coincidence. From what I’ve read in that thread, we don’t have a solution yet. It seems the problem is related to grub (or our grub configuration) not working with certain machines/UEFIs. So creating the live-usb in other ways (which was my first guess for a solution) will probably not help.

    The error message you get is not relevant. It’s not really an error, just Grub demanding for more redundant bloat in a system we are trying to keep small. We can get rid of the error message but then you will be stuck at a blank screen. We can get rid of that error message by making a 4th copy of the same file. We will probably do this.

    Context is worth 80 IQ points -- Alan Kay

    #17380
    Forum Admin
    BitJam
    BitJam

    @geo3geo, fehlix thinks he has a solution in the works. Unfortunately, you will need to download a new iso. We could also provide an xdelta3 patch. Xdelta3 does work on Windows.

    What is the name of the iso file you are using? We can try to get that one updated first.

    The problem seems to be that some newer systems refuse to boot with the version of Grub we are using. This might be related to secure boot but turning off secure boot does not fix it.

    Context is worth 80 IQ points -- Alan Kay

    #17384
    Member
    geo3geo
    geo3geo

    @Bitjam – my iso is
    Antix-17.3.1_x64-base.iso

    cheers

    #17441
    Forum Admin
    BitJam
    BitJam

    I’ve applied the fehlix fix to antiX-17.3.1_x64-base.iso and uploaded here: antiX-17.3.1b_x64-base. PLMK if this fixes the problem for you.

    Context is worth 80 IQ points -- Alan Kay

    #17528
    Member
    geo3geo
    geo3geo

    Using Rufus (options GPT, UEFI, DD) on my Sony Vaio Win10 I produced a USB stick that boots fine on my UEFI GeoBox !!!
    It doesn’t pick up the touchpad so I added an external USB mouse and I can now control it.

    Thanks for this
    Geo

    • This reply was modified 2 months, 3 weeks ago by geo3geo.
Viewing 11 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic.