Tiny Core Linux
Tiny Core Base => TCB News => Release Candidate Testing => Topic started by: roberts on January 17, 2010, 09:03:11 AM
-
The Third Release Candidate of v2.8 (tinycore_2.8rc3.iso), is now posted and ready for testing.
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/2.x/release_candidates
tinycore_2.8rc3.iso
tinycore_2.8rc3.iso.md5.txt
Change log for Tiny Core v2.8
rc1:
* Updated tce-load to allow miltiple loading, e.g., tce-load -i *.tcz
* Updated tce-load to drop ".tcz" requirement.
* Updated appsaudit to allow selective removal of items from "marked for deletion"
* Updated appsaudit to allow operation in tce directory as well as tce/optional directory, use File option.
* Updated appsaudit menu for smoother operation.
* Updated cd_dvd_symlinks.sh for better multiple cd and dvd devices.
* Cleanup of tce-setup & tce-update of l,m,lm, and ml code.
* Updated tce-fetch.sh to cleanup old dual repository support.
* Updated tce-update to prompt before beginning easy mode batch update operation.
* After much Team testing and input, the upx'ed kernel returns, prior kernel is in distribution files.
* Dropped symlinker by using builtin cp construct.
* Dropped GNU ftp from base.
rc2:
* Updated tce-update for selective interaction via CLI options "query", "list", and "update".
* Major updates to appsaudit including new "Updates" menu option to "check for updates and selectively update wired into the tce-update options.
* Updated and reorganized cpanel, added "TCE Update", "USB Install", "Run Command", "Xkill", and "Xvesa Setup"
* Dropped dropbearmulti from base.
* Updated appbrowser cleanup of l,m,lm,ml code.
* Updated rc.shutdown by reverse umount loops to support tcvd virtual drive.
rc3
This release candidate changes the storage of extensions to a single location, the optional directory located under your "tce" directory. Boot time loading of application extensions are provided by links into the optional directory. These links are easily maintained with the new OnBoot section of appsaudit. This will better support the trend to use more "OnDemand" items, make it easy to "move" applicatons into and out of the "OnBoot", tce, directory. This also greatly improves systems resources by having a single copy of dependencies. Having a single area to host all extensions & dependencies also greatly improves auditing and both batch and selective updating.
* Updated FLTK to v1.1.10.
* Updated FLWM with more traditional close button layout.
* Updated appbrowser to support new extension support structure.
* Updated appsaudit - new menu section OnBoot.
* Updated tce-setup, tce-load, and tce-audit to support new extension support structure.
* Updated 'ab' shell appbrowser for more consistent input handling.
* Updated udev rules for much quicker boot times with loop mount extensions.
* Updated rebuildfstab for faster response.
* Updated filetool.sh to ignore sockets.
* Updated tc-terminal-server typo.
* Standard kernel returns with upx'd kernel available in the distribution file area.
Notes:
For tiny core users to move to the new structure perform the following:
* boot base norestore
* mv your_tce_dir/*.tcz* optional/.
* appsaudit -> OnBoot
Select only those apps that you wish to have loaded upon boot.
Do not select dependencies, they will load from optional.
Your "tce" directory should have very few link items for your selected boot time apps.
Easy to change your mind using appsaudit OnBoot as
Left hand side panel selects item and creates link in "tce" dir
Right hand side panel deletes link from "tce" dir
Rebooting then loads items as selected.
We now have a single directory from which to audit dependencies, perform selective updates, and pick and choose our on boot selection of applications.
-
Is kernel still UPX'd?
EDIT by roberts: I added mention of the return to standard kernel to the change log.
-
Hi Robert,
great news (the new extension storage structure). This is very much in line with a prototype a made last week.
I guess that if you are working with different system configurations, i.e. different sets of installed applications, you could create meta-packages that represents these sets (the .dep file lists the applications to be included) and then you just select one of these metapackages as OnBoot?
Is the boot time loading of extensions fully recursive? The prototype I made is fully recursive and it works very well.
A tip for users that have the repo synced to their system is to place the repo copy at tce/optional, i.e. no need for an extra copy and always the most up to date version available (if the repo is synced).
Thanks
Lars
-
Is kernel still UPX'd?
No standard kernel in the iso. The upx'd kernel is available in the distribution files download area.
-
Hi Robert,
great news (the new extension storage structure). This is very much in line with a prototype a made last week.
I guess that if you are working with different system configurations, i.e. different sets of installed applications, you could create meta-packages that represents these sets (the .dep file lists the applications to be included) and then you just select one of these metapackages as OnBoot?
Is the boot time loading of extensions fully recursive? The prototype I made is fully recursive and it works very well.
A tip for users that have the repo synced to their system is to place the repo copy at tce/optional, i.e. no need for an extra copy and always the most up to date version available (if the repo is synced).
Thanks
Lars
Dependency loading has not changed except for the new single location as specified in the change log.
-
Would you consider a fully recursive load, both at boot and when installing via appbrowser, in the future? It would simplify creation and maintenance of .dep files.
/Lars
-
Although I don't see any impending need, sure. For consideration email me.
-
Great work Robert and team tinycore. I'll start testing this release today.
-
I noticed there's still an ftp indicator in the tool panel. Is this correct? I thought ftp was dropped from the base.
Also, any progress on the dropbear extension?
-
Just out of curiosity does "tce2tcz.sh" still work?
-
Regarding tce-load usage:
# Example usage:
# tce-load -i /mnt/hda1/tce/optional/nano.tcz Loads local extension
# tce-load -w -i nano.tcz Download into tce/optional directory, links for OnBoot and installs
# tce-load -w nano.tcz Download only into tce/optional directory
I'm a little confused just what options cause the "boot link" to be created in /tce ? Are both -w and -i required?
Could a little more explanation be provided.
-
Could a few of the more complicated usage examples be provided for the tce-audit command.
Usage tce-audit: {builddb|dependson|requiredby|nodepends|audit|auditall|delete|marked} extname
-
Could a little more explanation be provided for tce-update easy mode and inplace batch mode.
# If not interactive then check for easy mode or inplace batch update
-
Is tce-setup used by anything other than tc-config ?
-
I noticed there's still an ftp indicator in the tool panel. Is this correct? I thought ftp was dropped from the base.
Also, any progress on the dropbear extension?
ftp was dropped. Where is ftp shown? AFAIK, not shown when booted base norestore. What window manager are you using?
-
Regarding tce-load usage:
# Example usage:
# tce-load -i /mnt/hda1/tce/optional/nano.tcz Loads local extension
# tce-load -w -i nano.tcz Download into tce/optional directory, links for OnBoot and installs
# tce-load -w nano.tcz Download only into tce/optional directory
I'm a little confused just what options cause the "boot link" to be created in /tce ? Are both -w and -i required?
Could a little more explanation be provided.
Operationally the same combination of flags.
-w only = download only
-i only = loads local from specified path
-w -i = downloads and sets up link for on boot.
-
I noticed there's still an ftp indicator in the tool panel. Is this correct? I thought ftp was dropped from the base.
Also, any progress on the dropbear extension?
ftp was dropped. Where is ftp shown? AFAIK, not shown when booted base norestore. What window manager are you using?
I booted from cd iso. I'll try again with base norestore.
If you are talking about control panel tftp server, that is still available.
-
Could a little more explanation be provided for tce-update easy mode and inplace batch mode.
# If not interactive then check for easy mode or inplace batch update
easy mode and inplace mode are not new in this RC. Both are batch updates.
easy mode checks disk space available for update of all extensions, if so, creates an upgrade folder and updates download into upgrade folder, upon boot upgrade is completed before loading of extensions.
In place mode, is for smaller devices, e.g., a small pendrive, here each extension to be updated is downloaded into /tmp, md5 checked, then moved to replace existing extension.
Interactive mode is intended solely for calls from appsaudit.
-
Could a few of the more complicated usage examples be provided for the tce-audit command.
Usage tce-audit: {builddb|dependson|requiredby|nodepends|audit|auditall|delete|marked} extname
To build the database of dependices you need to specify dir, e.g.:
tce-audit builddb /mnt/hda2/tce/optional
To check for missing denpendencies on all extensions you need to specify a dir, e.g.:
tce-audit auditall /mnt/hda2/tce/optional
To display all extensions that have no dependencies you need to specify a dir, e.g.:
tce-audit nodepends /mnt/hda2/tce/optional
For all other reports use the full path, e.g.:
tce-audit requiredby /mnt/hda2/tce/optional/webkit.tcz
tce-audit dependson /mnt/hda2/tce/optional/midori.tcz
It is much easier to use appsaudit which loads up the path and makes selecting and reporting via the GUI very nice.
Of course using shell's edit capability of 'up arrorw' and 'tab completion' makes the cli easy as well.
-
Just out of curiosity does "tce2tcz.sh" still work?
I will remove it.
-
I noticed there's still an ftp indicator in the tool panel. Is this correct? I thought ftp was dropped from the base.
Also, any progress on the dropbear extension?
ftp was dropped. Where is ftp shown? AFAIK, not shown when booted base norestore. What window manager are you using?
I booted from cd iso. I'll try again with base norestore.
If you are talking about control panel tftp server, that is still available.
Yes, that is what I was referring to. So was the ftp that was removed only the client side ftp program or something else?
-
Sorry to keep pestering you guys.
I don't quite get how the Install Optional submenu item "Toggle Default Copy Install" works in the panel tool.
Could someone explain this?
-
Sorry to keep pestering you guys.
I don't quite get how the Install Optional submenu item "Toggle Default Copy Install" works in the panel tool.
Could someone explain this?
This again is not new in this RC.
It toggles copy2fs.flg
If this flag is set all extension are copied to filesystem instead of mounted.
-
I noticed there's still an ftp indicator in the tool panel. Is this correct? I thought ftp was dropped from the base.
Also, any progress on the dropbear extension?
ftp was dropped. Where is ftp shown? AFAIK, not shown when booted base norestore. What window manager are you using?
I booted from cd iso. I'll try again with base norestore.
If you are talking about control panel tftp server, that is still available.
Yes, that is what I was referring to. So was the ftp that was removed only the client side ftp program or something else?
ftp client was removed.
tftpd a busybox applet is used for tc-terminal-server and it remains.
-
dropbear.tcz posted.
-
dropbear.tcz posted.
Thank you.
-
AppsAudit OnBoot does not seem to be doing anything. I moved all the extensions to /optional, rebooted, opened AppsAudit and selected OnBoot from the menu.
On the left I see all the extensions in /optional, on the right the OnBoot box which is empty.
So how do I proceed from here? Clicking on extensions in the left pane did not do anything.
-
On what device is your tce directory? What is the file system hosting this directory?
-
I booted off the rc3 .iso, and used the USB install function to format and install tc on a usb device. I manually copied extensions to the usb device over from another partition.
So I guess the file system is whatever the USB install function creates. Can't check right now.
-
I booted off the rc3 .iso, and used the USB install function to format and install tc on a usb device. I manually copied extensions to the usb device over from another partition.
So I guess the file system is whatever the USB install function creates. Can't check right now.
I noticed that OnBoot creates/removes symlinks, at least on my ext2 based tce-directory. If you are using a FAT file system on the USB that would not support symlinks, so it could be that the OnBoot functionality does not work on FAT formatted volumes. I have not explored the code so I do not know if OnBoot is supported with FAT volumes.
/Lars
-
Fat filesystems as previously discussed, do not fully support *nix features.
If you insist on using such a file system then setup a virtual disk ( tcvd ) that will support *nix.
It is possible to use a unetbootin vfat pendrive with a tcvd hosting a tce directory.
-
But but but I DIDN'T choose fat... I just used the usb inbstall function that comes with tc! You insist on lecturing me on fat but effectively YOU chose fat. I didn't see anywhere the procedure gave me any choice. In fact that usb device WAS formatted with ext3 BEFORE I used your procedure. >:(
So after this, I ignored what's in core, used gparted to reformat the usb device with ext3 and set it up myself and then it worked. So I guess you have some work to do to fix usbinstall in tc.
-
On he first screen of the USB install tool you select the file system to use. If you used that tool you must have made an active selection, or am I missing something here ?
/Lars
-
helander, I can't figure it out either as the opening usbinstall screen shows:
===================================================================
Tiny Core pendrive BIOS boot installation/update.
HDD
* Your BIOS must support USB-HDD booting.
* A single FAT partition will be made.
ZIP
* Your pendrive will be formatted into two partitions.
* One small one for USB_ZIP boot compatibility, and used to hold Tiny Core.
* The remaining partition will be used for backup & extensions.
EXT
* Your BIOS must support USB-HDD booting.
* A single EXT2 partition will be made.
Use USB Boot type [H]DD, [Z]ip, [E]xt. (h/z/e):
==================================================================
You do have to make an active selection and selecting e
will automatically format and setup an ext2 pendrive.
@jur, your right. There is still some work to do. But this is a release candidate, as such it is to be considered still 'in progress'. Release Candidates are open public testing.
I have since posted that "I am cutting the FAT" from the usbinstall script.
Thus the usbinstall script will only support ext file systems.
-
I see. That opening screen's clarity is lacking somewhat... it always puzzled me what the various choices meant... So I would look at the choices, figure by a process of elimination what must be the right one (ZIP drive? Nope. EXT drive? Nope, whatever that is, never heard of an EXT drive. Must be HDD.).
-
:facepalm:
Back on topic, I installed 2.8rc3 in a Fujitsu Siemens and it works like a charm.
The idea about using .dep files instead of symlinks is worth considering, IMHO. Downside is TCZ repo would be implied instead of refered directly.
Upside is that it would create and load something like 'bare.dep' as default, and provide room for future dialog at boot time if more than a personal .dep file us there, like 'vm.dep', 'webserver.dep', 'workstation.dep' and so on.
I am suggesting only, in fact I don't like 'bare.dep' because it would be easily confused with 'base'.
-
I have since posted that "I am cutting the FAT" from the usbinstall script.
Thus the usbinstall script will only support ext file systems.
So to make this perfectly clear unlike in the past the tce directory must now be in a *nix ext2/3 partition. I assume the "boot" directory can still be in a fat or ext2/3 partition. Do I have this right?
-
I know Robert wants to get rid of vfat support, but for those of you who had rc2 on a fat fs, and now
have problems because of no symlinks, I have a solution.
Symlinks are not an issue.
tce-setup only looks at the filenames in tce.
Instead of symlinks, you can use touch to create a 0 length file in tce of the same name.
Perhaps Robert could change the symlinks into 0 length files to eliminate this issue.
Perhaps eliminating vfat is a better solution.
-
I know Robert wants to get rid of vfat support, but for those of you who had rc2 on a fat fs, and now
have problems because of no symlinks, I have a solution.
Symlinks are not an issue.
tce-setup only looks at the filenames in tce.
Instead of symlinks, you can use touch to create a 0 length file in tce of the same name.
Perhaps Robert could change the symlinks into 0 length files to eliminate this issue.
Perhaps eliminating vfat is a better solution.
This does not solve the "tce-load -w -i" or app browser created sym links. eh?
-
To state that you know I want to get rid of vfat support then subvert the effort that was a Team decisions and not mine alone is not really helpful.
Users trying to place persistent home and/or persistent opt on vfat are just some of the reasons for our collective decision.
If fact a zero length file was considered and rejected. Why hold back *nix capabilities supporting an acient and easily corruptable Windows file system!
-
I'm not trying to subvert anything.
I just pointed out a solution for someone who may have tried to update their tc or mc on their vfat filesystem and suddenly found it no longer worked.
I was not advocating that new installations use vfat.
I did not even say that I thought that it was a good Idea to continue using vfat on an existing drive.
In fact I said "Perhaps eliminating vfat is a better solution."
-
My PC can't boot from USB, but if I use the usb installation tool and select ext2 format, I should be able to just use the tce directory the tool creates on the usb stick, right?
-
On the topic of the USB install script, I have two thoughts:
1) I perfectly understand and fully support ditching support for FAT. But the simple truth is some people do still want to use FAT, despite all the problems it would cause for TC. Perhaps an acceptable compromise between "Must have FAT support!" and FAT not playing well with linux would be to update the FAT install option to force it to create and use a tcvd?
2) Is usbinstall an appropriate name for this script, even? The ext option installs fine and boots fine from a normal hard drive, after all.
RC3 is looking very good so far! Will be watching this one closely. =)
-
My PC can't boot from USB, but if I use the usb installation tool and select ext2 format, I should be able to just use the tce directory the tool creates on the usb stick, right?
Yes
The installation process is very simple.
-
To state that you know I want to get rid of vfat support then subvert the effort that was a Team decisions and not mine alone is not really helpful.
Users trying to place persistent home and/or persistent opt on vfat are just some of the reasons for our collective decision.
If fact a zero length file was considered and rejected. Why hold back *nix capabilities supporting an acient and easily corruptable Windows file system!
I agree with "persistent home and/or persistent opt on vfat" problems. However I did like the convenience of being able to have a tce directory on a usb stick that was portable and compatible with my windows systems. However, I have ended up with my /tce directory located in an ext3 partition so it's no big deal to me.
Robert, you and the tc team have done a brilliant job transitioning the extension system to what it is today. I do have what might be a dumb question and observation? It looks to me as a humble observer that /tce/optional has become /tce and the copy to file system flag, copy to file system list, and boot file links could all be reduced to one text file with a list of boot extensions where each entry has a flag to denote copy to file system. It's just a thought.
-
So to make this perfectly clear unlike in the past the tce directory must now be in a *nix ext2/3 partition. I assume the "boot" directory can still be in a fat or ext2/3 partition. Do I have this right?
Yes.
-
Hello Y'all in The Tiny Core Team!
You have done a wonderful job with this new version of tiny core. I'm constantly surprised of the many good functions that have been adapted to tiny core. Many times I have thought that now there aren't many big improvements that can be done, it's as good as perfect. But you have proven me wrong but I don't mind. Many thanks!
Have fun and keep on surprising me,
meo
-
Is usbinstall an appropriate name for this script, even? The ext option installs fine and boots fine from a normal hard drive, after all.
While true, I have used it that way, even on SSDs. However, WARNING DANGER it wipes out the entire drive. Hence my caution to label it for use on a pendrive.
Perhaps I will make a link to an have an additional name for those who wish to use it on hard drives / SSDs, etc..
-
I have since posted that "I am cutting the FAT" from the usbinstall script.
Thus the usbinstall script will only support ext file systems.
With no intent to influence the decisions made on usb install I just want to mention the following considerations:
1. Eliminating Zip emulation means most older machines will no longer able to boot from usb. Zip emulation has been the best bet since in old times PC BIOS supported booting from Zip. For some other PCs HDD emulation worked and no others. By eliminating these choces and using only Ext, means many such PCs will no longer able to boot. USB install in TC is excellent in design as it gives these choces to enhance chance of bootability.
2. Zip emulation in TC usb install beautifully partitions the usb drive in 16M partition, where it puts tc core and separates extensions in the second partition. EXT options creates a single partition where all is mixed together. If going forward only EXT option will be used, I suggest that usb install partitions the usb drive in similar way as Zip option was doing, separating TC core in a small partition from the rest. This enhances integrity of the system.
If the new usbinstall does not partition the usb to separate TC core and all is mixed in one partition, then I suggest to do it manually using Gpartes and create additional partitions on the usb stick, such as FAT32. For this usb stick needs to be in HD mode.
3. In a way TC usbinstall is superior to Unetbootin in that it supports usb flash drives configured as HD drives. Unetbootin does not understand this important configuration. Since the tremendous advantage of using usb flash sticks configured as usb HD drives is hard to beat, I hope after change planned for usbinstall this capability is continued, that means usbinstall will continue to recognize and accept usb flash configured as HD drives. If this capability is lost, then it will be harder to use for TC usb sticks larger than 1 or 2 GB.
-
Hi. Really great job with 2.8!!!
Would it be possible to post the ftp cli client that was previously part of the core as a tc extension?
-
All of the inetutils clients will come in the future; unlike with dropbear, there have been updates since.
-
Just a friendly reminder, release candidates are for public preview and testing only.
Anything can change based on public input before final release or next release candidate.
As such, one should not use release candidates as their primary system.
Thank you for your participation in testing and feedback.
-
After reflecting on feedback from both microcore and tinycore topic areas, regarding both the .core.gz/initramfs change and the vfat/symlinks change.
Here is what I done:
1. Drop symlinks and use a simple text file, onboot.lst, for determining which to load on boot. I have modified tce-load, tce-setup, and appsaudit.
2. Add a new boot code lst=mylist.lst. This will skip the onboot.lst and load up only that which is in mylist.lst I have modified tce-setup.
This should satisfy microcore users that need to 'preload' special extensions, keyboard, etc...,
then after boot can run tce-setup to get full X with onboot specified extensions.
3. Update tc-config to ensure persistent home and/or persistent opt is on a supported Linux file system. If not such boot code(s) will be ignored. I have modified tc-config.
4. Leave usbinstall script as is. Fat support not cut. onboot.lst being a simple text file should present no issues hosted on fat file system.
I feel this will solve most issues and concerns expressed from the combined microcore and tinycore communities' feedback, while also providing even greater flexibility moving forward.
I have coded these changes and am in early testing phase. As such, I will issue a release candidate 4.
Robert
-
Interesting, that now for the 2nd time, tcl direction is changing to align almost exactly with how I have been using it. I changed my setup to on-demand quite a few releases ago, tcl 2.8 has gone there. Now with rc3, I have been using my own onboot file instead of symlinks, tcl is going there also. ;D
In my mind there is no doubt, tcl is unbeatable. Thanks very much Robert and the team.
-
Jur - this is where contribution and experience of others helps roberts to decide the best strategy.
-
After reflecting on feedback from both microcore and tinycore topic areas, regarding both the .core.gz/initramfs change and the vfat/symlinks change.
Here is what I done:
1. Drop symlinks and use a simple text file, onboot.lst, for determining which to load on boot. I have modified tce-load, tce-setup, and appsaudit.
2. Add a new boot code lst=mylist.lst. This will skip the onboot.lst and load up only that which is in mylist.lst I have modified tce-setup.
This should satisfy microcore users that need to 'preload' special extensions, keyboard, etc...,
then after boot can run tce-setup to get full X with onboot specified extensions.
3. Update tc-config to ensure persistent home and/or persistent opt is on a supported Linux file system. If not such boot code(s) will be ignored. I have modified tc-config.
4. Leave usbinstall script as is. Fat support not cut. onboot.lst being a simple text file should present no issues hosted on fat file system.
I feel this will solve most issues and concerns expressed from the combined microcore and tinycore communities' feedback, while also providing even greater flexibility moving forward.
I have coded these changes and am in early testing phase. As such, I will issue a release candidate 4.
Robert
Thank you Robert for the advanced information. The proposed changes will make for a better and simpler system.
Should we assume that the copy to file system flag and list operation will be unchanged? Will they be located in the boot list or /tce directory.
Perhaps it's too soon for yet another change but it seems that after implementing your proposed changes there really is no such thing as optional extensions. What we end up with is simply a local extension repository that is used for on demand or boot extension installations. The system is becoming even more simple that the original tc. Fantastic!
-
Copy to file system works the same. I would rather keep it a separate function from selecting a few on boot, or on demand extensions.