Tiny Core Linux
General TC => Remasters / Remixes - Unofficial => Topic started by: jazzbiker on December 24, 2023, 11:09:56 PM
-
Greetings!
I want to propose pre-installed image of CorePlus-14.0 and TinyCorePure64-14.0. New users may benefit burning it to the USB flash drive and obtaining ready to use various flavours of Core at the single drive in normal read-write mode, with backup and restore available, normal tce-load -w and so on. The image is dual-boot BIOS/UEFI, includes both x86 and x86_64 distribution files, proposes Core, Core64 and Corepure64 modes depending on Your hardware.
You can download an image from Google Drive :
https://drive.google.com/file/d/1X2y2RZRLArrqcpy8XfC4SMN0nlvDmMl0/view?usp=sharing
An image was packed following an approach already implemented in piCore images. When You burn this 600M image to for example 32G flash drive You have absolutely functional but restricted in free space (less than 200M) environment. If You are absolutely new to TinyCore You may continue experimenting with it. But if You want to utilize the whole drive space You need to perform few simple steps:
1. Load into "base+resize". You will see clear command line prompt.
2. Run "inflate.sh" script.
3. Reboot and continue with the full drive capacity accessible.
Please ask Your questions, and have Merry Christmas!
-
your description of the expansion of the working partition reminded me of EasyOS
https://easyos.org/tech/how-easy-works-part-2.html
At the first bootup, the initrd increases the size of the working-partition to fill the drive, and creates some folders in it...
-
Hi gadget42!
I was following the way piCore developers deal with unallocated drive space :-) Of course expanding/inflating may be unconditional, but probably in some (maybe afew) cases it may be inappropriate, I guess.
Another thing done after inflating is filesystem's UUID shuffling. Cloned image assumes cloned UUID, not good for regular use. Maybe separating these tasks is possible, in order to have possibility to change the UUID without inflating the filesystem.
-
Seasons Greetings - this sounds like how I have set up a Ventoy pendrive - except for expanding & using free space - downloading now, thanks. :)
-
Hi core-user!
If You are on the short leg with Ventoy You may try it with InstantCore. In case of success it may be attracting, as Ventoy can boot even the boxes with "secure boot = on", as far as I've read some time ago.
Happy Holydays!
EDIT: I want to warn You about using inflate.sh while running from Ventoy! I can not predict exactly what may happen, because I am not using Ventoy, but I guess inflate.sh will cause some kind of disaster (
-
Hi jazzbiker
I mounted your image file and did a little poking around.
Just some observations:
It contains partitions 1 and 3 but skips 2:
tc@E310:~/Downloads/tmp$ sudo losetup --show --find --partscan InstantCore.img
/dev/loop296
tc@E310:~/Downloads/tmp$ sudo lsblk -f /dev/loop296
NAME FSTYPE LABEL UUID MOUNTPOINT
loop296
|-loop296p1 vfat E28D-73DA
`-loop296p3 ext4 f6bff2ef-e204-46cd-a3e5-c86f6ca5073b
Probably not an issue, it just seemed odd.
There are 2 versions of rootfs.gz:
tc@E310:~/Downloads/tmp$ for F in `sudo find P3 -name rootfs*`; do ls -l $F; done
-rw-r--r-- 1 root root 3498790 Dec 25 01:40 P3/boot/14/0/3/0/rootfs.gz
-rw-r--r-- 1 root root 3470570 Dec 24 02:56 P3/boot/14/0/3/rootfs.gz
-rw-r--r-- 1 root root 3523605 Dec 24 02:56 P3/boot/14/0/6/rootfs64.gz
-
Hi Rich!
It contains partitions 1 and 3 but skips 2:
tc@E310:~/Downloads/tmp$ sudo losetup --show --find --partscan InstantCore.img
/dev/loop296
tc@E310:~/Downloads/tmp$ sudo lsblk -f /dev/loop296
NAME FSTYPE LABEL UUID MOUNTPOINT
loop296
|-loop296p1 vfat E28D-73DA
`-loop296p3 ext4 f6bff2ef-e204-46cd-a3e5-c86f6ca5073b
Probably not an issue, it just seemed odd.
I think it is not an issue, too. I create the drive partitions and filesystems with the help of the script - grub4tc.sh. My defaults are:
sdx1 - grub
sdx2 - boot
sdx3 - tce
The script asks for boot partition size and if it is zero, then sdx3/boot is used for distribution files. sdx2 appears to be absent.
I did in such a manner because distribution files are not necessary after the boot finished, and keeping them in the separate partition I guess slightly decreases the risk they will be damaged accidentally. Still TC default is /boot directory, so I decided to follow the default TC scheme for InstantCore.
There are 2 versions of rootfs.gz:
tc@E310:~/Downloads/tmp$ for F in `sudo find P3 -name rootfs*`; do ls -l $F; done
-rw-r--r-- 1 root root 3498790 Dec 25 01:40 P3/boot/14/0/3/0/rootfs.gz
-rw-r--r-- 1 root root 3470570 Dec 24 02:56 P3/boot/14/0/3/rootfs.gz
-rw-r--r-- 1 root root 3523605 Dec 24 02:56 P3/boot/14/0/6/rootfs64.gz
Yes, You are absolutely right. 32-bit version (/boot/14/0/3 subtree) includes two versions of rootfs.gz. The upper one is the default one, while /boot/14/0/3/0/rootfs.gz is used during "base+resize" boot menu option and is slightly customized: resize2fs and inflate.sh are added to the official rootfs.gz. So inflate.sh can be used only during "base" boot when not a single disk partition is mounted and all partitions are free to play them with.
Thanks for review! Merry Christmas!
-
Hi jazzbiker
... /boot/14/0/3/0/rootfs.gz is used during "base+resize" boot menu option and is slightly customized: resize2fs and inflate.sh are added to the official rootfs.gz. So inflate.sh can be used only during "base" boot when not a single disk partition is mounted and all partitions are free to play them with. ...
Ah, that makes sense.
Merry Christmas to you too.
-
Hi!
As far as I understand at this moment, nothing prohibits to write InstantCore to the hard drive. EFI grub is installed with "--removable" option which only means that such hard drive will work with any EFI motherboard. In such an application InstantCore seems to be the easiest way to install TC to the local hard drive. It may be test-driven and configured in the USB drive incarnation and then immediately self-copied to the hard drive. Only if the box is intended to be TinyCore only :-) Which is not bad but in opposite is very good.
Not yet tested, if anybody will find some obstacles, please warn me.
If /home must be persistent, the dedicated partition on the hard drive may be created with some gap from sdx3 (tce partition) and after image copying inflate.sh will fill the gap.
Looks of that kind. Or not?
-
Hi jazzbiker
... If /home must be persistent, the dedicated partition on the hard drive may be created with some gap from sdx3 (tce partition) and after image copying inflate.sh will fill the gap. ...
Persistent home and/or opt don't need to be put on separate partitions.
Anytime I do a Tinycore install, it gets its own partition with:
boot/ home/ lost+found/ opt/ tce/
An entry for this install gets added to grubs menu.lst file.
Then home, opt, and tce get populated to suit my needs.
-
Hi Rich!
Persistent home and/or opt don't need to be put on separate partitions.
Anytime I do a Tinycore install, it gets its own partition with:
boot/ home/ lost+found/ opt/ tce/
An entry for this install gets added to grubs menu.lst file.
Then home, opt, and tce get populated to suit my needs.
Thanks for the explanation, I must have remebered this :-) but I never use persistent /home or /opt.
But what must be the directory structure if You have several TC versions? Partition per version?
-
Probably directory per version:
/boot
/lost+found
/tc10/home
/tc10/opt
/tc10/tce
/tc11/home
/tc11/opt
/tc11/tce
...
?
-
Hi jazzbiker
I typically do partition per version.
I have also done this when I want a choice of booting
to a 32 or 64 bit environment:
/boot
core.gz
corepure64.gz
vmlinuz
vmlinuz64
/home
/lost+found
/opt
/tce
/tce64
I use this for when I want to be able to run one of
my compile scripts to produce 64 bit binaries.
-
After playing a bit with InstantCore the simple, yet probably silly, question arose in my head:
Why, damn, OSes in general and TinyCore especially are not distributed in the form of really alive filesystems? What is the sacred meaning of dead iso-s?
It is so comfortable and convenient to:
1. dd it to some drive and instantly dive at the full depth.
2. Run it in qemu, perform some tweaking and return to the point 1.
3. Mount in rw mode and adjust manually.
Sorry for me being too emotiional, but I am really astonished.
-
Why, damn, OSes in general and TinyCore especially are not distributed in the form of really alive filesystems? What is the sacred meaning of dead iso-s?
Well I still write them to CDs. You could include all the functionality of your disk image in a dd-able ISO anyway, catering for the likes of me as well. Dual BIOS/UEFI booting is possible with dd-written ISOs, though it took me quite a while to figure out how to set that up right.
For PiCore I think it would be better to distribute an image as a ZIP containing the OS files which can be unpacked to a preformatted SD card (the default FAT, or re-formatted ext* by the user). Much easier than dealing with disk image writer tools and expanding partitions. I did that for a PiCore-based package that I developed.
But everyone has their own opinions. I believe Puppy Linux switched from ISOs to disk images a while ago, so your opinion isn't unique. That might have turned me off, except I already hadn't tried a new Puppy Linux version in many years anyway.
-
Hi jazzbiker
... It is so comfortable and convenient to: ...
That's an easy statement to make when you have years of
experience and hindsight to rely on.
About 15 years ago when I was looking for an alternative to
Windows, I had neither of those to rely on.
... 1. dd it to some drive and instantly dive at the full depth. ...
I didn't know about dd. As a newb, that was probably a good thing.
... 2. Run it in qemu, perform some tweaking and return to the point 1. ...
Even if I knew about qemu, my hardware probably was not
up to the task of running it.
... 3. Mount in rw mode and adjust manually. ...
Mount? That would have been a foreign concept for someone coming
from the Windows world.
Back then, I started out with zero Linux experience. I wasn't looking to
install anything. I didn't want anything writing to my hard drive.
Those live ISO's were a useful stepping stone for this know-nothing
newbie. They allowed me (with my limited knowledge) to test various
distros to see which ones were best suited for my hardware prior to
committing to installing one.
-
Rich you mension DD
Here is a site that i have get lots of tips from regarding DD..
https://www.noah.org/mediawiki-1.34.2/index.php?title=Dd_-_Destroyer_of_Disks (https://www.noah.org/mediawiki-1.34.2/index.php?title=Dd_-_Destroyer_of_Disks)
-
Hi CNK!
Well I still write them to CDs. You could include all the functionality of your disk image in a dd-able ISO anyway, catering for the likes of me as well. Dual BIOS/UEFI booting is possible with dd-written ISOs, though it took me quite a while to figure out how to set that up right.
CDs are rather expensive toys nowadays :-) What is CD/USBflash exchange rate in Your country?
In fact almost every ISO found itself written to some kind of flash drive.
But everyone has their own opinions. I believe Puppy Linux switched from ISOs to disk images a while ago, so your opinion isn't unique. That might have turned me off, except I already hadn't tried a new Puppy Linux version in many years anyway.
Well, I'm glad not to be alone, and in the good company :-) Join us with BarryK!
-
Hi Rich!
Hi jazzbiker
... It is so comfortable and convenient to: ...
That's an easy statement to make when you have years of
experience and hindsight to rely on.
I think installation with the single dd is comfortable and convenient for absolute noobs too.
About 15 years ago when I was looking for an alternative to
Windows, I had neither of those to rely on.
Oh, yeah, 15 years ago I was buying laptops with Win installed too... But Knoppix looked like a portal into another world! I was young and handsome, now Linux swarm is holding us tight ;-)
... 1. dd it to some drive and instantly dive at the full depth. ...
I didn't know about dd. As a newb, that was probably a good thing.
Everything must be just in its time: first kiss, first s_e_x, first dd ...
... 2. Run it in qemu, perform some tweaking and return to the point 1. ...
Even if I knew about qemu, my hardware probably was not
up to the task of running it.
The same as above but
sed -e 's/dd/qemu/'
... 3. Mount in rw mode and adjust manually. ...
Mount? That would have been a foreign concept for someone coming
from the Windows world.
sed -e 's/qemu/mount/'
Back then, I started out with zero Linux experience. I wasn't looking to
install anything. I didn't want anything writing to my hard drive.
Those live ISO's were a useful stepping stone for this know-nothing
newbie. They allowed me (with my limited knowledge) to test various
distros to see which ones were best suited for my hardware prior to
committing to installing one.
Of course ISOs are great, but alive filesystem and even device images are - better? more flexible? attractive as for new experience? But bigger, still does it really matters nowadays?
-
Optical media is pretty much dead as far as installable live media is concerned - pendrives have been king since USB2 arrived. ;)
(If frightened of using 'dd', you can also use 'cat' or 'cp' to put nearly every image onto a pendrive.)
-
Hi core-user!
Optical media is pretty much dead as far as installable live media is concerned - pendrives have been king since USB2 arrived. ;)
I don't want optical media to be dead, sometimes they are well suited and in place due to their read-only nature.
In my understanding the game changer for USB drives was mostly appearance of "Boot from USB" option in BIOSes.
-
(If frightened of using 'dd', you can also use 'cat' or 'cp' to put nearly every image onto a pendrive.)
High-end, low-end, back-end, front-end, ..... frightened :-0
-
Tested installation of InstantCore to the local drive.
Box: EEE PC 901
Two local SSDs: 4G and 8G.
InstantCore written to 8G USB flash drive. Not inflated.
Boot from it into "base+resize"
Local drives are /dev/sda and /dev/sdb. Flash is /dev/sdc/
Install:
sudo dd if=/dev/sdc of=/dev/sda bs=1M count=600
That's all, folks!
-
Probably directory per version:
/boot
/lost+found
/tc10/home
/tc10/opt
/tc10/tce
/tc11/home
/tc11/opt
/tc11/tce
...
?
I use a directory per version but place them under /boot and some other directories off of the root directory of the device for mostly-static data (so in the example below everything implicitly starts with /mnt/sda1 or similar)
/boot
core14.0
tce
tce64
core13.1
tce
tce64...
/lost+found
/music
/photos
/ebooks
/videos
I also have /opt/bootsync.sh set up to symlink the current tce directory as /tce and a few other similar (symilar?) symlinks for convenience.
-
Well I still write them to CDs. You could include all the functionality of your disk image in a dd-able ISO anyway, catering for the likes of me as well. Dual BIOS/UEFI booting is possible with dd-written ISOs, though it took me quite a while to figure out how to set that up right.
CDs are rather expensive toys nowadays :-) What is CD/USBflash exchange rate in Your country?
When I bought a bulk pack years ago, about $0.15 per disc. Since then I've picked up packs at second-hand stores and garage sales for $0 - $2 (yes, some are giving them away). Unfortunately most distros don't fit on a CD anymore, and DVDs are painfully slow. Then again one DVD's worth of data is all my monthly internet data allowance, so I rarely go to the trouble of downloading those at a free Wi-Fi location anyway.
USB drives are about a minimum of $6 if you wait all year for the best specials. On a regular day $10 - $15 at the cheaper stores. If one wants to keep a few distros/rescue-discs, CDs still look way cheaper than eg. 10x USB drives. But I do also keep all the ISOs on a USB HDD to avoid needing to waste internet data re-downloading them if a disc gets wrecked, so with one of these multi-boot systems I could probably use that for booting computers itself. I can't be bothered with that though.
The USB HDD cost me around $80 in around 2013, so I could have bought 533 CD-Rs instead. CDs probably are more expensive now, but not that much.
In fact almost every ISO found itself written to some kind of flash drive.
Perhaps. My point is that you can either cater for the possibly exceptional people like me or not. It's harder to make ISOs, but you don't have to sacrifice features for USB-drive users in order to do so. Like publishing a custom distro image for others in the first place, it just depends on whether you want to make the effort (I think a total of one other person used the TC-based ISO that I made, after I did a full day's compatibility testing with CDs and USBs :( ).
-
Hi CNK!
Of course talking about media we should take into consideration the capacity. So the price per GB matters. I think it is correct approach, if we use these toys to store some data :-)
In our country now best quality CDs cost around $0.30, the cheap ones $0.15. For $5 You can by 32GB flash drive. So for flash memory we got 5/32=0.15625 $/GB. For CDs we got 0.15/0.7=0.2143 in the cheapest case. Interesting that DVDs price is almost equal to CDs. Are they really so slow that someone may choose CD over DVD?
External HDD cost less than 50$ for 1TB and we got 50/1000=0.05 $/GB. Conclusions are obvious. Encountering that HDD is hundred times handier and smaller :-)
-
Of course talking about media we should take into consideration the capacity. So the price per GB matters.
Not for me, because as I said I don't want to mess around with multi-boot things like Ventoy, so for 10x CD ISOs the choice is either 10x CDs or 10x USB drives for me. I like the simplicity of picking out a CD and have it boot straight up, compared to messing about with extra boot steps. I'm not trying to convert you to CDs, but just pointing out why I personally wouldn't use a disk image release instead of an ISO.
Interesting that DVDs price is almost equal to CDs. Are they really so slow that someone may choose CD over DVD?
I do. Booting a big Linux distro from DVD takes ages compared with CD, and burning takes even more ages.
-
Hi CNK!
I'm not trying to convert you to CDs, but just pointing out why I personally wouldn't use a disk image release instead of an ISO.
InstantCore is proposed for new users, not for an experienced ones. One-touch all-in-one full-functional dual-boot BIOS/UEFI USB flash drive and then if necessary one-touch install to the local drive.
-
InstantCore is proposed for new users, not for an experienced ones.
All that I said applied to me the first time I tried Tiny Core. I also mentioned that Puppy Linux adopting disk images instead of ISOs would dissuade me from trying that again.
But my point is only that ISOs still serve a purpose for some potential new users who are like me, which is what you originally asked about. Whether you accomodate those people or not is up to you.
-
But my point is only that ISOs still serve a purpose for some potential new users who are like me, which is what you originally asked about. Whether you accomodate those people or not is up to you.
How am I to accommodate? Offical ISOs can be downloaded form http://tinycorelinux.net/downloads.html, aren't they?
-
How am I to accommodate? Offical ISOs can be downloaded form http://tinycorelinux.net/downloads.html, aren't they?
I mean accomodate CD users with your InstantCore release by using (dd-able) ISOs for them.
Or actually you originally asked:
Why, damn, OSes in general and TinyCore especially are not distributed in the form of really alive filesystems?
So I thought you were asking why Tiny Core shouldn't use disk images instead of ISOs for the official releases too.
Either way, I've said all I care to say about that now.
-
Hi CNK!
InstantCore is not a kind of my release, it is compilation of official CorePlus-14.0 and TinyCorePure64-14.0 - talking about the content of the present InstantCore.img. My contributions are grub.cfg (3 kB) and inflate.sh (1 kB). The cornerstone is grub2 incorporated into the drive image according to an excellent Juanito's dual boot BIOS/UEFI HOWTO: http://forum.tinycorelinux.net/index.php/topic,19364.0.html.
So I propose to use "InstantCore" term for any image of the live drive with grub2 installed in the dual boot mode accordingly to the above mentioned HOWTO. In my case I used the grub.cfg I use by myself, as reliable and convenient, and applied it to the official ISOs content. One can change the grub.cfg and content to his/her taste and get the same-featured InstantCore image, which can be written into any USB flash drive or local drive and instantly obtain full-functional TinyCore system.
I mean accomodate CD users with your InstantCore release by using (dd-able) ISOs for them.
So I thought you were asking why Tiny Core shouldn't use disk images instead of ISOs for the official releases too.
CD users shouldn't pay attention to the InstantCore approach. They can download official ISOs and be sure they've missed nothing.
-
Warning for new users!
Current InstantCore.img is based on the official CorePlus-14.0-iso and TinyCorePure64-14.0.iso.
Some important updates were applied recently to some extensions in the repos. The current 14.x repo structure is not fully consistent and in case You will download some extensions (i.e. mc.tcz) You need to perform certain sequence of maintenance commands:
tce-audit builddb
tce-audit updatedeps
tce-audit fetchmissing
tce-update
before installing them.
But! The last "tce-update" command demands too much free disk space, than it is accessible inside the original InstantCore.img and may be performed only after Your system will gain the access to the full USB drive room, which can be done choosing "base+resize" boot menu option and then running:
inflate.sh
sudo reboot
So if You will (undoubtedly) want to load new extensions, the please:
1. Boot into "base+resize"
2. inflate.sh
3.sudo reboot
4. After downloading (and before installing!) of any extensions please run
tce-audit builddb
tce-audit updatedeps
tce-audit fetchmissing
tce-update
5. Reboot
Sorry for inconveniences, will hope that in the new year and new TC versions things will become less complicated.
Congrats with upcoming holiday!
-
Unfortunately even proposed maintenance sequence is not able to resolve all inconsistencies between extensions present in CorePlus-14.0.iso and the current repo state.
Sorry, in its present state InstantCore.img must not be recommended for new users, due to incompatibilities with repo state.
-
@newbieCore: I'm glad to hear you've made it into the MMC (turning off CSM) - three entire pages of forum comments since my last visit :)
@newbieCore, You may try writing an image from http://forum.tinycorelinux.net/index.php/topic,26658.0.html this thread to /dev/mmcblk0 with the help of dd utility:
sudo dd if=InstantCore.img of=/dev/mmcblk0 bs=4M
It contains ready to use dual boot BIOS/UEFI filesystems with CorePlus14 and TinyCorePure64. If the case is UEFI, it may help. Just to try with low expectations.
@jazzbiker: Please refrain from up-selling third party custom releases of Tiny Core Linux on the Tiny Core Linux forum (such as your "Instant Core" as you've named it); this forum is focused on the content found strictly within repo.tinycorelinux.net; when you create your own custom "version" of TinyCore and make changes to how our packages install and/or operate, it makes it difficult, if not impossible for us to "support" end users as this now falls on your lap - and preferably your website and domain. Please understand, also, that we have no way to babysit every package that has ever been created by users; thus we have no way to ascertain whether or not "Instant Core" is properly functional, or whether it's infested with errors, virus' or trojans, etc. (Not saying you would -- but we have no way to prove that to users like @newbieCore and we cannot be held liable for malicious damages.)
@Rich, @curaga, @Paul_123: Need your $0.02 here.
might be nice to have a copy of that here as well...
-
One more great post!
@jazzbiker, @newbieCore: YES, by all means! (sorry, more than one word!)
I see that communicating with @newbieCore I am violating something I don' t understand.
NO, communication isn't a problem in the least.
Actively promoting a remaster ON the forum as a replacement for the Tiny Core Linux project can become a problem, which I hope you understand why.
Let's say the next X number of people to stop by find your link and install your remaster instead of the real Core project... and let's imply there are problems... who do you think THEY will expect support from?
You? Or the development and maintenance team from Tiny Core Linux which is what's at the top of the website they're looking at?
"I'm sorry, sir... the release you installed is not supported..." "...What do you mean it's not supported, I got it FROM you people - see, it's right here on your forum!!"
It doesn't end well.
Suggestion 1: If you feel strongly that your remaster is superior in any way, put together a website (there's plenty of free hosting services out there, so it doesn't even cost you anything) and describe your remaster accordingly; leave note on the site indicating it's not a TCL release, but instead an "awesome custom remaster" (how ever you want it worded) but that it's not affiliated with the Tiny Core Linux project AND offer your own contact information for if/when someone runs into trouble. Avoid creating links to this forum - it's an SEO nightmare. Instead, you're welcome to create links such as "...for more information on the Tiny Core Linux project, click here (http://www.tinycorelinux.net)" -- that sort of direction, as long as you're not pretending to BE Tiny Core Linux or otherwise directly associated.
Return here to the initial thread you created regarding its release and update that thread with your website's URL. In doing so, you cover the necessary bases and you've made it perfectly clear to someone downloading it that this is your project (a PORT of Tiny Core, so to speak.) As long as the remaster still maintains the forum requirements (ie: spamming, marketing, abuse, piracy - all those types of issues) I don't mind in the least that you try to help people out using it -- as long as they are aware that it's your remaster... up front.
LEGALLY speaking, website and other similar trade-marked or identification based graphics should not be reused on third party websites without expressed, written permission... blah... blah... you'll want to come up with a fresh new look for "Instant Core" anyway.
Suggestion 2: If you really want to maintain a port of this project, here's a recommendation that works in your favor by limiting the amount of work that has to go into it:
- Download and extract the full TinyCore package that suits what you're building from
- Take all the files you've altered/created/etc. and create instant.gz (CPIO)
- Update extlinux.conf: APPEND: /boot/core.gz,/boot/instant.gz
- Repackage and upload to Google Drive
If you do things in this fashion, people can separate your work from TCL, verify core.gz is in fact untouched and if they wanted to check to ensure your efforts were clean and genuine, a look inside instant.gz makes it easy to do (without having to scan/scour a modified core.gz or root/modules.gz) Also, when there's a new release (15.x for example) your "upgrade" is tremendously simple by merely updating extlinux.conf's APPEND line and repackaging.
might be nice to have a copy of that here as well...
I'm sure it deserves to be pinned in the Unofficial Remixes board ;-)