How to make a legacy bios/uefi dual boot usb stick with syslinux

[polikuo]

This tutorial will teach you how to boot tiny core from a usb stick on legacy bios and uefi machines.

Note that It is suggested to use corepure64 as most efi/uefi are 64-bit.

For GRUB2 lovers, see:
http://forum.tinycorelinux.net/index.php/topic,19364.0.html

To create a GPT USB stick, you'll need gdisk.

Code: [Select]

tce-load -wil gdisk
To create a hybrid USB stick, you'll need a EFI System Partition.
The code below format the USB into 3 partitions.
1. M$ data with ntfs (a "share" partition)
2. ESP
3. ext4 TC installation

create partitions with gdisk

Code: [Select]

sudo gdisk /dev/sdb
# main menu
o        # create a new empty GUID partition table (GPT)
n        # add a new partition
# number, size, type = 0700
n        # add a new partition
# number, size, type = ef00
n        # add a new partition
# number, size, type = 8300
# now we'll create a hybrid MBR for legacy BIOS
x        # extra functionality (experts only)
# expert menu
r        # recovery and transformation options
h        # make hybrid MBR
1 2 3    # assign partitions to MBR
# Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N):
n        # we're using syslinux
# follow gdisk instruction to set up MBR hex code and bootable flags
07       # M$
n        # not bootable
EF       # ESP
y        # personally I prefer putting all the files together
83       # Linux filesystem
n        # if you pick the 3rd partition as the bootable partition, use extlinux to install the boot loader
x        # go back to expert menu
# expert menu
a        # set attributes
2        # your legacy bootable partition
2        # boot flag attribute code
w        # write table to disk and exit
formatting

Code: [Select]

tce-load -wil dosfstools
mkfs.vfat /dev/sdb1
mkfs.vfat /dev/sdb2
mkfs.ext4 /dev/sdb3
sudo rebuildfstab
setup syslinux

Code: [Select]

tce-load -wil syslinux mtools glibc_gconv
syslinux -i /dev/sdb2
# Note that extlinux uses path instead of device:
# extlinux -i /mnt/sdXY/path/to/your/boot/directory
mkdir -p /mnt/sdb2/EFI/BOOT
cp /usr/local/share/syslinux/efi*/syslinux.efi /mnt/sdb2/EFI/BOOT/BOOTX64.EFI
# default path for 64-bit syslinux UEFI firmware
# use "BOOTIA32.EFI" for 32-bit UEFI
sudo dd if=/usr/local/share/syslinux/gptmbr.bin of=/dev/sdb bs=440 count=1
cp /usr/local/share/syslinux/efi*/ldlinux.e64 /mnt/sdb2/EFI/BOOT
cp /usr/local/share/syslinux/efi*/libutil.c32 /mnt/sdb2/EFI/BOOT
cp /usr/local/share/syslinux/efi*/libcom32.c32 /mnt/sdb2/EFI/BOOT
cp /usr/local/share/syslinux/efi*/vesamenu.c32 /mnt/sdb2/EFI/BOOT
cp /usr/local/share/syslinux/libutil.c32 /mnt/sdb2
cp /usr/local/share/syslinux/libcom32.c32 /mnt/sdb2
cp /usr/local/share/syslinux/vesamenu.c32 /mnt/sdb2
cp core.gz vmlinuz /mnt/sdb2/
syslinux.cfg example:

UI vesamenu.c32
DEFAULT tc

LABEL tc
MENU LABEL Tiny Core
KERNEL /vmlinuz
INITRD /core.gz
APPEND ...

Place the syslinux.cfg file to /mnt/sdb2 AND /mnt/sdb2/EFI/BOOT

ALL done ! 
Reboot and test.

    [EDIT]: Added missing  cp  comand and changed  sdc  references to  sdb  as requested.  Rich

[hamak]

Have anyone got this to work on a UEFI only system?

[hamak]

NOW this tutorial works PERFECT!!!
For other users that have Acer Aspire ES11 ES1-132, just change these lines and it will work for you too:

mkdir -p /mnt/sdb2/EFI/Linux
cp /usr/local/share/syslinux/efi*/syslinux.efi /mnt/sdb2/EFI/Linux/BOOTX64.EFI
cp /usr/local/share/syslinux/efi*/ldlinux.e64 /mnt/sdb2/EFI/Linux
cp /usr/local/share/syslinux/efi*/libutil.c32 /mnt/sdb2/EFI/Linux
cp /usr/local/share/syslinux/efi*/libcom32.c32 /mnt/sdb2/EFI/Linux
cp /usr/local/share/syslinux/efi*/vesamenu.c32 /mnt/sdb2/EFI/Linux

[coreplayer2]

hamak,

So, this path "/EFI/Linux/BOOTX64.EFI" is unique to your notebook?

I thought you said earlier that "/EFI/BOOT/BOOTX64.EFI" worked too?

[Rich]

Hi coreplayer2

hamak,

So, this path "/EFI/Linux/BOOTX64.EFI" is unique to your notebook? ...

It seems his Acer laptop has a list of  "acceptable"  paths hardcoded into it it:
http://forum.tinycorelinux.net/index.php/topic,22410.msg140356.html#msg140356

I thought you said earlier that "/EFI/BOOT/BOOTX64.EFI" worked too?

That worked on a different machine he tried it on:
http://forum.tinycorelinux.net/index.php/topic,22410.msg140424.html#msg140424

[coreplayer2]

It seems his Acer laptop has a list of  "acceptable"  paths hardcoded into it it:
http://forum.tinycorelinux.net/index.php/topic,22410.msg140356.html#msg140356

Hello Rich
This is what's troubling me..  In the OP's questions it's never very clear if the list within this notebook's firmware contains both the Standard
"/EFI/BOOT/BOOTX64.EFI", and manufacturer specific
"/EFI/Linux/BOOTX64.EFI"
pathways?

[Rich]

Hi coreplayer2
The notebook did not contain  /EFI/BOOT/  which was why I suggested he try polikuos tutorial using  /EFI/Linux/  instead.

[coreplayer2]

Hi coreplayer2
The notebook did not contain  /EFI/BOOT/  which was why I suggested he try polikuo's tutorial using  /EFI/Linux/  instead.

Ok but I believe that this troubleshooting step occurred earlier and was not confirmed to have fixed the problem.    It was my understanding that this was the cause;
http://forum.tinycorelinux.net/index.php/topic,22410.msg140439.html#msg140439

After this fix was performed the OP reinstalled to /EFI/Linux/ which worked.   Yet it's not clear that /EFI/BOOT/ wouldn't have worked after the fix was applied.

Only reason I'm curious, is because I have a hard time believing a manufacturer would not include the default UEFI path in it's firmware. 

 

[Rich]

Hi coreplayer2

Hi coreplayer2
The notebook did not contain  /EFI/BOOT/  which was why I suggested he try polikuo's tutorial using  /EFI/Linux/  instead.

Ok but I believe that this troubleshooting step occurred earlier and was not confirmed to have fixed the problem. ...

It eventually got him to a grub prompt after some additional prompting by polikuo and yourself.

It was my understanding that this was the cause;
http://forum.tinycorelinux.net/index.php/topic,22410.msg140439.html#msg140439

That fixed a syslinux problem.

Only reason I'm curious, is because I have a hard time believing a manufacturer would not include the default UEFI path in it's firmware.

I think you're not giving manufacturers enough credit for thinking they know what you need better than you do. Someone
decided paths for Windows, several Linux flavors, and a generic Linux entry were all that was needed.

[coreplayer2]

Hi coreplayer2

Only reason I'm curious, is because I have a hard time believing a manufacturer would not include the default UEFI path in it's firmware.

I think you're not giving manufacturers enough credit for thinking they know what you need better than you do. Someone
decided paths for Windows, several Linux flavors, and a generic Linux entry were all that was needed.

Hello Rich,   Yes that's right,  It extremely frustrating when they know better what we want than we do..       It's for this reason I waste time with constant reboot cycles attempting to select my desired OS boot loader and that's ASUS whose engineers I have a lot of respect.   Yet they forgot to include the only boot option that's important, to me; Load the EFI bootloader menu switchable to default, instead the time limited special key usage.
In this case it appears that ACER neglected to conform with the UEFI spec's. to include the default path for removable drives and generic fallback path ( EFI/BOOT/bootx64.efi ).   Maybe they thought it was enough to support Windows and Ubuntu?  maybe this was neglect, or maybe they thought it was a security risk allowing someone to boot their hardware without knowing the super secret path and handshake... 


I quote from https://www.rodsbooks.com/efi-bootloaders/principles.html  which is easier reading than the UEFI specifications

One other boot loader directory requires mention: EFI/BOOT. This directory holds a boot loader file, bootx64.efi, which serves as the fallback boot loader if none is specified in the firmware's flash storage. The filename varies depending on the architecture—the filename is bootia32.efi on IA-32 (x86) computers and bootaa64.efi on ARM64 computers. The vast majority of EFI-based x86-64 computers use 64-bit EFIs and therefore use a bootx64.efi default boot loader file
...
The fallback boot loader mentioned earlier (EFI/BOOT/bootx64.efi, or variants of that, depending on the architecture) is something of a special case. This filename was originally intended for use only on removable media, so that they could be booted to install an OS. (If not for that fixed filename, a factory-fresh computer wouldn't be able to boot anything!) This filename was quickly adopted as a fallback filename for hard disk installations, as well. This way, if a duplicate of the normal boot loader is installed to the fallback filename, the computer will remain bootable if the NVRAM-based boot manager list is damaged.

ref: http://www.uefi.org/specifications v2.7 (Errata A)
/EFI/BOOT/bootx64.efi is listed as the only path for multiple architectures on removable devices In the latest UEFI spec's chapter "13.3.1.3 Directory Structure"

For removable media devices there must be only one UEFI-compliant system partition, and that partition must contain an UEFI-defined directory in the root directory. The directory will be named EFI. All OS loaders and applications will be stored in a subdirectory below EFI called BOOT. There must only be one executable EFI image for each supported processor architecture in the BOOT directory.

/EFI/Linux/  is not listed as an approved none conflicting path

Just saying,..

[gwalther]

I am going to try and create a dual boot USB stick following your instructions.  What size do you recommend making the three partions, especially partition one and two?

[coreplayer2]

Hello 

My whole point about dual EFI/MBR boot loaders is their performance hit is considerable.  So, unless the dual boot is really necessary to boot some old device i'd go all out with EFI install ONLY!   The performance boost with GPT/EFI in my test environment is substantial. 

[PDP-8]

I'll second what coreplayer2 says - UEFI only (no csm) is a vast speedup.

BUT, the catch is that on another UEFI-only machine I have (Intel Computesticks and now my 2 year old Acer Aspire 1 netbook/laptop chromebook wannabe) may be playing with the UEFI specs as seen above.  I haven't figured out where that one is going wrong.

I haven't tested as thoroughly with the Acer like Hamak and others have, but in the interest of time I can bring TC up immediately on both of these, with the YUMI-UEFI burner and it's bootloader.

Kind of a bummer - by the time many might figure out that their own machine is not following specs, they may just lose interest in getting TC running.  Or resort to using a "fat" bootloader (well compared to TC's one) to get the job done.

I mean figuring out all this bootloading quirks to get TC running might be fun, but for me, that fun has waned - hency my reliance on 3rd party bootloaders now.  Maybe I'm just in a bad mood, but I wouldn't mind a plump TC bootloader.

[polikuo]

I am going to try and create a dual boot USB stick following your instructions.  What size do you recommend making the three partions, especially partition one and two?

Hi, sorry for the late reply. 

It depends on your habits.
FYI, in my case above, I used an old 8G pendrive.
The sizes are roughly 4G, 512M, 3.5G in order.
4G for file sharing, FAT32.
512M for bootloader, FAT32 EFI.
3.5G for TC stuffs, ext4.

Note that, the first M$ partition is totally optional. 
It's for file sharing between the operating systems.

Since M$ only accept one partition for an USB flash drive,
 you can't access files in other partitions.
The M$ policy usually assign a letter to the first partition on the USB.
Thus, the first partition exist.

If you don't need to share files between the systems,
 then you could omit the first partition and merge partition 1 and 2.

About the file sharing, here's a brief example.
Say, I'm learning C language.
I'm currently working with it under linux system.
In order to test it out on M$ system,
 I can just put it in the first partition of the USB,
 and reboot my PC.
When the system comes up,
 I can load and edit the file normally.

[labeas]

This looks interesting.
I've had problems trying to install <grub2-forUEFI>.
Since I'm still using Ver7.2 of TC64: I thought to update to ver10,
while installing for the newProblematic UEFI laptop.
Since oldLaptop:V7.2 boots with no problems, and good font-size etc. I
thought to start from a known good state.
 Could I use these existing partitions of my "Ver7.2 of TC64 BakUpStik",
and just loses the "MBR",
and rename the dirs which I want to keep for BakUps?
Device      Boot    Start       End   Sectors   Size  Id Type
/dev/sdc1   *        2048   4689547   4687500   2.2G   c W95 FAT32 (LBA)
/dev/sdc2           4689548  15630335  10940788   5.2G  83 Linux
--------------
So far I've had no explanation of how syslinux & grub can have different
"kernel and initrd" files: eg: isolinux.cfg = 2 files:
    KERNEL /boot/vmlinuz64
    INITRD /boot/corepure64.gz
but, *2/EFI/BOOT/grub/grub.cfg  = 3 files ?! :
linux /boot/vmlinuz64v10 ...
initrd /boot/corepure64v10.gz /boot/modules64.gz
 What is the modules*.gz which syslinux doesn't need ?