Rufus Uefi Bootable Usb Windows 10

[Flocka Bilodeau]

Iam installing Leap onto my Dell Laptop on to a separate Hard Drive so that I can use either Windows or Leap without dual booting from one hard drive. I have downloaded and made a bootable USB Drive using Rufus. My issue is that my Dell XPS laptop uses UEFI Bios and does not allow me to select the USB Drive itself. Instead it is asking for a specific file from the USB Stick. Can somebody please let me know which file I need to select to be able to boot and install Leap from? If you need any more infomation or if i am missing something please let me know and I will try to fill in.

Regards

Charles

I have no idea what Rufus does to your USB and you probably should be addressing your question to Rufus community. The standard way to create bootable openSUSE USB is to dd the image onto the full drive (not partition).

Hi there, many thanks for the reply. I will try to expand a bit more. I was hoping that the option to select the USB drive would be there however its not. When i enter Bios to select the bootable media, it asks you add a bootable device. When you go to add a bootable device it brings up the usb drive, but is asking for a specific file within the .opensuse iso file itself. I have tried to select different files with.efi file name but to no success.

I tried creating a virtual machine ti run this from in windows 11, however i need it to connect to be able to plug an ethernet cable in, but it would not regconise it even after creating virtual switches and selecting different options.

You just repeated what you said before. Again - we do not know what Rufus put on this USB so we cannot tell what file to select. The standard bootable image would be \EFI\Boot\bootx64.efi, but if firmware fails to detect USB as bootable, this file is probably missing.

I was trying to create a UEFI-bootable ISO with ImgBurn, but the ISO can not be booted on UEFI based systems. I tried to boot the generated ISO file on a virtual machine (VirtualBox) and two computers (after transferring ISO to USB drive by Rufus). I tried to create an ISO from extracted contents of the Windows 8.1 PE ISO image. Contents of the original image were extracted by automatic mount to a Windows volume. I tried to do the same with other software (mkisofs) and everything worked, so that the original ISO should be OK. I needed to create an ISO as intermediate step in customizing a pre-compiled Win PE ISO image downloaded from this site. I needed to add my own software (IGLib, IGShell and AnnApp based) to the ISO for testing and deployment.

I tried to create an ISO from USB, since this is what I've done when using mkisofs. The USB contents were created by Rufus from the same original ISO image used to generate the other images (Gandalfs_Win8.1U1SE_x64_updateable_final.ISO). I have uploaded the first bytes of generated ISO and the corresponding log file to the Dropbox directory with the above link.

Sorry, I don't know the answer to your question. It would probably depend on what it's meant to be for the file you're pointing it to as the boot image. Normally you'd get the information from a disc that works.

Hi, I've put around first 25 MB of TEST_double_mkisofs_OK.001 to the TEST_double_mkisofs_OK__split subdirectory, split into 19 files of 1.44 MB. I have a slow connection and it willl take some time for all files to be uploaded.

I tried different things and I noticed that the original (Gandalfs_Win8.1U1SE_x64_updateable_final.ISO) is not UEFI bootable on VirtualBox VM, and also if I create new ISO images from the original bymkisofs (same parameters as described) they are only legacy bootable.

As I mentioned, the double bootable ISO image that works was created by mkisofs from the double USB drive that was created from the original ISO image by Rufus, so obviously Rufus added the stuff that makes the USB (and ISO images created from it by mkisofs) UEFI bootable.

OK, that was a missunderstanding. So Gandalfs_Win8.1U1SE_x64_updateable_final.ISO, this was my original and is not UEFI bootable (didn't even check that), and I uploaded only the 1.44 MB part of it if you need to check anything.

To further clarify, the problem is that I can create UEFI bootable ISO from UEFI bootable USB by using mkisofs (creating TEST_double_mkisofs_OK.ISO, which is both legacy and UEFI bootable) but I can not do this by using ImgBurn by suggested settings (the result is TEST_uefi_fromUSB_not_good.ISO, which is not UEFI bootable).

Does it even look like its attempting to load anything from the disc? I don't have anything uefi capable but legacy bios boot sometimes shows error messages when something about the el Torito boot configuration isn't quite right.

I just took an original Windows 8.1 image, mounted it in a virtual drive, pointed build mode at the virtual drive it and configured the 'bootable disc' tab with the UEFI platform, the efisys.bin boot image and set the 'sectors to load' to the value I gave you earlier (2880) and it's booted fine in VMware (set in EFI mode).

I also created a legacy bios bootable version (so just changing the boot image to etfsboot.com, sectors to load to 8 and the platform id to 80x86) and that failed to boot in the EFI enabled VMware. Switch VMware out of EFI mode and the legacy one booted fine.

This is strange because the file is there, and it is precisely the same location and contents as the one contained on the original ISO image and the one contained in the mkisofs - created image that boots without errors on the same configuration (I boot form VirtualBox, have also used my laptob before).

Hmm... This would suggest either that the Windows 8.1 PE disk that I was using is different from the original Windows 8.1 in something that is important for booting, or that VirtualBox' implementation of UEFI is different from VMWare's.

Also, in my previous testing, I could UEFI - boot those DVDs or USBs that I could also boot on VirtualBox on two actual systems (Acer Aspire V3 (quite old) and MS Surface Pro 4), and I couldn't boot those which I couldn't boot on VirtualBox. I haven't yet tried to boot the ISO image created with the latest settings (i.e. 2880 sectors to load) on actual systems (I will not have access for some time).

Is it possible that VMware doesn't have a strict implementation of UEFI standard and is tolerant to some minor error in images created by ImgBurn? It would be nice to verify that on some other systems, but I will not have this possibility for some time.

Based on your last screenshot, I don't believe you issue is related to anything to do with the el Torito / bootable disc stuff at all. After all, it *has* booted, it's just falling over sometime after that.

The strange thing is that when I compare the Gandalfs Win8.1U1SE_x64 updateable final.iso (source image) and TEST_double_mkisofs_OK.ISO (created by mkisofs, bootable in UEFI), practically all files that could be related to booting and to the system, are the same, byte to byte and by paths within ISO. So if the original image really came to the point where Windows are started, how could it fail when the one created by mkisofs does not fail, and all Windows-related files are (in my opinion) exactly the same? As I understand, from the point when Windows begin to load, all data on disk is accessed through the file system paths and not through hardware addresses? This would then mean that if two disks have the same file structure, either Widows should run properly on both or should fail on both?

The USB stick boots perfectly in UEFI mode although it doesn't have boot.catalog. Why is that, is boot.catalog specific to optical drives, or the reason for boot/not boot lies in lower level (not at the file system level)?

On a separate w10 pc, I used Rufus to make a bootable Windows 10_22H2 x64 USB drive in MBR mode. My bios sees the USB, but when I launch into it, I get the error "Load Failure (3) Unsupported". I tried running Rufus in GPT but it crashes when I select "start", so MBR mode is it.

I discovered the USB will not boot if my Boot Options>CSM Support>Change Boot Device Control setting is on UEFI, so I swapped to Legacy, and the USB boots into the Windows installer. But in there, it does not see the m.2 SSD, neither does my bios. Selecting "both uefi/legacy" option for Boot Device Control gives the first issues of no USB.

I imagine there is a setting I messed with when I installed Linux that is bogging me here (Fast Boot and such). I don't have an internet connection on the spare-pc at the moment to use the Windows Media Creation Tool to make the boot USB, Rufus crapped itself when I selected GPT, and trying to make a boot USB in Linux Mint is fruitless so far. I can get my spare pc over to an internet connection if Windows Tools would help.

However, since you mentioned that your system doesn't see the m.2 SSD in UEFI mode, you may try enabling CSM Support and selecting "Both UEFI and Legacy" mode in the Boot Device Control settings. This should allow the system to detect both UEFI and legacy boot options.

If you follow the directions well, and all goes well, you will wind up with a bootable thumbdrive

with fossapup64 9.5 on it that will boot on either a BIOS box or a UEFI box. Once booted, and

before making a savefile, use GPartEd to expand the ext3 partition2 to a more desirable size.

DO NOT MOVE IT or it won't boot any more.

(Edit: In addition to the above warning, don't resize it to the exact end of the flash drive. Leave 10meg or so blank on the end of the drive. Otherwise the resize operation may fail if the end of the drive doesn't happen to fall on a block boundary.)

3a8082e126