Tiny Core 17.0 released

[MikeRocor]

The release cut of Tiny Core 17.0 was announced yesterday (Wednesday) morning and I'm looking forward to "trying it out" - though I don't think there are many, if any changes from the beta. But I'm basically holding myself hostage - staying on the beta until I get my custom installer updated. I've been using my installer script in a partially finished state for years now, so 17.0 will be my treat to myself for finally finishing it (at least up to the next round of scope creep).

(hours later...)
There! I feel so much better now:

 

[KGIII]

You've probably said it before, but why do you use Tiny Core?

Is that the only distro you use?

I have played with it before. It's amazing what Linux-minded folks can do to keep things small. But it just doesn't appeal to me as a daily driver. While it does remind me a lot of some older desktop environments, I've become used to creature comforts and easy things.

Then again, I sometimes miss CDE. I just don't have it in me to go back to that era. Well, that and I have enough computational power to run any of the distros out there, regardless of their default RAM consumption.

 

[Alexzee]

Interesting:-

Does Tiny Core lack an installer in the downloaded .iso?

 

[MikeRocor]

Interesting:-

Does Tiny Core lack an installer in the downloaded .iso?

I think the installer is included in the Tiny Core "Plus" ISO (if not, the installer is available in the tc-install.tcz extension in the application browser) but I don't care for it for two reasons. 1) it uses syslinux/extlinux boot loader while I prefer grub2 and, 2) it installs to a specific directory layout while I prefer a different layout. I guess in the grand scheme of things, these are relatively minor points, but I've invested enough brain cells in doing it my way that I don't want to change. I really do think the way I do it is better (at least for me) though I can see how others might prefer the way the official installer does things.

I think most others install Tiny Core and, if they want to move to a newer version they just install the new one in place of the old one. To be clear, there's nothing wrong with that - I've never seen a new version of Tiny Core (even alpha and beta versions) actually break anything. But I prefer to do what is basically a multi-boot system where a new version is installed in parallel with the old version and a new menu entry added to the boot loader menu so that I can, with a simple reboot, revert back to any previous version. The way I handle the directory layout and the boot menu in grub.cfg make it incredibly easy to add a new version. My current primary system has over a dozen installs ranging from version 4.7.7 through 17.0, including the beta for 15.0, the alpha for 16.0 and alpha, beta and release for 17.0... and both 32 and 64 bit installs for some of them - it's like a little Tiny Core museum. TBH, once I install a new version, I almost never boot the older ones again - I tell myself I'll go back and delete the older ones but I never actually do so. Disk space is not really an issue lately,

My install script, however, is not as complete as the official Tiny Core installer. It does not deal with installing the boot loader, or any partitioning or formatting. To my way of thinking, those functions, while necessary, are not properly part of "installing the OS" (and they add a bit of complexity tot the installation process). I am toying with the idea of having it at least produce a menu entry for insertion into grub.cfg but the manual process is so simple that I'm a bit ambivalent about automating it.

 

[MikeRocor]

You've probably said it before, but why do you use Tiny Core?

Is that the only distro you use?

I have played with it before. It's amazing what Linux-minded folks can do to keep things small. But it just doesn't appeal to me as a daily driver. While it does remind me a lot of some older desktop environments, I've become used to creature comforts and easy things.

Then again, I sometimes miss CDE. I just don't have it in me to go back to that era. Well, that and I have enough computational power to run any of the distros out there, regardless of their default RAM consumption.

I occasionally play around with other distros, but haven't found one that I like as well as Tiny Core. Even on my Pinephone (which I doubt I'll ever use as an actual telephone), I try out the various available operating systems and can't help but wish they were more like Tiny Core - even though it's definitely not designed for that platform.

I've been using Tiny Core since the project was publicly announced in late 2008, so I've followed the development and occasionally contributed my two cents all along. I've found that the developers there share a similar mindset to mine - just with a lot more skill to back it up.

Why? Well, bunch of reasons.

First, just to get the negatives out of the way, I'm not a fan of the whole idea of systemd - not that I doubt it works just fine or anything like that so no need for an ideological discussion there. Second, I'm also not a fan of all encompassing desktop environments.

On the positive side

Tiny Core is fast - or at least fast enough. I don't have enough experience with other distros to make an informed comparison.

Tiny Core is "clean" - if I foul something up, a simple reboot literally reinstalls the running system. The kernel and root filesystem are loaded into RAM and the applications are mounted from read-only packages (squashfs) and the individual files are symlinked to wherever the belong (mostly under /usr/) and the only other files that survive the reboot are those that were explicitly backed up from RAM to persistent media before the reboot.

I'm a control freak when it comes to my computers. Tiny Core is easy to personalize to the extent the user wants. There are no applications loaded other than those that the user explicitly asked for and dependencies of those.

There is a certain charm to the initial tiny size of the OS but really, for desktop use, there's not much "tiny" left once I load up a bunch of stuff like Thunderbird, Firefox, VLC, Libreoffice, GIMP3.

It's really nice to be able to run the same OS on my daily driver as I run on my little "thin client" web server and my least capable netbook and my backup server. Of course, loading different selections of software for those different environments, one might not even recognize it as the same OS.

When I was still fairly uncertain of my Linux skills, I really liked that Tiny Core was small enough (simple enough) that I could wrap my head around it and have a reasonable understanding of what was going on. Now that I'm a little more secure in my Linux skills, I still like that - maybe even more.

Tiny Core draws a distinction between "the OS" and the "the GUI" and "the applications". This, and the way it's all implemented, makes it incredibly easy to configure a system just the way you want it. Since I don't particularly care for the default window manager (flwm) used in Tiny Core, I use what is more properly called "Core", the command line only install, and I load the GUI-related bits but with jwm as my window manager. The visible elements of my desktop consist entirely of

• jwm - the window manager. Also provides system "tray" and drop-down menus. Highly customizable.
• wbar - the icon "dock". Provides a bit of eye candy - which I use to make it almost disappear when idle.
• conky - system status/info at a glance

Support - I rarely have to ask for help on the Tiny Core forums, but when I do, the help is quick, knowledgeable and friendly. The wiki is also a gold mine of solutions to various questions.

The developers of Tiny Core don't call it a "distro", though I don't see why not. They think of it as a "toolkit" for building your own OS/distro. They've made it easy even to remaster the base OS for those who are so inclined - I did this once, just to learn how, then realized there was nothing I really wanted to change.

I just rambled a lot there and could go on and on even more but I probably shouldn't.

 

[KGIII]

I just rambled a lot there and could go on and on even more but I probably shouldn't.

Indeed and thanks!

 

[Alexzee]

I think the installer is included in the Tiny Core "Plus" ISO (if not, the installer is available in the tc-install.tcz extension in the application browser) but I don't care for it for two reasons. 1) it uses syslinux/extlinux boot loader while I prefer grub2 and, 2) it installs to a specific directory layout while I prefer a different layout. I guess in the grand scheme of things, these are relatively minor points, but I've invested enough brain cells in doing it my way that I don't want to change. I really do think the way I do it is better (at least for me) though I can see how others might prefer the way the official installer does things.

I think most others install Tiny Core and, if they want to move to a newer version they just install the new one in place of the old one. To be clear, there's nothing wrong with that - I've never seen a new version of Tiny Core (even alpha and beta versions) actually break anything. But I prefer to do what is basically a multi-boot system where a new version is installed in parallel with the old version and a new menu entry added to the boot loader menu so that I can, with a simple reboot, revert back to any previous version. The way I handle the directory layout and the boot menu in grub.cfg make it incredibly easy to add a new version. My current primary system has over a dozen installs ranging from version 4.7.7 through 17.0, including the beta for 15.0, the alpha for 16.0 and alpha, beta and release for 17.0... and both 32 and 64 bit installs for some of them - it's like a little Tiny Core museum. TBH, once I install a new version, I almost never boot the older ones again - I tell myself I'll go back and delete the older ones but I never actually do so. Disk space is not really an issue lately,

My install script, however, is not as complete as the official Tiny Core installer. It does not deal with installing the boot loader, or any partitioning or formatting. To my way of thinking, those functions, while necessary, are not properly part of "installing the OS" (and they add a bit of complexity tot the installation process). I am toying with the idea of having it at least produce a menu entry for insertion into grub.cfg but the manual process is so simple that I'm a bit ambivalent about automating it.

I can appreciated your preference for grub.
It's good that you have a Tiny Core museum. That way you could always boot into another install in a situation where time can't be wasted.

I'm triple booted myself and understand. Two questions.
Are you using a fstab file?
Would you mind, showing your custom grub configuration?

 

[MikeRocor]

I can appreciated your preference for grub.
It's good that you have a Tiny Core museum. That way you could always boot into another install in a situation where time can't be wasted.

I'm triple booted myself and understand. Two questions.
Are you using a fstab file?
Would you mind, showing your custom grub configuration?

fstab - There is one, of course, but I rarely mess with it. The system generates it at boot time and updates it whenever a new block device appears (I think udevd handles that but not I'm not sure about that). The only time I have to touch it is if I reformat an already present device - when I'm done, I can either unplug/replug the device or manually run sudo rebuildfstab (which is a script supplied with Tiny Core). Rebooting would do the trick too, I suppose.

grub - for USB sticks I use a double grub install that allows the same device to work with either a BIOS or an EFI machine. I make two partitions: partition #1 is the majority of the space and is formatted ext4 and partition # 2 is about 10 MB for EFI and is formatted VFAT. I do a regular grub install on the main partition and an EFI grub install on the EFI partition. There's only one grub.cfg and it lives in .../EFI/BOOT/grub. Since grub is kind of scriptable, I've arranged my grub.cfg to provide certain global values (mainly for boot codes to be passed to the kernel) and installation-specific variables (mainly directories in which to find the kernel). I like to include plenty of comments as documentation right there in grub.cfg. All edits to grub.cfg are manual, not using the various grub tools. Here's a sample of grub.cfg with a few menu items (the whole file is a bit TLDR because includes a bunch of menu items and really a lot of comments):

#####
#
# grub2-multi install on                                   2024-12-13 03:27
#   Seagate Backup Plus portable  4 TB USB 3.0 disk drive ("NAEB0Q8X")
#
#####

#####
#
#  BOOTUUID is the UUID of the main partition, not the EFI partition.  This
#  info MUST be updated when moving this file to a new device.
#
#  BOOTLABL is the fs label of the main partition.  It is no longer used
#  except as a visual cue.
#
set BOOTUUID=b4568e00-cdf2-4675-abca-4cb16cc24661
set BOOTLABL=NAEB0Q8X
#
#####

#####
#
# Juanito's instructions included all of these, but it seems to work for me
# with just these two - probably because I use only a text menu with no
# graphical background:
#
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 - colors, DEFAULT and FALLBACK selections, TIMEOUT
#

# I use a long timeout just as a matter of personal preference.
default=core17.0_64bit
fallback=core16.1_64bit
timeout=30

#                           
#   Black       Blue           green        cyan
# dark-gray  light-blue     light-green  light-cyan
#                           
#    red        magenta     brown        light-gray
# light-red  light-magenta  yelow          white
#                           
# foreground/background
#                           
color_normal=red/black     
color_highlight=light-red/black
menu_color_normal=magenta/black
menu_color_highlight=light-magenta/black
#                           
#####                       

                            
#####
#                           
## This blacklisting is an example taken from devrototrs' config where
## I have to blacklist broadcom wifi related kernel modules before loading
## the extensions that actually work with the legacy BCM4322 wifi device
#BLACKLIST="blacklist=bcma,ssb,b43"
#
#####


#####
#
# General options for all Tiny Core versions
#
#  I don't use persistent /home nor persistent /opt but, if I did, HOMESPEC
#  and OPTSPEC would be the boot codes specifying the UUIDs of the
#  relevant filesystems.
#
#  GENERALOPTS contains common boot codes that I use accross all of my
#  Tiny COre installations
#
GENERALOPTS="quiet noswap noutc tz=GMT-5 multivt host=dolly whathost=dolly"
# HOMESPEC="home=UUID=${HOMEFSUUID}"
# OPTSPEC="opt=UUID=${OPTUUID}"
#
#####


#####
#
#  Note that, in the menu entry sections below, the only parts that change
#  from one entry to the next are
#  * the menuentry line itself (the title)
#  * the COREDIR value, which is the specific directory (under /boot/) where
#    the given version of Tiny Core is installed.  This directory will contain
#    the 64 and/or 32 bit versions of the kernel (vmlinuz) and two initrd
#    files (rootfs.gz and modules.gz) and the 'tce" directory (tce or tce64).
#  * the BIT value, which is either empty or "64" where the empty value
#    indicates a 32 bit boot
#
#
#####


#####
#
# 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-24 14:35
#
menuentry "core17.0_b1_64bit" {
  set COREDIR=core17.0b1
  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_64bit" {
  set COREDIR=core17.0a1
  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

  # The third initrd (microbrew.gz) is a "lazy remaster" that I made as a
  # learning project.  It overwrites one of the files provided in rootfs.gz
  # with an altered file just so I can see that it worked.
}
#
#####

 

[jigsawrusty]

fstab - There is one, of course, but I rarely mess with it. The system generates it at boot time and updates it whenever a new block device appears (I think udevd handles that but not I'm not sure about that). The only time I have to touch it is if I reformat an already present device - when I'm done, I can either unplug/replug the device or manually run sudo rebuildfstab (which is a script supplied with Tiny Core). Rebooting would do the trick too, I suppose.

grub - for USB sticks I use a double grub install that allows the same device to work with either a BIOS or an EFI machine. I make two partitions: partition #1 is the majority of the space and is formatted ext4 and partition # 2 is about 10 MB for EFI and is formatted VFAT. I do a regular grub install on the main partition and an EFI grub install on the EFI partition. There's only one grub.cfg and it lives in .../EFI/BOOT/grub. Since grub is kind of scriptable, I've arranged my grub.cfg to provide certain global values (mainly for boot codes to be passed to the kernel) and installation-specific variables (mainly directories in which to find the kernel). I like to include plenty of comments as documentation right there in grub.cfg. All edits to grub.cfg are manual, not using the various grub tools. Here's a sample of grub.cfg with a few menu items (the whole file is a bit TLDR because includes a bunch of menu items and really a lot of comments):

#####
#
# grub2-multi install on                                   2024-12-13 03:27
#   Seagate Backup Plus portable  4 TB USB 3.0 disk drive ("NAEB0Q8X")
#
#####

#####
#
#  BOOTUUID is the UUID of the main partition, not the EFI partition.  This
#  info MUST be updated when moving this file to a new device.
#
#  BOOTLABL is the fs label of the main partition.  It is no longer used
#  except as a visual cue.
#
set BOOTUUID=b4568e00-cdf2-4675-abca-4cb16cc24661
set BOOTLABL=NAEB0Q8X
#
#####

#####
#
# Juanito's instructions included all of these, but it seems to work for me
# with just these two - probably because I use only a text menu with no
# graphical background:
#
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 - colors, DEFAULT and FALLBACK selections, TIMEOUT
#

# I use a long timeout just as a matter of personal preference.
default=core17.0_64bit
fallback=core16.1_64bit
timeout=30

#                          
#   Black       Blue           green        cyan
# dark-gray  light-blue     light-green  light-cyan
#                          
#    red        magenta     brown        light-gray
# light-red  light-magenta  yelow          white
#                          
# foreground/background
#                          
color_normal=red/black    
color_highlight=light-red/black
menu_color_normal=magenta/black
menu_color_highlight=light-magenta/black
#                          
#####                      

                           
#####
#                          
## This blacklisting is an example taken from devrototrs' config where
## I have to blacklist broadcom wifi related kernel modules before loading
## the extensions that actually work with the legacy BCM4322 wifi device
#BLACKLIST="blacklist=bcma,ssb,b43"
#
#####


#####
#
# General options for all Tiny Core versions
#
#  I don't use persistent /home nor persistent /opt but, if I did, HOMESPEC
#  and OPTSPEC would be the boot codes specifying the UUIDs of the
#  relevant filesystems.
#
#  GENERALOPTS contains common boot codes that I use accross all of my
#  Tiny COre installations
#
GENERALOPTS="quiet noswap noutc tz=GMT-5 multivt host=dolly whathost=dolly"
# HOMESPEC="home=UUID=${HOMEFSUUID}"
# OPTSPEC="opt=UUID=${OPTUUID}"
#
#####


#####
#
#  Note that, in the menu entry sections below, the only parts that change
#  from one entry to the next are
#  * the menuentry line itself (the title)
#  * the COREDIR value, which is the specific directory (under /boot/) where
#    the given version of Tiny Core is installed.  This directory will contain
#    the 64 and/or 32 bit versions of the kernel (vmlinuz) and two initrd
#    files (rootfs.gz and modules.gz) and the 'tce" directory (tce or tce64).
#  * the BIT value, which is either empty or "64" where the empty value
#    indicates a 32 bit boot
#
#
#####


#####
#
# 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-24 14:35
#
menuentry "core17.0_b1_64bit" {
  set COREDIR=core17.0b1
  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_64bit" {
  set COREDIR=core17.0a1
  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

  # The third initrd (microbrew.gz) is a "lazy remaster" that I made as a
  # learning project.  It overwrites one of the files provided in rootfs.gz
  # with an altered file just so I can see that it worked.
}
#
#####

snowrider

That’s a really clean and well-documented setup. I especially like the shared grub.cfg approach and the detailed inline comments everywhere.

 

[MikeRocor]

That’s a really clean and well-documented setup. I especially like the shared grub.cfg approach and the detailed inline comments everywhere.

Thanks. I wanted to keep it easily reproducable because I have this project going on where I I'm replacing all of my older USB sticks, some of them quite old, with newer, higher capacity USB 3.0 sticks and I decided to make all of the new ones bootable at least to a minimal system. Probably only a couple will have a full desktop load out.

Since USB sticks, by their nature, might boot on any of several machines, I'm playing around with some scripting in bootsync.sh that tries to determine exactly what host it's running on at boot time. To that end there's a custom boot code called whathost so I can override whatever automated means of determining the host and just -tell- it the hostname. I think I sanitized stuff like that out of the example grub.cfg but if you see something like "whathost=sabertooth" that's all that is. FWIW, boot codes, whether or not they are recognized by the kernel itself, are available in /proc/cmdline after bootup so you can add in whatever boot codes you want and parse for them as needed.