Tiny Core Linux
Tiny Core Base => TCB Talk => Topic started by: Yleisajattelija on November 12, 2026, 01:56:20 AM
-
Tried again to install TC. With Ubuntu workstation (Ubuntu is current distro, transition to Debian is going...) need DVD setup disk for USB, too.
I found documentation (yes, I make docs...) and bunch of non-working USB-boot sticks from my previous attempt to make bootable USB-stick. I have some experience with embedded environments with Uboot and linux static drivers, but same methods are not working with Legacy BIOS, extlinux, static kernel drivers and udev -system. There is some mystical bug on USB-bridge setup, which terminate boot process. USB-boot is known to work with win and grub2, so there must be solution for that.
But there is lot of other isssues: I think boot process and driver installation should be totally different. TC is pro system, and pro's want to control things, especially drivers which are serious security problem (=runs at system level permissions).
I will try this kind of system:
1) Debian, network connection and 2 USB sticks. One stick (INS-stick) for installation and drivers database and one stick (OU-stick) for "operative use". On OU-stick is only those drivers, which are actually needed.
2) Both sticks: Formatting and partitioning with standard tools fdisk/cdisk. File format for current PC-BIOS boot (typically Win95 FAT32 LBA)). Create small boot partition for grub2 code.
3) Both sticks: Mrb.bin/GPT settings (boot bit, jump vector to boot partition (=Grub2 code), etc.), and file copy (=dd) for grub2 code to boot partition)
4) Both sticks: Stand alone grub2 boot to test boot USB-stick boot (if, succeed, you have limited kernel, drivers and command set to work with). I'm not (yet) familiar with Grub2, but seems to me that available disks and other boot media is visible, and you can boot Grub at "/boot" directory at boot partition, at leas temporary. Typically system crashes when trying to start kernel at new permanent filesystem location. No single message is available if crash, so it it impossible to find out what was wrong. It is lot easier ot try-and-error just Grub2 boot than whole system.
5) INS-stick: load TC-command line version to main partition "/"
6) Boot on TC with INS-stick, put OP-stick on other USP-port
7) Load full TC with drivers, GUI, Xorg, etc, to OP-stick on several phases and try boot on OP-stick on every phase
8)If OP-stick is working, set INS-stick for system rescue stick (drivers etc.)
-
I think, this will be nice systems with dCore, drivers and applications can be fetched from .deb database in systematic manner, modified and packaked for TC use. INS-USB is working as "pure" TC environment without pollution. Several OP-USB stics can be made for driver testing etc. Practical problem is that I have large 4k display, and VESA formats are very ugly wiht it, but I think I can manage INS-USB without GUI.
-
I think this is it:
"GRUB 2 has more reliable ways to find its own files and those of target kernels on multiple-disk systems, and has commands (see search) to find devices using file system labels or Universally Unique Identifiers (UUIDs)."
https://www.gnu.org/software/grub/manual/grub/grub.html
-
At first fast read of those grub2 documents, grub2 installation should be very straightforvard and UUID handling on boot is very flexible -> USB boot should be routine.
Is there some hidden problems, why it is not used on current TC version?
-
See: https://forum.tinycorelinux.net/index.php?topic=19364.0
I recently installed fedora to a laptop hard drive and then added tinycorelinux.
Fedora (and I presume other linux distros) has a complicated script driven grub setup and it took me ages to get it to dual boot with CorePure64 - I have still not managed to get it to dual boot Core. The fedora boot is not even consistent, some times it (correctly) uses hd0 and sometimes it fails trying to use hd1.
The fedora grub setup is such a pain that I've gone back to using a usb stick to boot Core/Corepure64 on the laptop.
-
The Grub scripts are problematic, because there is endless variations of HW and BIOS combinations.
Especially automatic USB booting is difficult, because of USB devices have dynamic mounting point.
There must be a script, of course, but it have to build interactive manner. I think Grub must be installed stand-alone first, and carefully tested to find installation media and /boot -directory correctly.
-
The Grub scripts are problematic, because there is endless variations of HW and BIOS combinations.
Especially automatic USB booting is difficult, because of USB devices have dynamic mounting point.
There must be a script, of course, but it have to build interactive manner. I think Grub must be installed stand-alone first, and carefully tested to find installation media and /boot -directory correctly.
Hi Yleisajattelija,
Within the context of grub.cfg, the installation media, and /boot directory on it, are implicitly known.
I use almost exactly the procedure Juanito provided in the link in Reply #4, with the only difference being that I, for my own preference, install each Tiny Core version to it's own subdirectory under the main boot/ directory and each such Tiny Core directory has its own tce/ and/or tce64/ directory under that. Below is an excerpt from a working grub.cfg. The ability to use shell script style variables hugely simplifies the insertion of additional menu entries and, in order to move this grub.cfg to a different boot device, I need only copy it over and update BOOTUUID, in the first line, to the correct uuid from the new device's main file system (-not- the EFI filesystem):
set BOOTUUID=b4568e00-cdf2-4675-abca-4cb16cc24661
# * * * NOTE: BOOTUUID is specific to each device * * *
#####
#
# Juanito's instructions included all of these, but it seems to work for me
# with just these two:
#
loadfont unicode
insmod all_video
# set gfxmode=1366x768x32
# set gfxpayload=keep
# set gfxterm_font=unicode
# terminal_output gfxterm
#
#####
search --no-floppy --fs-uuid --set=root ${BOOTUUID}
#####
#
# menu setup - DEFAULT and FALLBACK selections, TIMEOUT
#
default=core17.1_64bit
fallback=core17.0_64bit
timeout=30
#
#####
#####
#
# General options for all Tiny Core versions
#
GENERALOPTS="quiet noswap noutc tz=GMT-5 multivt host=dolly"
#
#####
#####
#
# 2026-07-17 22:50
#
menuentry "core17.1_64bit" {
set COREDIR=core17.1
set BIT=64
set TCE=tce${BIT}
set WAITUSB=waitusb=30:UUID="${BOOTUUID}"
set TCESPEC=tce=UUID=${BOOTUUID}/boot/${COREDIR}/${TCE}
# disable HDMI sound (on host "dolly") in order to use analog sound
set BLACKLIST=blacklist=snd_hda_intel
linux /boot/${COREDIR}/vmlinuz${BIT} ${GENERALOPTS} ${TCESPEC} ${WAITUSB} ${BLACKLIST}
initrd /boot/${COREDIR}/rootfs${BIT}.gz /boot/${COREDIR}/modules${BIT}.gz
}
#
#####
#####
#
# 2026-02-11 06:17
#
menuentry "core17.0_64bit" {
set COREDIR=core17.0
set BIT=64
set TCE=tce${BIT}
set WAITUSB=waitusb=30:UUID="${BOOTUUID}"
set TCESPEC=tce=UUID=${BOOTUUID}/boot/${COREDIR}/${TCE}
# disable HDMI sound (on host "dolly") in order to use analog sound
set BLACKLIST=blacklist=snd_hda_intel
linux /boot/${COREDIR}/vmlinuz${BIT} ${GENERALOPTS} ${TCESPEC} ${WAITUSB} ${BLACKLIST}
initrd /boot/${COREDIR}/rootfs${BIT}.gz /boot/${COREDIR}/modules${BIT}.gz
}
#
#####
#####
#
# 2026-01-03 09:16
#
menuentry "core17.0_a1_32bit" {
set COREDIR=core17.0a1
set BIT=""
set TCE=tce${BIT}
set WAITUSB=waitusb=30:UUID="${BOOTUUID}"
set TCESPEC=tce=UUID=${BOOTUUID}/boot/${COREDIR}/${TCE}
# disable HDMI sound (on host "dolly") in order to use analog sound
set BLACKLIST=blacklist=snd_hda_intel
linux /boot/${COREDIR}/vmlinuz${BIT} ${GENERALOPTS} ${TCESPEC} ${WAITUSB} ${BLACKLIST}
initrd /boot/${COREDIR}/rootfs${BIT}.gz /boot/${COREDIR}/modules${BIT}.gz
}
#
#####
#####
#
# 2025-07-15 00:45
#
menuentry "core16.1_64bit" {
set COREDIR=core16.1
set BIT=64
set TCE=tce${BIT}
set WAITUSB=waitusb=30:UUID="${BOOTUUID}"
set TCESPEC=tce=UUID=${BOOTUUID}/boot/${COREDIR}/${TCE}
# disable HDMI sound (on host "dolly") in order to use analog sound
set BLACKLIST=blacklist=snd_hda_intel
linux /boot/${COREDIR}/vmlinuz${BIT} ${GENERALOPTS} ${TCESPEC} ${WAITUSB} ${BLACKLIST}
initrd /boot/${COREDIR}/rootfs${BIT}.gz /boot/${COREDIR}/modules${BIT}.gz /boot/${COREDIR}/microbrew.gz
}
#
#####
To insert a menu entry for another version of Tiny Core, I can just copy an existing menu entry, give it a new menuentry name and then update the variables COREDIR and BIT. COREDIR is the name of the directory under boot/ where the kernel and .gz files are located. BIT is the architecture indicator - "64" for x86_64 and "" (empty) for x86. TCE directories you create are tce64/ for x86_64 and tce/ for x86. When I do a new install, I use a script to pre-download a bunch of extensions from the relevant repo to the new tce directory at the same time I'm downloading the kernel etc.
I rarely try out non-Tiny Core distros and when I do, nothing is allowed to mess with my grub.cfg (though I do have it backed up elsewhere).
The un-condensed version of this file includes a ton of comments including the full text of Juanito's procedure and my own notes, and including several years worth of menu entries for previous Tiny Core versions - all making it more of a "TLDR" than it already is. ;)
-
Thanks for Leee for detailed description of TC Grub installation!
Quotation on Grub documentation:
------------------------------------------------------------------------------------------------------------------------------------------
"The following is a quotation from Gordon Matzigkeit, a GRUB fanatic:
Some people like to acknowledge both the operating system and kernel when they talk about their computers, so they might say they use “GNU/Linux” or “GNU/Hurd”. Other people seem to think that the kernel is the most important part of the system, so they like to call their GNU operating systems “Linux systems.”
I, personally, believe that this is a grave injustice, because the boot loader is the most important software of all. I used to refer to the above systems as either “LILO”5 or “GRUB” systems.
Unfortunately, nobody ever understood what I was talking about; now I just use the word “GNU” as a pseudonym for GRUB."
-------------------------------------------------------------------------------------------------------------------------------------------
That is actually true. Most difficult issues using operating system on modern multicore microprocessor must be handled by bootloader. Memory Management Unit (MMU) on modern multicore microprocessor is actually more complex than microprocessor core itself, and critical transition from real mode to protected mode is done on bootloading stage.
I have some experience on embebbed environment with GuruPlug Plus, Kirkwood SOC and U-boot. I got help from Debian Armel Installer maintainer Martin Michlmayr, but even he couldn't help to get Guruplug booting. Unnamed Linux Armel maintainer refused cooperation for "some reasons" so it was impossible to modify FDT-config files (Kirkwood propriety staff).
Critical stage is switching to protected mode and simultaneous to start MMU and hope that next jump to virtual memory address founds it way to physical memory chip.
-
You are quite welcome. I don't often get a chance to discuss such things with anyone who cares. :)
While I wouldn't want to downplay the importance of the bootloader, I think most people see it as less important than the OS itself because it performs its function and then gets out of the way, never to be active again until the next reboot - and I can't say I disagree with that viewpoint. While a boot loader surely does a lot more than meets the eye, most of what it does, in fact, -does not- "meet the eye" so a lot of folks (myself included) have very little idea of what all goes on in there.
I'm just happy that I can set up grub.cfg the way I want it, even though I'm just scratching the surface. I like grub2 much better than syslinux/extlinux/isolinux, grub4dos or lilo but my opinion has little to do with the low level nuts and bolts and more to do with the installer-facing parts - primarily that grub.cfg works a bit like shell script. grub4dos is ok, except for the stupid DOS like syntax for variables, but grub2 is better.
-
referencing multiple bootloaders, Barry Kauler has a simple straightforward post:
https://www.easyos.org/install/limine-bootloader.html
edited to add:
https://github.com/Limine-Bootloader/Limine/blob/trunk/FAQ.md