bootman - boot versions on one drive/partition

[mocore]

pokeing around in the repo i found http://tinycorelinux.net/14.x/x86/tcz/bootman.tcz.info

(i suspected because of the small size 
"Size:      4.0K")
it was some scripts in an extension

so i had a look &

Code: [Select]

# download extension
wget http://tinycorelinux.net/14.x/x86/tcz/bootman.tcz.info
# create a temporary directory
mkdir tczx
# mount the extension
sudo mount -o loop ./bootman.tcz ./tczx
#  find files
find ./tczx/ -type f
find shows one file

tczx/usr/local/sbin/bootman

Code: [Select]

less tcz/usr/local/sbin/bootman
it appears to use syslinux ....

Comments:      Allows the user to boot into numerous versions of
                TCL using a single drive/partition and separate
                mydata.tgz and/or persistent opt/home directories
                sudo bootman VERSION [PLATFORM=x86_64]
                VERSION=5 or more, PLATFORM=x86 or x86_64 (x64)
                ONLY INTENDED for default boot loader; grub not
                yet implemented and PXE not intended here.

i wander if any one (other than the author ;p ) has tested this script/approach ??

which seams conceptually similar to the method mentioned hear
https://forum.tinycorelinux.net/index.php/topic,22546.msg141259.html#msg141259
and others @ https://forum.tinycorelinux.net/index.php/topic,26464.0.html

[Leee]

I haven't played around with bootman.tcz at all but I just use grub and have a menu entry for each Tiny Core installation on the device.  The disk layout is structured like this:

Code: [Select]

boot
     core15.0
              tce
                    optional
              tce64
                    optional

     core14.0
              tce
                    optional
              tce64
                    optional
and so on. Your computer can be a Tiny Core museum.   

In addition to the simplified view above, there are also "ondemand" and "upgrade" directories and all that happiness in the expected places.

Both the x86 and x86_64 versions of vmlinuz, rootfs.gz and modules.gz live at the "coreXX.X" level.  The "tce" directories are used for x86 while the "tce64" directories are used for x86_64.
The grub directory can be under boot or, as is my current habit, on the EFI partition under EFI/BOOT.

I don't use persistent home, so each older version has a mydata.tgz snapshot of the last time I used it, a copy of which was brought forward to the next newer version.

[Leee]

Here's a (pared down) sample grub.cfg for the above setup (attached).

[CentralWare]

pokeing around in the repo i found http://tinycorelinux.net/14.x/x86/tcz/bootman.tcz.info
i wander if any one (other than the author ;p ) has tested this script/approach ??

@mocore: We had to implement a simple method to allow us to switch between TCL versions (5.x to Current), flip between x86 and x64 (or ARM6/7/7L in the newer in-house version) AND allow us to switch between "projects" (ie: the first project might be a desktop environment running X3D, Gnome, numerous support extensions and a customer profile containing their files, then twenty minutes later we may have to put that client on hold and revamp the same machine with a remote compiler environment using an NFS mount for /src, all without the need for rebooting.  "BootMan" is a very stripped down recipe from our in-house version which focuses on just the first stage -- 5.x to Current x86/64 swapping.

Has the "bootman" script been tested...  Initially it was submitted because ONE other person needed a way to do the same principle concept and I thought maybe others might have use for the same, but doubtful to be all that many overall.  Was it tested by more than myself?  Yes.  By TWO people!!

Can Ext/SysLinux/Grub configs do a better or easier job?
No.

In fact, they don't work at all here.  They can't!
The machines we use our Project Manager system on are all headless rack machines which don't have the ability to select things from a boot menu.

Example: BootMan can jump between Tiny Core v14 x86_64 and seconds later it's running v11 x86.  Each "Version" it runs can all live on the same drive/partition in an organized fashion.

Our in-house version goes the extra step by switching ACTIVE flags between two hard drives in order to determine if it's booting a WIN or NIX based operating system and for NIX, a set of Grub2 config files are swapped in and out to boot from multiple images of Debian, Tiny Core, Ubuntu, CentOS and a few others using hard drive images that are remotely mounted via AoE, NFS, iSCSI or SMB.  (A similar version exists for non-86 processors.)

[mocore]

hi CentralWare

thanks for the explanation / background of your motivations for writing bootman

(just replying quickly (while bleary eyed & un-caffeinated) to one point)

Can Ext/SysLinux/Grub configs do a better or easier job?
No.

In fact, they don't work at all here.  They can't!
The machines we use our Project Manager system on are all headless rack machines which don't have the ability to select things from a boot menu.

afaik / fwiw it is possible to configure  other boot-loaders to boot a default menu entry
with out user interaction to manually "select things from a boot menu."

aka
"other horsemen loaders can ride boot headless two"

thanks again for the script

[CentralWare]

afaik / fwiw it is possible to configure  other boot-loaders to boot a default menu entry

@mocore: Yes, boot configs can be set up to select a default menu entry, but how does the horseman change to something other than default?

1. Have an app or script modify the boot config and change the DEFAULT= to something else on the list (then reboot to effect changes)

2. Have an app or script create a new boot config based solely on a single os/entry (then reboot - #2 is similar to what bootman was aimed for.)

3. If the kernel/core are the same, kill off all running services, unload extensions, clear cache and swap, unload kernel modules, etc. and start fresh without rebooting (which is our in-house version; it's really simple in TCL, reasonably simple in Mint...  not so simple with Deb )

[mocore]

2. Have an app or script create a new boot config based solely on a single os/entry (then reboot - #2 is similar to what bootman was aimed for.)

3. If the kernel/core are the same, kill off all running services, unload extensions, clear cache and swap, unload kernel modules, etc. and start fresh without rebooting

this kind of reminds me of hyperos https://msfn.org/board/topic/9733-hyperos-2003/
who's blurb says "It turns ***dows into a disposable razor. Once it stops working you throw it away and start using another one. "

presumably nix/tc user's  have different motivations for rebooting 

Here's a (pared down) sample grub.cfg for the above setup (attached).

thanks!

[CentralWare]

@Leee: I just finished installing Grub2 on a little drive that's going to be the Master of Disaster of about two dozen baby drives (2.5" SATA-II laptop drives that were otherwise collecting dust) which are dedicated to a single Win11 and twenty-some flavors of 'Nix/BSD connected by a USB3/3.1 desktop hot-swap enclosure and the insanity being TCL and W11 have dedicated SSD's internally, everyone else plugs into the hot-swap if we need to venture out with any of the other players and Grub's being experimented with to see whether or not "which ever drive is connected is the one that boots" if that menu item is chosen works without a hitch.  I already expect EFI is going to be a problem for a few distros (Ubuntu/Bodhi ISOs were flagged as expired/revoked signatures so this should be fun!)