Tiny Core Linux
Tiny Core Base => TCB News => Release Candidate Testing => Topic started by: Juanito on April 25, 2015, 11:42:39 PM
-
Team Tiny Core is pleased to announce that Tiny Core 6.2 rc2 is available for public testing:
http://repo.tinycorelinux.net/6.x/x86/release_candidates/
http://repo.tinycorelinux.net/6.x/x86_64/release_candidates/
This is a release candidate. If you decide to help test, then please test carefully. We don't want anyone to lose data.
We appreciate testing and feedback.
Changelog for 6.2 rc2:
* tce-audit: similar speedup patch from aswjh
* tc-config: nfs4 mount changes from gerald_clark
* tce-load: 2% speedup from aswjh
Changelog for 6.2 rc1:
* tce-size: apply patch from Greg Erskine for no-deps files
* tce-remove, rc.shutdown: update copy2fs name
* tce-ab: convert to a symlink
* tce-load: awk recursion changes changed to a subshell, so exit status needs to be passed
* tce-setup: wait for slow CD drives
-
Hi Juanito!
Will try ASAP. On a train at the moment trying out the last debian Jessie KDE. Works fine by the way.
Keep up the good work,
meo
-
Newbie question here:
I first tried the 64 bit versions CorePure and TinyCorePure 6.2rc2 and discovered an odd behavior -- due to my ignorance.
Both spit out a long list of basic command errors -- on 'cp' 'chown' ... etc. and then halted with not being able to find 'fluxbox'
Turns out it was trying to load my hard drive installed version of the home directory (defaults to fluxbox). i gather this is the
normal default behavior. Problem was my current hard drive install uses 32 bit.. Purpose of the test to me was to see about
moving to 64 bi version.
So how do I test a 64 bit release candidate?? My kludge was to come up in another OS and rename the tce/ directory -- worked
but is there a better way???
-
Home shouldn't matter since you should not be installing any binaries there.
You need to have a separate tce directory though.
-
Not true. The purpose of the system is to test and write new programs .. its a continuing ongoing activity.
There is no practical way to isolate the code that way -- not in early stages. Once finalized its different.
This issue doesn't arrive except in this odd case of dual use of a 64 bit system running 32 bit as well.
I'll give it some thought. I do a a kludge for the moment.
-
Just do your development in another directory on your hard drive, not /home/tc.
-
A thought -- but part of the testing requires setting up the environment -- which is started by the window manager.
Hummm ... I do have both 64 bit and 32 bit versions of the binaries, guess i could test for error and re-point to the proper
'bin' .. that might work. I think I'll give it a try.
-
Turns out I already had a general purpose 'make' facility for either 32 or 64 and with TC it doesn't take that long to re-compile.
So I simply, run the make at every new startup -- problem solved.
-
Thanks all for the new RC.
Just upgraded and have some feedback. Please note these items bugged me for a while and are not specifically related to v6.2rc2.
- Apps > Maintenance > Md5 Checking: Many users probably check their entire install, not just select extensions. Would be great if there was a select all checkbox and any problematic md5 checks were flagged in red or yellow text, rather than scrolling a long list of black and white OKs.
- Dependencies > Update .dep files: Painfully slow to update. Takes ~10 minutes to complete while Apps window blanks with hourglass cursor. Shouldn't this be completed within a few seconds or a minute? Conky shows <10% CPU usage (800MHz system), some network activity, good wired DSL connection, not performing any background tasks and system otherwise runs great. Optional folder has 409 files/120MB and OnDemand list 10 items. Apps window usually redraws itself when completed, otherwise Alt-Tab between applications redraws Apps window contents.
- Dependencies > Update .dep files: In addition to above, no dialogue output is provided upon completion, such as 'Dependencies check completed'.
- Dependencies > Build Reporting Database: Completes very quickly - did it do anything? Similar to above, no dialogue output is provided upon completion, such as 'Reporting Database Built'.
- Dependencies > Missing Dependencies Reporting: Also provides no dialogue output upon completion. Odd as Dependencies > Fetch Missing Dependencies ouputs 'Dependency check completed. No missing dependencies found'.
Thanks - take care.
-
Thanks all for the new RC.
Just upgraded and have some feedback. Please note these items bugged me for a while and are not specifically related to v6.2rc2.
- Apps > Maintenance > Md5 Checking: Many users probably check their entire install, not just select extensions. Would be great if there was a select all checkbox and any problematic md5 checks were flagged in red or yellow text, rather than scrolling a long list of black and white OKs.
For the longest time I too was doing this all wrong :( You are supposed to highlight any and/or all items to check
- Dependencies > Missing Dependencies Reporting: Also provides no dialogue output upon completion. Odd as Dependencies > Fetch Missing Dependencies ouputs 'Dependency check completed. No missing dependencies found'.
AFAIK It has always been this way, "Missing Dependencies Reporting" only reports if there are missing dep's.
-
Thanks for the response coreplayer2.
For the longest time I too was doing this all wrong :( You are supposed to highlight any and/or all items to check
I am aware of this thanks. The current system is, however, cumbersome when selecting all from a long scroll list. I am just suggesting an easier method to 'select all', which could be a select all checkbox, Ctrl-a keyboard shortcut or right-click 'select all' option.
AFAIK It has always been this way, "Missing Dependencies Reporting" only reports if there are missing dep's.
That doesn't mean the functionality shouldn't be enhanced. You're an experienced user and i'm looking at it with fresh eyes from a new user perspective. Apps inconsistent message output (and lack of) to a new user appears unpolished or worse yet broken.
To reiterate the example cited above:
- Dependencies > Missing Dependencies Reporting: Also provides no dialogue output upon completion. Odd as Dependencies > Fetch Missing Dependencies ouputs 'Dependency check completed. No missing dependencies found'.
Why should Missing Dependencies Reporting output nothing, especially since it's supposed to be reporting something, but Fetch Missing Dependencies ouput a completion message. Consistency would be appreciated from a new user trying to figure out the system.
Edit: Or maybe these two categories could be combined into one - 'check and fetch missing dependencies', although this would likely require more work under the hood. Is there ever a valid use case just to check but NOT install a missing dependency?
-
My kludge was to come up in another OS and rename the tce/ directory -- worked
but is there a better way?
You can use two directories - /tce and /tce64 for example - and switch between them with the "tce" boot code.
-
Hello guys!
Back home and have made a thorough test of this cut of TC (32 bit X version) including compiling the go language and all I have to say is; WELL DONE! ;)
Sincere Regards,
meo
-
Edit: Or maybe these two categories could be combined into one - 'check and fetch missing dependencies', although this would likely require more work under the hood. Is there ever a valid use case just to check but NOT install a missing dependency?
I think that's a bad idea if for some reason someone doesn't want a particular extension updated.
-
downloaded the Core Plus v6.2rc2 version and used live cd with AMD Phenom 64. Booted OK. Installed Firefox 21.X from repo. After install on boot all icons from wbar disappeared. After clicking control panel and wbar apply icons came back.
Same happened when I installed the next extension.
VLC media player still crashes due to missing dependency: libiconv.tcz. It still needs to be downloaded from the V5.X repo and put into /tce/optional
-
does this still happen if your firefox extension is not loaded?
As mentioned elsewhere the vlc recompile is in the maintainers task queue.
-
Since previously mentioned re wbar disappearing, after a full system update (dep's and extensions) I no longer experience this anomaly
I think it's safe to assume it is caused by outdated extensions
Sent from my iPhone using Tapatalk
-
- Apps > Maintenance > Md5 Checking: Many users probably check their entire install, not just select extensions. Would be great if there was a select all checkbox and any problematic md5 checks were flagged in red or yellow text, rather than scrolling a long list of black and white OKs.
- Dependencies > Update .dep files: Painfully slow to update. Takes ~10 minutes to complete while Apps window blanks with hourglass cursor. Shouldn't this be completed within a few seconds or a minute? Conky shows <10% CPU usage (800MHz system), some network activity, good wired DSL connection, not performing any background tasks and system otherwise runs great. Optional folder has 409 files/120MB and OnDemand list 10 items. Apps window usually redraws itself when completed, otherwise Alt-Tab between applications redraws Apps window contents.
Quick follow-up. All items noted in my earlier post remain with the exception of the following. Hope someone can address them either way - any feedback is appreciated.
Regarding the two items quoted above:
- Just noticed the subtle yellowish line and FAILED flag on a failed md5 - that's great thanks. Maybe just too subtle for my ageing eyes or maybe because i'm using Xvesa.
- Dependencies > Update .dep files ran quick for me today. Tested twice and only took ~45 seconds each trial. Not sure why so slow when i reported the issue earlier. If nobody else experiences this slowness then maybe just my system. My hardware is old, limited and had just finished compiling with numerous extensions loaded. Since the initial slowness issue, i've also removed several extensions (primarily Xorg related) but the optional folder is still 371 files, 120 MB.
New item, is this a security concern? Apps > md5 Checking loads all .tcz.md5.txt files but doesn't check to ensure all extensions have an associated md5.txt file. These extensions, therefore, never get flagged or md5 checked. This obviously occurs when extensions i've compiled are copied into optional without an md5.txt file. So in theory if someone gets into a system, swaps in a compromised .tcz extension and removes the md5.txt file, no one would be the wiser. Shouldn't Apps check, flag and report missing md5.txt files?
-
New item, is this a security concern? Apps > md5 Checking loads all .tcz.md5.txt files but doesn't check to ensure all extensions have an associated md5.txt file. These extensions, therefore, never get flagged or md5 checked.
For me this is a good way to avoid having personal extensions continually flagged - if they don't have an md5sum, then they are ignored.
-
Thanks for the response. Your point is understood but to me this issue is an oversight. Just wanted to report a potential exploit. If i knew how to program i would attempt a patch, reporting any optional folder .tcz extensions not associated with an md5.txt file, but i can't so up to you/developers whether it's worthy of addressing.
Given the choice, i typically prefer security over convenience. Probably not a big concern for the average home user, but maybe for kiosk operators, etc. Flagging missing md5.txt files wouldn't need to compromise the functionality of the .tcz extension, just ensure the end user is notified of a potential issue.
-
One can always add a check of the md5sum files to bootsync.sh.
However, once access is obtained, there is no security.
-
Thanks for the response. Your point is understood but to me this issue is an oversight. Just wanted to report a potential exploit. If i knew how to program i would attempt a patch, reporting any optional folder .tcz extensions not associated with an md5.txt file, but i can't so up to you/developers whether it's worthy of addressing.
I do not see why and how a missing md5 is imposing a security risk.
-
Core is a toolkit, not a distro.
You can add a simple script to md5sum the whole optional directory at boot.
If you can't, why are you using core instead of a distro targeted for the end user?
-
Tested install again. When I installed leafpad the wbar also disappeared. Then I brought back the wbar using the control panel and tcWbarConf --Apply.
Then installed Firefox and wbar was gone again. After installing several more extensions all of the sudden the wbar did not disappear after an install. Strange?
BTW: I was using CorePlus in cloud mode.
-
Given the choice, i typically prefer security over convenience. Probably not a big concern for the average home user, but maybe for kiosk operators, etc. Flagging missing md5.txt files wouldn't need to compromise the functionality of the .tcz extension, just ensure the end user is notified of a potential issue.
This is deliberate. At a minimum it's a means to prevent auto-update and accidental removal of modded or personal extensions. I do have a solution and have been using it for a year or more, just need to submit it (wasn't sure if anyone would be interested..).
-
Thanks for the reponses.
gerald_clark wrote:
One can always add a check of the md5sum files to bootsync.sh.
However, once access is obtained, there is no security.
An occasional manual md5sum check via Apps is good enough for me, but as outlined the check is only valid if the .tcz extension has an associated md5.txt file. So in that sense it is really only a partial and incomplete check. Why run a checker if it only performs a partial job. Of course once access is obtained security is compromised, but providing awareness of missing md5.txt files could help detect possible intrusion/corruption.
bmarkus wrote:
I do not see why and how a missing md5 is imposing a security risk.
Well to me the purpose of an md5 check is not only to confirm an accurate download, but also to help ensure there is no curruption in the system post-install, which could be secondary to a security violation. Does that not make sense?
gerald_clark wrote:
Core is a toolkit, not a distro.
You can add a simple script to md5sum the whole optional directory at boot.
If you can't, why are you using core instead of a distro targeted for the end user?
BusyBox is a toolkit, TinyCore is a distribution.
If not, maybe someone should notify distrowatch and update the TinyCore website:
About Our Project
Our goal is the creation of a nomadic ultra small graphical desktop operating system capable of booting from cdrom, pendrive, or frugally from a hard drive.
http://distro.ibiblio.org/tinycorelinux/
As already outlined, a simple script to md5sum check the optional directory at boot is futile if .tcz extensions in the optional folder are missing an associated md5.txt file. They don't get flagged or checked.
coreplayer2 wrote:
This is deliberate. At a minimum it's a means to prevent auto-update and accidental removal of modded or personal extensions. I do have a solution and have been using it for a year or more, just need to submit it (wasn't sure if anyone would be interested..).
Sorry i don't buy that, Apps > md5 Checking is not designed to update or remove any extensions, modded or personal, it's simply an automated way to complete an md5 check - no system changes. And in it's present state the md5 check is incomplete. Although i appear to be a minority, i would definitely be interested in your solution.
Still can't understand the resistance to flagging missing md5.txt files. How could incorporating this feature be a bad thing? Why should a user need to manually scroll through an optional folder to check for missing md5.txt files when a computer can check so much quicker and reliably.
-
Core Concepts
On behalf of the Tiny Core Team, welcome. Please take the time to read this document and understand the philosophies behind Tiny Core.
One quick user beware: Tiny Core is not a turn-key operating system. At least initially, almost all users will require internet access to the online repository.
--------------
Downloaded programs WILL have an md5 file.
There is nothing preventing you from keeping your own md5sum file of all the tcz files in the optional directory.
Then a simple md5sum -c command will verify all packages at boot.
Core is NOT a secure system. All security must be added by the user.
Once an outsider gains access, no program can be trusted. All the features you think would add security could be faked.
The installation from scratch concept of loading everything anew on each boot does allow you the ability to check the authenticity of your extensions,
but only if you keep the sums on separate storage. If you suspect an intrusion occurred, you would need to boot from a secured thumbdrive and verify the checksums on your persistent storage. Once verified, you could then do your normal boot.
-
Tested install again. When I installed leafpad the wbar also disappeared. Then I brought back the wbar using the control panel and tcWbarConf --Apply.
Then installed Firefox and wbar was gone again. After installing several more extensions all of the sudden the wbar did not disappear after an install. Strange?
BTW: I was using CorePlus in cloud mode.
I just downloaded CorePlus-6.2rc2.iso, burnt it to CD and booted from the CD using flwm classic.
Downloading and loading firefox and leafpad did not make wbar disappear for me...
-
The tinycorepure64 legacy-bios/(u)efi multiboot iso has been further slimmed down and is available here:
http://tinycorelinux.net/6.x/x86_64/release_candidates/TinyCorePure64_mb-6.2rc2.iso
The iso is now "only" 3.2mb bigger than the standard version (including 2.4mb of efi fonts).
Most, if not all, (u)efi boot machines appear to be able boot legacy-bios cd/dvd, but there may be advantages to using (u)efi boot:
* drivers may boot up in a faster mode (this was the case with the hd controller in my last laptop)
* there are less non-critical errors reported on boot (manufacturers giving priority to (u)efi boot)
* displays over 1024x768 work at native resolution with Xfbdev
..and this is an easy way to check if your machine will (u)efi boot...
Note that on my hardware with a usb cd/drive and uefi boot, it takes +/- 12s for anything to happen after selecting the tcw (tc waitusb) menu entry.
-
Tested install again. When I installed leafpad the wbar also disappeared. Then I brought back the wbar using the control panel and tcWbarConf --Apply.
Then installed Firefox and wbar was gone again. After installing several more extensions all of the sudden the wbar did not disappear after an install. Strange?
I've had similar experiences with wbar using Firefox, could have been other applications too, using TC6.0 at the time. As i find wbar buggy, on my recent TC installs i now promptly remove wbar and switch to JWM. Since TC aims to provide lean releases, query why it is provided by default in TinyCore, as clicking the FLTK desktop provides all necessary functionality to get started.
-
Core Concepts...
One quick user beware: Tiny Core is not a turn-key operating system...
Downloaded programs WILL have an md5 file...
Core is NOT a secure system. All security must be added by the user...
Once an outsider gains access, no program can be trusted. All the features you think would add security could be faked...
If you suspect an intrusion occurred, you would need to boot from a secured thumbdrive and verify the checksums on your persistent storage. Once verified, you could then do your normal boot.
Thanks for the response, it's been enlightening. TinyCore is not turn-key, that is obvious although not a valid argument. For example, out of the box TinyCore provides a control panel and GUI tools for trival matters, such as mounting partitions and changing desktop backgrounds. To shoot down a user concern and/or feature request based on this argument is unfair.
By design TC has features that help make it reasonably secure (no automounts, read-only file system, minimal background services, set password, encrypted backup, etc). And with minimal effort it's not hard to make TC about as secure as any other distribution (iptables, custom software compiles, shutdown without backup, etc).
Since the kernel and primary file system are read-only and the user is in complete control of what gets loaded and backed up/when, then the remaining item is to protect the integrity of the extensions. Thank-you for the sums on separate storage tip, that will be useful.
As there appears to be some confusion, just to be clear this is my concern and feature request. When Apps completes the md5 check and reports 'Md5 checking complete' is also checks and lists the extensions that could not be verified due to a missing md5.txt file. No actual system changes, just reporting. The feature would even be useful to developers, a quick reminder of outstanding md5 files that need to be created prior to submission.
Md5 checking complete.
The following extensions could not be verified due to missing md5.txt files:
abc.tcz
xyz.tcz
No reply required. I've tried to provide feedback on this and previous RCs on several items and my experience has been that in most instances the feedback is quickly pooh-poohed or ignored altogether. When a suggestion is heard, it typically takes numerous responses and lively discussions to justify the request. Apparently TC does not require much refinement and i am probably just wasting everyone's time. I will likely just continue to utilize TC as a regular user. Thanks.
-
bmarkus wrote:
I do not see why and how a missing md5 is imposing a security risk.
Well to me the purpose of an md5 check is not only to confirm an accurate download, but also to help ensure there is no curruption in the system post-install, which could be secondary to a security violation. Does that not make sense?
No. Presence or lack of .md5 has no any security impact, it is not related to security at all. It useful only to check integrity of downloaded file and to speed up update check eliminating md5 recalculation. Thats all.
-
That is the way it is. You need to defend suggested changes. You have to convince the developers here that it is either necessary of desirable.
Your last suggestion that missing md5 files be reported may not seem unreasonable, but may or may not be trivial to implement, and may not, in the view of the developers, fit the intended use of the program.
A patch file providing the feature you wish to be accepted is more likely to get it considered.
-
Patchs for tce-load,tce-setup, please see if they are useful:
1.option -t, to set TCEDIR
2.simplification of app_exists
3.simplification
4.recursive_scan outputs with path, for "tce-load -i/w path1/ext1 path2/ext2"
5.centrally scan dep files.
-
I've just finished preparing the tc-6.2 release, but thanks, we'll have a look for tc-6.3.
-
@aswjh
Thanks!
Patches 1-3 and the tce-setup one applied. On 4 and 5, I think mixed dirs like that is not desirable; it adds complexity, and it's quite reasonable to expect extensions only from one dir in one invocation. 5 did result in a similar speedup in CorePlus as the tce-setup one, but didn't apply alone. If you reworked it to not depend on the mixed dirs, we'll take it too.