Installing Tinycore directly to USB-stick without burning CD-rom

[Yleisajattelija]

I'm trying to develop method to install TC directly to USB stick without burning CD-rom first, using another bootable USB-stick as TC-source.

By CDROM -burning TC USB-install is OK. I'm using syslinux(extlinux), partitioning with gparted msdos partioning table, bootable flag and ext2-filesystem, dd copy syslinux mbr.bin to USB, extlinux.conf UUID settings with blkid and correct UUID number, 5sec waitusb. new core.gz and vmlinuz, extlinux --install /dev/sdX for syslinux.

Not booting, one time probably booted from target USB (not sure about that) when both USB-sticks were installed.

Boots normally from source USB (made by CDROM).

I suspect, that syslinux copies some runtime parametres from environmet and is very sensitive how to be launched.

I made some experiments with gdisk and MBR/GTP -hybrid, gparted did leave starting sector to 2048 after gdisk (is that problem?)

Question:

What is correct system for manual TC-USB installation? Computer BIOS have UEFI support (not used currently), but there is some combability issues with that.

[bmarkus]

Did you read http://tinycorelinux.net/faq.html ?

[Yleisajattelija]

There is "standard" problem with documentation, part of documents are always out of date, and it is impossible to know which is currently useful.

I have understood, that there is systematic problems with linux USB-boot, that is probably reason why TC standard USB installation is by CDROM. 

I know kernel loading problems with IBM-PC memory limits, real/protected mode transition problems, 8086-style address segmentation and BIOS-LBA addressing.

Ultimate solution is of course UEFI -boot with GPT-partitioning, but I don't know is TC supporting that without modifications.

But USB-identification is one problem on boot, I don't know if using disk labels is solution at current TC setup.

Edit: typo

[bmarkus]

There is "standard" problem with documentation, part of documents are always out of date, and it is impossible to know which is currently useful.

Be specific and do not make generic statements. Are you saying that the USB boot section of Tiny Core FAQ is not correct and outdated.

BTW, there is NO any problem with USB boot, opposit to your statement.

[Yleisajattelija]

As I did wrote, normal TC USB-installation via CDROM works OK.

Problems are with manual USB-TC installation from source USB-TC.

Reason for manual installation is to avoid CDROM-burning phase and to control HW-system-spesific features.

Point is, I don't find documentation how to install TC manually to USB-stick, Tiny Core FAG is not including information for that, I think. I don't know it is up to date, either.

Few answers I already can tell:

a) Why not use solid standard CDROM based installation? Yes you can but it is slow and tedious.
b) TC-kernel can be loaded as any linux-kernel. Yes, but kernel can be heavily paramerized, and especially kernel loading phase is very sensitive for minor changes and/or missing parametres.
c) Use grub, lilo etc. other loader. OK, thats fine for me if I can find documentation
d) Use search and/or google. Done that, no help (yet)

[Yleisajattelija]

My current theory is that syslinux uses msdos style bootable floppy installation system, and copying boot system code from source disk. That OK with floppy and HD:s (=CDROM), but encouters problems when used with USB-stick.

USB-stick is loaded dynamically, and part of system data cannot be copied directly.

When syslinux is run from CDROM, correct data is copied to USB, but when syslinux run from another USB, problems start.

[curaga]

The manual install (grub 0.97 page) instructions work fine on USB sticks, and you can also check the tc-install script for extlinux instructions.

[Yleisajattelija]

OK, thanks!

Of course, extlinux is more "TClike" as it small and simple, but it is strongly tied with BIOS/msdos, which is problematic sometimes, but I will look grub docs, if it works.

[Yleisajattelija]

The manual install (grub 0.97 page) instructions work fine on USB sticks, and you can also check the tc-install script for extlinux instructions.

Why just grub 0.97 (UEFI-support missing) and not 2.0? Both versions are missing proprietary USB-stickboot docs, so general boot docs probably works with USB, I guess.

Edit: lot of comments for grub 2 being big complex and difficult to use. Lets dig syslinux little bit more ...

[Juanito]

Ultimate solution is of course UEFI -boot with GPT-partitioning, but I don't know is TC supporting that without modifications.

Yes, TC does support EFI/UEFI boot without modification - see various form posts by searching on EFI or UEFI.

[Yleisajattelija]

ARCH-linux documentation:

At 4.) sector location might be a problem with TC ramdisk:

Syslinux boot process
1. Stage 1 : Part 1 - Load MBR - At boot, the BIOS loads the 440 byte MBR boot code at the start of the disk (/usr/lib/syslinux/bios/mbr.bin or /usr/lib/syslinux/bios/gptmbr.bin).
2. Stage 1 : Part 2 - Search active partition. The Stage 1 MBR boot code looks for the partition that is marked as active (boot flag in MBR disks). Let us assume this is the /boot partition for example.
3. Stage 2 : Part 1 - Execute volume boot record - The Stage 1 MBR boot code executes the Volume Boot Record (VBR) of the /boot partition. In the case of syslinux, the VBR boot code is the starting sector of /boot/syslinux/ldlinux.sys which is created by the extlinux --install command. Note ldlinux.sys is not same as ldlinux.c32.
4. Stage 2 : Part 2 - Execute /boot/syslinux/ldlinux.sys - The VBR will load rest of /boot/syslinux/ldlinux.sys. The sector location of /boot/syslinux/ldlinux.sys should not change, otherwise syslinux will not boot.
 Note: In the case of Btrfs, the above method will not work since files move around resulting in changing of the sector location of ldlinux.sys. Therefore, in BTRFS the entire ldlinux.sys code is embedded in the space following the VBR and is not installed at /boot/syslinux/ldlinux.sys unlike the case of other filesystems.

5. Stage 3 - Load /boot/syslinux/ldlinux.c32 - The /boot/syslinux/ldlinux.sys will load the /boot/syslinux/ldlinux.c32 (core module) that contains the rest of core part of syslinux that could not be fit into ldlinux.sys (due to file-size constraints). The ldlinux.c32 should be present in every syslinux/extlinux installation and should match the version of ldlinux.sys installed in the partition. Otherwise syslinux will fail to boot. See http://bugzilla.syslinux.org/show_bug.cgi?id=7 for more info.
6. Stage 4 - Search and Load configuration file - Once Syslinux is fully loaded, it looks for /boot/syslinux/syslinux.cfg (or /boot/syslinux/extlinux.conf in some cases) and loads it if it is found. If no configuration file is found, you will be dropped to a syslinux boot: prompt. This step and rest of non-core part of syslinux (/boot/syslinux/*.c32 modules, excluding lib*.c32 and ldlinux.c32) require /boot/syslinux/lib*.c32 (library) modules to be present (http://www.syslinux.org/wiki/index.php/Common_Problems#ELF). The lib*.c32 library modules and non-core *.c32 modules should match the version of ldlinux.sys installed in the partition.

[Yleisajattelija]

Obviously the problem is not related to ramdisk, becouse bootcode use static location at /boot/extlinux.

All USB boot examples with syslinux I have found copies system files from CDROM, so there is possible extlinux read-bootsector-for-copy problem from USB.

I think extlinux cannot read correctly USB-bootsector, it is not contigious as HD or CDROM. For protect flash-memory, USB-driver circulates write cyles evenly aroud flash-memory and at least block size is different than HD, worst case it is not posssible to force file block at certain fixed address at all.

Anyway, if grub works, I think problem is solvable and there is just a bug at extlinux read-boot-sector-for-copy -code.

[Yleisajattelija]

This problem seems to be even more complicated:

Ext2/4 -filesystems are cabable to handle flash erase blocksizes. When I was really coding (year -95), first flash memories were use and those were "manually" block erased. Nowdays flash memories are more/less self-erasing types, and erase/-write cycles are (more/less) transparent.

Anyway, those are strongly HW-implementation spesific issues and ext2/4 filesystems cannot rely any spesific memory type, so there is some kind adaptation layer for flash erasing. This is performance issue too, so ext2/4 includes parametres to adapt known memory types.

Problem is now threefold, to load boot sector, you need to be combatible with:

a) BIOS and real mode of uP (rememberheavy memory address space limitations)
b) Old msdos -filesystem/partion table limitations (MBR+bootsector)
c) Ext2/4 filesystem with flash memory erase properties

Probably this is not solely extlinux solvable problem, you must use correct USB-stick partitioning scheme and/or correct ext2/4 flash erase parametres to get boot process to work.

Edit: As above mentioned sector may not change during ldlinux.sys loading. so sector size is now essential. But there seems to be two different sector sizes. One for logical sector and second for I/O (probably related to USB-transfer protocol).

[Yleisajattelija]

Syslinux Hardware problems docs:

--------------------------------------------------------
USB-Geometry

Geometry-related issues are one of the more common reasons preventing booting in some systems while the same drive may work in others. The BIOS inspects the drive, then estimates the geometry based on the total size of the drive and on some key content on it. If it fails to estimate properly, it can either be assumed unbootable or exhibit strange failures when attempting to read blocks (e.g. unable to find <somefile> or only showing the Syslinux copyright banner but no other message).

Check to ensure that the LBA addresses match the CHS addresses and that the FAT VBR (Volume Boot Record; aka BPB or BIOS parameter block) matches these values too.

Some systems also refuse some attempted geometries on some drives (i.e. you are trying to change "sectors per track" and "heads per cylinder") such that even if the partitions are aligned to the geometry properly, it may still refuse to boot. Partitioning with "cylinder alignment", or with "MiB alignment", or with no alignmet at all, would probably not affect the chances of successfully booting; but using an adequate drive geometry that most BIOS can recognize, will.

Depending on the system, you may find better luck with a USB drive with a single partition of either FAT16 or FAT32 starting at the standard CHS 0,1,1 and ending on the edge of a cylinder.

For example, if a drive has a size of 128 MB (or slightly larger), it should be assumed with 64 heads per cylinder and 32 sectors per track. Its partition should then end at C/H/S: 127 / 63 / 32 .

Drives larger than 1 GB should be regarded as having 255 heads per cylinder and 63 sectors per track. E.g. a drive of 15'794'176 blocks (7.5 GB) should have its partition end at C/H/S: 982 / 254 / 63 .

Drives larger than 16'434'495 blocks should bear its partition end at C/H/S: 1023 / 254 / 63 . Setting the partition's ENDing LBA to the full drive size may or may not hamper its bootability.

Suggested CHS values according to size are also relevant (and might also apply) for building isohybrid images.
-----------------------------------------------------------------------------------------------------------------------------------

[linuxguy2014]

For whatever reason it seems the author(s) of this distro are ignoring this problem.  A very simple search or browsing of the forums and you can see this problem constantly (at least once per week someone is trying to get this right).

Interestingly enough the 2 "fixes" mentioned on the FAQ for using unetbootin are two options:

1) add a 2nd partition with /tce as a dir
2) rename cde to tce on the partition that unetbootin created

None of these work.

Authors don't you think enough people have tried to make this work that maybe it's an issue needing some attention?