0

The title pretty much says it all. I have an older machine with OpenSuSE installed (12.x, IIRC) which I want to update. It does not have a UEFI BIOS. I want to create a bootable USB install, but everything I try, from the OpenSuSE imagewriter program to a straight dd copy to the thumb drive, creates an EFI directory with BOOT under it. This doesn't boot - indeed, isn't even recognized - from the target machine.

I'm using the current openSUSE-Leap-15.3-NET-x86_64.iso for the install, and have tried creating the install on a couple of different machines, running 15.0 and 15.2. I installed on both of those machines using essentially the same procedure, with no more than the usual problems.

Also, one of those machines is also non-UEFI, and the created USB stick works just fine with it. Both have BIOS dates from 2007. The only difference is that the one it works with is presumably an IBM BIOS (it's a ThinkPad T60p), the other has an AMI BIOS.

PS: I also set the BIOS to boot only from USB, but that just causes the machine to hang on startup with a message that there's no bootable drive found. The machine also mounts & reads the stick after I boot into the installed Linux, so it's not simply that the USB hardware is broken.

3
  • From my experience, It shouldn't matter where or not there's a UEIF boot directory on the USB install drive. What matters are the BIOS options on the target machine. Did you check the BIOS options on the machine with a the problem? It's possible it's configured not to boot USB drives. Aug 21, 2021 at 19:01
  • @Cinaed Simson: Yes, I did that. In fact, I set the BIOS to boot only from USB, but that just means the machine hangs on startup with a message that there's no bootable drive found. Then there's the puzzle of why the other machine boots from the same USB. The machine also mounts & reads the stick after I boot into the installed Linux, so it's not simply that the USB hardware is broken.
    – jamesqf
    Aug 22, 2021 at 19:40
  • I have a similar problem - I cannot create a bootable non-uefi usb disk. I have one for ubuntu 20.04 that idk how it was created, but it works. Any iso I try to put on a usb (old or new) winds up with a single ISO partition. The disk that works has ISO plus FAT partitions. Less than 2G? idk but have a similar problem.
    – Julian
    Feb 27 at 6:47

1 Answer 1

0

Note that the image, as written to the thumb drive, should show up as two partitions: the first is indeed a FAT32 partition with the EFI directory at the root, but the second partition, although marked with type ID 17 ("Hidden HPFS/NTFS" according to Debian 10's fdisk), actually contains the ISO9660 filesystem that has most of the contents of the ISO. This is a fairly normal structure for a BIOS+UEFI-bootable hybrid boot media.

# sha256sum openSUSE-Leap-15.3-NET-x86_64-Current.iso
54fb3a488e0fececf45cdaeefaccfb64437745

I'll simulate writing it to a USB thumb drive using a loopback device with partition support enabled:

# losetup -fP --show openSUSE-Leap-15.3-NET-x86_64-Current.iso
/dev/loop0

# fdisk -l /dev/loop0
Disk /dev/loop0: 146 MiB, 153092096 bytes, 299008 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x1d9b6617

Device       Boot Start    End Sectors   Size Id Type
/dev/loop0p1        276   7331    7056   3.5M ef EFI (FAT-12/16/32)
/dev/loop0p2 *     7332 299007  291676 142.4M 17 Hidden HPFS/NTFS

# file -s /dev/loop0p2
/dev/loop0p2: ISO 9660 CD-ROM filesystem data 'openSUSE-Leap-15.3-NET-x86_64160' (bootable)

However, if your problem system uses (or is capable of using) partition type ID 0x17 for some internal purpose, e.g. for a "restore to factory defaults" system image, then that might explain why the system rejects a BIOS-style boot from that partition. You might try altering the partition type of the second partition of the installer thumb drive to some other value. Any value other than any of the "extended partition" types should work; I believe RedHat used to use partition type 0x00 for some of their hybridized ISO images.

A hex dump of the contents of the MBR suggests that the ISOLINUX BIOS bootloader has been installed:

# dd if=openSUSE-Leap-15.3-NET-x86_64-Current.iso bs=512 count=1 | xxd -g 1
1+0 records in
1+0 records out
512 bytes copied, 9.4268e-05 s, 5.4 MB/s
00000000: 33 ed 90 90 90 90 90 90 90 90 90 90 90 90 90 90  3...............
00000010: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90  ................
00000020: 33 ed fa 8e d5 bc 00 7c fb fc 66 31 db 66 31 c9  3......|..f1.f1.
00000030: 66 53 66 51 06 57 8e dd 8e c5 52 be 00 7c bf 00  fSfQ.W....R..|..
00000040: 06 b9 00 01 f3 a5 ea 4b 06 00 00 52 b4 41 bb aa  .......K...R.A..
00000050: 55 31 c9 30 f6 f9 cd 13 72 16 81 fb 55 aa 75 10  U1.0....r...U.u.
00000060: 83 e1 01 74 0b 66 c7 06 f1 06 b4 42 eb 15 eb 00  ...t.f.....B....
00000070: 5a 51 b4 08 cd 13 83 e1 3f 5b 51 0f b6 c6 40 50  ZQ......?[Q...@P
00000080: f7 e1 53 52 50 bb 00 7c b9 04 00 66 a1 b0 07 e8  ..SRP..|...f....
00000090: 44 00 0f 82 80 00 66 40 80 c7 02 e2 f2 66 81 3e  D.....f@.....f.>
000000a0: 40 7c fb c0 78 70 75 09 fa bc ec 7b ea 44 7c 00  @|..xpu....{.D|.
000000b0: 00 e8 83 00 69 73 6f 6c 69 6e 75 78 2e 62 69 6e  ....isolinux.bin
000000c0: 20 6d 69 73 73 69 6e 67 20 6f 72 20 63 6f 72 72   missing or corr
000000d0: 75 70 74 2e 0d 0a 66 60 66 31 d2 66 03 06 f8 7b  upt...f`f1.f...{
000000e0: 66 13 16 fc 7b 66 52 66 50 06 53 6a 01 6a 10 89  f...{fRfP.Sj.j..
000000f0: e6 66 f7 36 e8 7b c0 e4 06 88 e1 88 c5 92 f6 36  .f.6.{.........6
00000100: ee 7b 88 c6 08 e1 41 b8 01 02 8a 16 f2 7b cd 13  .{....A......{..
00000110: 8d 64 10 66 61 c3 e8 1e 00 4f 70 65 72 61 74 69  .d.fa....Operati
00000120: 6e 67 20 73 79 73 74 65 6d 20 6c 6f 61 64 20 65  ng system load e
00000130: 72 72 6f 72 2e 0d 0a 5e ac b4 0e 8a 3e 62 04 b3  rror...^....>b..
00000140: 07 cd 10 3c 0a 75 f1 cd 18 f4 eb fd 00 00 00 00  ...<.u..........
00000150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000001a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000001b0: 50 39 00 00 00 00 00 00 17 66 9b 1d 00 00 00 08  P9.......f......
000001c0: 15 00 ef 25 04 03 14 01 00 00 90 1b 00 00 80 25  ...%...........%
000001d0: 05 03 17 3f 20 91 a4 1c 00 00 5c 73 04 00 00 00  ...? .....\s....
000001e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000001f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa  ..............U.

And if we search the second partition (which is correctly marked as BIOS-style bootable), we'll find the isolinux.bin:

# mount -o ro /dev/loop0p2 /mnt
# find /mnt -name isolinux.bin
/mnt/boot/x86_64/loader/isolinux.bin

/boot/x86_64/loader/ is typical SuSE style for a bootloader installation path. So all the essential components for a BIOS-style boot seem to be in place, however your problem system's BIOS seems to be rejecting it for some reason. And as I stated above, I suspect the choice of partition type ID for the ISO9660 partition might be related to your problem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.