Tiny Core Linux
Tiny Core Extensions => TCE Tips & Tricks => Topic started by: polikuo on April 11, 2017, 08:07:46 AM
-
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 (http://forum.tinycorelinux.net/index.php/topic,19364.0.html)
To create a GPT USB stick, you'll need gdisk.
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
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 tce-load -wil dosfstools
mkfs.vfat /dev/sdb1
mkfs.vfat /dev/sdb2
mkfs.ext4 /dev/sdb3
sudo rebuildfstab
setup syslinux 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 ! :D
Reboot and test.
[EDIT]: Added missing cp comand and changed sdc references to sdb as requested. Rich
-
Have anyone got this to work on a UEFI only system?
-
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
-
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?
-
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
-
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?
-
Hi coreplayer2
The notebook did not contain /EFI/BOOT/ which was why I suggested he try polikuos tutorial using /EFI/Linux/ instead.
-
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.
:)
-
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. :D Someone
decided paths for Windows, several Linux flavors, and a generic Linux entry were all that was needed.
-
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. :D 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.. :P 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...
:P
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,..
:)
-
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?
-
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.
-
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. :)
-
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. :P
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.
-
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 ?
-
Does your tc-7.x installation boot on the new laptop?
core*.gz = rootfs*.gz + modules*.gz
-
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?
In general, to boot UEFI properly, you'll need GPT (GUID Partition Table).
That usually means losing your data during conversion.
However, it may not be a requirement depends on your motherboard.
If you wanna preserve your MBR partition table, you could copy all the UEFI firmwares and go for a shot. (Recommended)
The second method is force convert to GPT via a M$ machine and hope for the best.
You could convert a MBR disk to GPT without losing data. (not sure about USB, especially one with multiple partitions.)
In command prompt, run "diskpart", "list disk", "select disk X", "convert gpt"
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 ?
Hi, I could see several misunderstandings / mistakes here.
isolinux.cfg is designed for CDs, the precedence of syslinux.cfg in ISOLINUX is lower.
If you boot from a standard isolinux CD, isolinux.cfg would be used unless it couldn't find one.
It would then fall back to syslinux.cfg
However, if the boot media is not a CD, isolinux.cfg would not be used.
(Which is the case in my tutorial. It uses syslinux.cfg)
Unless, you somehow made your disk / USB Isohybrid (https://wiki.syslinux.org/wiki/index.php?title=Isohybrid).
(A feature I never use.)
isolinux.cfg = 2 files:
Sometimes grub & syslinux could chain-load to each other.
IIRC, for grub to load a syslinux ISO, an extra isolinux.cfg is required.
If you somehow made a loop, you could have several files:
isolinux --> grub --> isolinux --> grub --> isolinux ....
initrd /boot/corepure64v10.gz /boot/modules64.gz
Multiple filenames are separated by commas.
Otherwise, IIRC, it would only load the first argument.
In your case, a core*.gz will suffice.
What is the modules*.gz
Answered by Juanito:
core*.gz = rootfs*.gz + modules*.gz
Please refer to distribution files (http://tinycorelinux.net/10.x/x86/release/distribution_files/).
In SYSLINUX syntax, either
INITRD /path/to/core*.gz
or
INITRD /path/to/rootfs*.gz,/path/to/modules*.gz
is OK.
Note that whether the keyword [INITRD] is in capital letters or not does not matter, I prefer capital ones. :)