openSuSE and Mandriva Live ISOs don't boot successfully

[Xtigyro]

The process of creating the usb live flash drive goes just fine. However, after trying to boot the flash drive with one of those distros - the boot process fails even before loading GRUB.

I've tried again (yesterday, with the GNOME 3.16 ISO which is openSuSE Factory-based) - the issue still occurs.
I've tried the tool which the openSuSE Team recommends ("ImageUSB" - http://www.osforensics.com/tools/write-usb-images.html) and then it worked fine. The same tool works fine with Mandriva, too.

Rufus ver. 2.1, Windows 7 64-bit

[pbatard]

What version of OpenSuse (or Mandriva)?
It really helps to have the exact ISO name of the distros, or the URL you downloaded them.

Also, as always, a complete of how you created the ISO in Rufus can prove invaluable, so can you tell me:

• What mode did you use to create the ISO? MBR? GPT?
• Is your computer you are trying to boo UEFI or BIOS?
• Were you using GNOME 32bit or 64 bit?

Also when you say:

the boot process fails even before loading GRUB
Do you mean you get an error, and if so what is it, or a black screen?

Last time I tried OpenSuse (openSUSE-13.1-DVD-x86_64.iso) it seemed to boot just fine and I was able to proceed up to the graphical setup process without issues, both in BIOS and UEFI mode. The only issue I am aware with OpenSuse right now is the one reported in the FAQ here, but that shouldn't impair the boot process. So unless you tell the name of the openSuse ISO you tried, I don't believe that there is much of an issue with full openSuse.

Now, I have just tested GNOME 3.16, and it really looks to me like the GNOME people (or it might be the openSuse guys) have screwed up their boot process... Or at the very least, it doesn't look like they tried to make it generic enough so that it could work with generic ISO → USB tools.
However I can see error messages on screen when that happens. Do you see error messages too?
I should also point out that (when not using DD-Image mode, but more about this later) the default GNOME boot doesn't use GRUB (but instead Syslinux or EFI).

Now, here is what I think is wrong with the GNOME boot process:

1) They have a /syslinux.cfg that contains the line:

ui gfxboot bootlogo isolinux.msg

However, the gfxboot, bootlogo and isolinux.msg reside in /boot/[i386|x86_64]/loader/ which doesn't seem to be a directory that default builds of syslinux will search for. So it looks like the GNOME people built their own version of Syslinux, which makes it a lot more difficult for generic tools such as Rufus to try to be compatible with.
The end result is that, when trying to boot in BIOS mode, you will get the following error message (for the Syslinux bootloader):

Could not find kernel image: gfxboot

If that is the error you have been seeing, it would have been nice to report it...

2) At least on the machine I tested with, if you fill in the full paths on the ui ... line, you get a crash when the UI modules are being loaded, which I don't think has anything to do with Rufus. I tried to use the gfxboot.c32 from Syslinux 4.07, which is the version Rufus uses, as opposed to version 4.04 from GNOME, but still got the same error.

As far as I can see, it looks like GNOME are using a very custom (and old!!) version of Syslinux and Syslinux modules, which is probably the cause of the gfxboot issues. Sure trying to boot Syslinux in full GFX mode is nice, but if the price is reduced compatibility, the GNOME people should either try to stick to text mode selection for Syslinux, which is A LOT more universal, or, bring their Syslinux version up do date, or, at the very least, try to use a generic build of Syslinux. This is also true of the GRUB 2 version they use, which they have customized to use nondefault directories (and which is therefore not seen by Rufus)

3) If you comment out the problematic ui ... line, you get the Linux kernel and initrd loaded, but the boot process fails later on while executing the boot scripts (plenty of looping messages loop for about 60 seconds, then the process gives up with rebootException), most likely because the GNOME process was probably designed to only look for a CD or DVD device and not a FAT filesystem on USB device. There's only so much Rufus can do if an installation/boot process is not generic enough when it comes to USB (there's no magical universal switch I can flip to make it so), and unlike what is the case with the openSuse installer, the GNOME installer doesn't seem to be able to find its way when the USB partition use a FAT filesystem.

4) This being said, Rufus is actually still compatible with GNOME 3.16, because they are using a Hybrid ISO, that is an ISO that can work as both a CD/DVD image and as a disk (DD) image. I guess this may be the reason why they didn't spend too much time making sure that their Syslinux/Grub process in ISO mode was generic enough to also be used from USB.
But you can use the DD-Image mode of Rufus to write it and it should work. To do that, you will first need to disable ISO support by using the Alt-I cheatmode. After I did so I was able to boot GNOME 3.12 without issues.
However, please be mindful that, because it creates partitions using a Linux filesystem, rather than FAT, you will not be able to see the content of the drive from Windows after formatting it (besides the small EFI partition).

All in all, unless you can tell me the ISOs you used for openSuse and Mandriva that were problematic, and provide more details about the errors you saw then, I don't think I want to spend too much time on GNOME support. This GNOME ISO is trying to use way too many boot methods at once (GRUB + Syslinux + Hybrid mode), and, as is usually the case when you're trying to take on too much at once, implements some of them very poorly.

[Xtigyro]

Dear, pbatard,

I've tested it under the latest openSuSE LiveCD (http://download.opensuse.org/distribution/13.2/iso/openSUSE-13.2-KDE-Live-x86_64.iso.torrent) - the same error.
So we're talking about problem No. 1:
"1) They have a /syslinux.cfg that contains the line:

ui gfxboot bootlogo isolinux.msg"

I personally see this error:
"boot:
Could not find kernel image: gfxboot".

And I guess that the ImageUSB app is using the DD mode which can be used through Rufus as well.

Thank you very much for your very detailed explanation!

Miroslav E. Hadzhiev

[pbatard]

OK, I tested this further, and replicated the same issue with openSUSE-13.2-KDE-Live-x86_64.iso.

One thing I found is that if I tell Rufus not to use /syslinux.cfg but instead use the one in /boot/[i386|x86_64]/loader/isolinux.cfg, I can get the graphical Syslinux menu to work and boot the kernel. So I think I will add this fix in the next version of Rufus.

However, this still won't allow openSuse based Live system to boot properly, as, as pointed out above, the latest openSuse live system is NOT designed at all to handle a FAT32 partition that was converted from an ISO. In fact, the openSuse Live system is designed to work with ISOs only, as demonstrated by their initrd's /linuxrc (and /include), which are the scripts excuted at boot.

linuxrc contains the following:

#======================================
# 7) Mount the live image device
#--------------------------------------
if searchImageISODevice;then
    if [ ! -z "$mediacheck" ]; then
        runMediaCheck
    fi
    if [ ! -z "$kiwi_hybrid" ];then
        setupHybridPersistent
    fi
    kiwiMount "$biosBootDevice" "/cdrom" "-o ro" 1>&2
fi

But then searchImageISODevice (from /include) contains this:

#======================================
# searchImageISODevice
#--------------------------------------
function searchImageISODevice {
    # /.../
    # search all devices for the MBR ID stored in the
    # iso header. This function is called to identify the
    # live media and/or install media
    # ----
    local IFS=$IFS_ORIG
    local mbrVID
    local mbrIID
    local count=0
    local isoinfo=/usr/bin/isoinfo
    mkdir -p /cdrom
    if [ ! -e $isoinfo ];then
        isoinfo=/usr/lib/genisoimage/isoinfo
    fi
    if [ ! -e $isoinfo ];then
        systemException \
            "Can't find isoinfo tool in initrd" \
        "reboot"
    fi
    if [ ! -f /boot/mbrid ];then
        systemException \
            "Can't find MBR id file in initrd" \
        "reboot"
    fi
    mbrIID=$(cat /boot/mbrid)
    udevPending
    #======================================
    # Check for ISO file on storage media
    #--------------------------------------
    if [ ! -z "$isofrom_device" ] && [ ! -z "$isofrom_system" ];then
        Echo "Looking up ISO on $isofrom_device..."
        mkdir /isofrom
        if [[ $isofrom_device =~ nfs: ]];then
            setupNetwork
            isofrom_device=$(echo $isofrom_device | cut -c 5-)
            mount -t nfs -o nolock $isofrom_device /isofrom
        else
            waitForStorageDevice $isofrom_device
            mount $isofrom_device /isofrom
        fi
        if [ ! $? = 0 ];then
            systemException \
                "Failed to mount ISO storage device !" \
            "reboot"
        fi
        biosBootDevice=$(losetup -f --show /isofrom/$isofrom_system)
        if [ ! $? = 0 ];then
            systemException \
                "Failed to loop setup ISO system !" \
            "reboot"
        fi
        return 0
    fi
    #======================================
    # Search ISO header in device list
    #--------------------------------------
    Echo -n "Searching for boot device in Application ID..."
    while true;do
        for i in /dev/*;do
            if [ ! -b $i ];then
                continue
            fi
            mbrVID=$(
                $isoinfo -d -i $i 2>/dev/null|grep "Application id:"|cut -f2 -d:
            )
            mbrVID=$(echo $mbrVID)
            if [ "$mbrVID" = "$mbrIID" ];then
                # /.../
                # found ISO header on a device, now check if there is
                # also a partition for this device with the same
                # information and prefer that device if it exists
                # ----
                biosBootDevice=$i
                for n in 1 2;do
                    local pdev=$(ddn $i $n)
                    if [ -e $pdev ];then
                        mbrVID=$(
                            $isoinfo -d -i $pdev 2>/dev/null |\
                            grep "Application id:"|cut -f2 -d:
                        )
                        mbrVID=$(echo $mbrVID)
                        if [ "$mbrVID" = "$mbrIID" ];then
                            biosBootDevice=$pdev
                            echo; return 0
                        fi
                    fi
                done
                echo; return 0
            fi
        done
        if [ $count -eq 30 ];then
            systemException \
                "Failed to find MBR identifier !" \
            "reboot"
        fi
        count=$(($count + 1))
        echo -n .
        sleep 1
    done
}

Unfortunately, the script above requires the system to locate an ISO9660 filesystem, which works if the (Hybrid) ISO is written straight to the USB in DD mode (since the block device will also be seen as ISO), or if you pass the isofrom_device and isofrom_system as kernel parameters to point to an ISO file residing on the boot filesystem (such as NFS), but there are no provisions whatsover in the scripts for the most common USB filesystem out there, which is FAT32.

So, unless the openSuse people modify their script to make it dual ISO + FAT compatible (which the people of Arch Linux, Debian, tails and so on seem to have had no trouble to do), openSuse based live CDs will remain incompatible with Rufus outside of creating the USB in DD-Image mode...

[pbatard]

Note: The latest openSuSE appears to have addressed the issue.

[Xtigyro]

Niiiiiice!

[SuperFluffy]

So is it possible now without additional hassle to create a bootable USB drive with OpenSuse (Tumbleweed) using Rufus on Windows? Or should any additional steps be taken? I found on reddit that there used to be an issue with OpenSuse, requiring dd mode in rufus.

I will have to help somebody create that via phone, so any hints are appreciated. :)

[pbatard]

It should work in ISO mode. But if you're paranoid, you can always tell the guy to use DD mode, as it should be safest (if you don't care that you may no longer be able to access full USB content until you repartition the whole USB). They WILL be prompted to choose the mode by Rufus anyway, so you'll have to tell them what to pick.