Unable to boot ISO from USB

Support
1

I just got a new system (Ryzen 7600+B650E motherboard) and tried installing Manjaro-KDE through a USB drive.
If I use the dd method to write the image to the USB, then it does not show up in the boot menu. If I create a FAT32 partition and copy all the files from the ISO image, then it boots through UEFI but grub goes into rescue mode and errors on unrecognized filesystem.
I have tried unetbootin and supergrub but both end up in grub rescue mode with unrecognized filesystem.

My current BIOS settings:

  • UEFI : Enabled
  • Secure Boot: Disabled
  • Fast Boot: Disabled

It appears that the ISO image has a hard dependency on the ISO9660 filesystem, so creating a VFAT partition doesnt help (unrecognized filesystem). And the raw ISO9660 partition is getting ignored by UEFI boot,

I am able to run both ArchLinux and Ubuntu ISOs through unetbootin but would prefer Manjaro if I can get it running.

EDIT: I also tried a recent ISO (manjaro-kde-dev-24.09-development-unstable-240911-linux610.iso) but the problems still persists.

2

Welcome to the Manjaro Community!

My first suggestion is to try with Ventoy.

Just copy the .ISO to the prepared Ventoy USB. You can put as many .ISOs on there as you wish; it will detect them. Also possible to store other data on there.

3 Likes
3

Ventoy and Balenaetcher i have tried personally. Rufus is also recommended from some users.

2 Likes
4

I’ve heard there are issues with more recent versions of Rufus, although it’s what I used to get Linux to boot on a tablet I’d been given.

I don’t see why dd shouldn’t work, though. I’ve used that by default before I heard about Ventoy.

I forgot to mention: did you verify the .ISO?

5

Probably he used wrong dd command. Me for example, i do not know how to do it exactly (without google search). So to spare my poor memory from remembering even more new stuff, i just use ventoy.

1 Like
6

Wow!. Ventoy was a breeze. I feel like an idiot for wasting half a day on this.

Yes I tested checksums, and tried Rufus as well. The dd command I used was

dd bs=4M if=manjaro-kde-24.0.7-240821-linux69.iso of=/dev/sdc status=progress oflag=sync
1 Like
7

I never bothered with the bs= argument in dd; don’t know if this had any effect. I should look into that, but I’m certainly happy that Ventoy is around. It’s proving very useful these days.

1 Like
8

The boot signature was only relevant if it was needed; for example disks with a Master Boot Record; with GPT disks in UEFI systems, it’s a product of a bygone era. Though it’s may still useful for a hybrid boot. :boot:

At least, that’s what my old brain cells are conjuring. The Arch Wiki dd page is a decent reference; most of us always need a reference. :smile_cat:

Plus there’s this one:

10

I always thought it meant block size. Having a look at the Arch Wiki seems to confirm this.

bs= sets the block size. Defaults to 512 bytes, which is the “classic” block size for hard drives since the early 1980s, but is not the most convenient. Use a bigger value, 64K or 128K. Also, please read the note below, because there is more to this than just “block sizes” — it also influences how read errors propagate. See [1] and [2] for details and to figure out the best bs value for your use case.

I have never needed to use it though. :wink:

1 Like
11

Boot sectors (Why I wrote boot signature, I don’t know; it made sense at the time) vary in size, as I found a few times when needing to strip them from various images and disks.

I probably confused myself in the wee hours, when remembering I had to set the block size (bs=) portion of the command I used to successfully save the boot information to file. :facepalm:

1 Like
12

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.