Tiny Core Linux
Tiny Core Base => TCB News => Release Candidate Testing => Topic started by: roberts on December 18, 2011, 08:50:16 AM
-
The second release candidate of Core 4.2 is ready for public testing:
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/4.x/x86/release_candidates (http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/4.x/x86/release_candidates)
Main theme for 4.2 release is to focus on the Core.
With the Core Project one starts with the kernel (vmlinuz) and the core.
MicroCore is simply the kernel + core.gz - this is the foundation for user created desktops.
TinyCore is simply the kernel + core.gz + Xvesa.tcz|Xorg.tcz + Xprogs + (user's choice of Window Manager) + (optionally wbar.tcz).
The original TinyCore becomes simply an example of what the Core Project can produce, an 11MB desktop.
4.2 also intoduces CorePlus a simple way to get started using the Core philosophy in allowing easy
embedded frugal or pendrive installation of the user's choice of supported desktop, while maintaining the
Core principal of mounted extensions with full package management.
RC1 Change log:
* Updated tce-setup to use /tmp/builtin for embedded initrd extensions. Changed from /opt/tce
* Updated cpanel to only activate Xvesa button if Xvesa is loaded.
* Updated exittc default focus on OK button for quicker use from keyboard.
* Updated mntttol to call rebuildfstab.
* Updated base for move of /opt/.tce_dir to a link at /etc/sysconfig/tcedir which includes the following:
tce-load, tce-run, tce-setdrive, tce-size, tce-audit, filetool.sh, tce-setup, ondemand, tce-update,
.profile, tc-config, rc.shutdown, appbrowser, appsaudit, exittc, flwm_topside_ondemand,
.setbackground, wbarconf, wbar_update.sh, wbar_setup.sh.
* Updated the following system X/GUI extensions:
Xvesa,tcz, Xlibs.tcz, Xprogs,tcz, fltk-1.10.tcz, flwm_topside.tcz, flwm.tcz, and wbar.tcz.
* Updated tce-setup to write cde info to /etc/sysconfig.
* Updated startx to better support desktop boot code.
* Updated tc-config and tce-setup.sh for refined definition of the base boot code.
base will now only ignore "user" extensions. Builtins and cde extensions always load as they have become by their very nature part of the base system. See CorePlus.iso for how it is being used.
xbase.lst is implemented via our standard lst boot option. But now lst is supported in the cde directory.
Hence by using xbase.lst a simple standard list file containing only the base X/GUI extensions to be loaded.
See CorePlus iso for how it is being deployed.
* Updated interface files for supported window manager extensions:
flwm_topside.tcz, flwm.tcz, fluxbox.tcz, hackedbox.tcz, icewm.tcz, icewm-full.tcz, jwm-snapshot.tcz, jwm.tcz
Files likely in your backup that will need to be updated:
.setbackground
.profile
.xsession
Note: You must recreate all ondemand items. Use AppsAudit OnDemand Maintenance.
CorePlus replaces MultiCore:
CorePlus now sports a boot menu so that the user can easily see the window managers and boot options available.
* Dropped tc-grub4dos
* Dropped tinycore.gz
* Added flwm, jwm, icewm, fluxbox, and hackedbox; plus their dependencies.
* Updated tc-install.sh & tc-install GUI now installs running desktop and detects CorePlus with user selectable options,
frugal now installs embedded, i.e., self contained in the tce directory with option to skip the boot loader install.
* Updated ezremaster to support the new Core foundation.
=======================================================================
RC2 Change Log:
* Clean up of some full paths, adjusted /opt/.filetool.lst and /opt/.xfiletool.lst
* New refactored Xlibs.tcz, Xprogs.tcz so that now Xprogs.tcz contains only FLTK GUI programs. Xprogs is now optional.
* New fltk-1.10.tcz contains only FLTK libraries, required by any FLTK GUI programs.
* New /usr/bin/exittc script to allow exiting WM when no Xprogs are used.
* New /usr/bin/backup script useful when no Xprogs are used.
* Updated .xsession to store X pid.
* Updated tc-config more adjustments for new tce specifications.
Files likely in your backup:
.xsession /opt/.filetool.lst /opt/.xfiletool.lst
You are now be able to use for example, JWM, and no Xprogs.tcz. You would have to use CLI utilities for Core extensions.
* Updated .dep files to include fltk-1.10 libs. You can now use any supported window manager without Xprogs,
Note: With all the structural changes, the required extensions are currently with the release candidate.
Once 4.2 is released the extensions will be moved into the repository.
-
Excellent! Now I should be able to load Xprogs.tcz on demand instead of on boot. :D
-
Running "tce-load -i Xprogs' from an aterm does not update wbar or desktop menus.
X must be stopped and restarted.
-
Excellent! Now I should be able to load Xprogs.tcz on demand instead of on boot. :D
FWIW Booting microcore way back many releases with the X/GUIs in tcedir one could
boot to CLI and when needed, on demand, run tc-setup to fire up a full X/GUI ala tinycore.
This has been available going way back, and can still be done with 4.2 core.gz
Why one would want to boot to X without the full GUI support then want to add such from with X seems rather odd to me.
Not wanting the full GUI support would seem to make sense if one had a dedicated use in mind and not want the dynamic features that the full GUI support provides.
-
Running "tce-load -i Xprogs' from an aterm does not update wbar or desktop menus.
X must be stopped and restarted.
It was not the intent. See my prior post. Will consider.
-
While it boots as expected on the notebook, behaves differently on the desktop as 4.rc1 Pressing enter on a menu option or when timeout expires nothing happenes, system is just freezing. No messages on screen.
-
Perhaps your system cannot handle isohybrid?
Did you ever try booting a multicore iso?
-
Just tested, TC 4.1 boots from CD normally on the desktop.
-
My guess is that it is isohybrid.
-
REPOSTED TinyCore-4.2rc2.iso
Please try this one.
-
4.1 MultiCore: even no boot menu
4.2rc2 TinyCore: same as CorePlus, freezing after boot menu selected
-
If you can boot tinycore 4.1 but not multicore 4.1 then that indicates that your BIOS on desktop is buggy and cannot handle isohybrid. At least this test shows it is not directly related to 4.2 and could have been found when the first multicore iso was issued.
-
If you can boot tinycore 4.1 but not multicore 4.1 then that indicates that your BIOS on desktop is buggy and cannot handle isohybrid. At least this test shows it is not directly related to 4.2 and could have been found when the first multicore iso was issued.
Yes, probably it is a buggy BIOS. To be honest I'm using such ancient media like CD very randomly and till now everything was working. Unfortunately it is valid for USB as well, not only CD/DVD. Motherboard is cca. 3 years old, updated to latest BIOS. While it is a BIOS issue, you know, customer view is simple:
4.1 works, 4.2 doesn'. Therefore it is a 4.2 bug >:(
-
tce-update needs a patch.
Change
*** tce-update.orig Sun Dec 4 00:25:24 2011
--- tce-update Sun Dec 18 10:39:55 2011
***************
*** 214,220 ****
clear
echo -n "${YELLOW}Checking for Easy Mode Operation... ${NORMAL}"
[ -z "$TCE" ] && TCE="$1"
! [ -z "$TCE" ] && TCE=/etc/sysconfig/tcedir
[ "$TCE" == "/tmp/tce/" ] && TCE=""
TCE="${TCE#/mnt/}"
# Next search for tce
--- 214,220 ----
clear
echo -n "${YELLOW}Checking for Easy Mode Operation... ${NORMAL}"
[ -z "$TCE" ] && TCE="$1"
! [ -z "$TCE" ] && TCE=`ls -l /etc/sysconfig/tcedir | awk -F '> ' '{ print $2 }'`
[ "$TCE" == "/tmp/tce/" ] && TCE=""
TCE="${TCE#/mnt/}"
# Next search for tce
A simpler line:
[ -z "$TCE" ] && TCE=`cd -P /etc/sysconfig/tcedir ; pwd`
-
Good find. Thanks! How about:
[ -z "$TCEDIR"] && TCE=`readlink /etc/sysconfig/tcedir`
-
That's even better.
Shows there is more than one way to skin a cat.
-
Running "tce-load -i Xprogs' from an aterm does not update wbar or desktop menus.
X must be stopped and restarted.
Done! :)
-
Awesome work here thanks
meanwhile i'm experiencing a few inconveniences, initially one appeared an issue with the windows managers of coreplus. I figured I'd sample these window managers, with a fresh frugal install between each. Soon after sampling two or three wm's I began experiencing system lockups, resolved by forcing a shutdown to clear each time, pulling the plug deal.
I found that despite the installer reporting to write zeros to the disk, create a new partition, format etc etc. the old installed extensions are loaded each time, ie: the old partition was not being zero'd or partitioned and formatted as indicated. On a clean new drive the installer performed the partitioning and formatting as expected, however a drives partition structure is never again touched once created.
I've performed the install procedure many times, boot to coreplus cd - tc-install - using frugal - whole disk - select disk - install boot loader - format with ext2 - boot options for persistence etc etc.. then watch as the installer writes zero's to the beginning of /dev/sda, create new partition and format it etc etc then reboot to the drive and all old extensions are still present and loaded.
So far have used gparted to wiped the drive and create a new partition, after which the installer from coreplus cd works as advertised.
I found this anomaly can be reliably reproduced using a VM
Also would be grateful for some consistency in the use of the install buttons, like an "exit" button next to the grayed out "proceed" button on install completion, as it is i'm always suspicious if the install fully completed.
-
Just a small cosmetic. Running from CD an eject before shutting down would be convenient.
-
4.1 works, 4.2 doesn'. Therefore it is a 4.2 bug >:(
or it's a syslinux issue. did its version change in the meantime ?
-
"I eat my own dog food", i.e, standard extensions are used to create the isos.
The syslinux extension according to the .info file has not changed since:
Current: 2010/07/14
What did change during this RC cycle was the added isohybrid code on the TinyCore iso.
The latest posting of TinyCore-4.2rc2.iso has the isohybrid feature removed.
I am waiting to hear if the removal of the isohybrid solves the reported issue.
-
Awesome work here thanks
meanwhile i'm experiencing a few inconveniences, initially one appeared an issue with the windows managers of coreplus. I figured I'd sample these window managers, with a fresh frugal install between each. Soon after sampling two or three wm's I began experiencing system lockups, resolved by forcing a shutdown to clear each time, pulling the plug deal.
I found that despite the installer reporting to write zeros to the disk, create a new partition, format etc etc. the old installed extensions are loaded each time, ie: the old partition was not being zero'd or partitioned and formatted as indicated. On a clean new drive the installer performed the partitioning and formatting as expected, however a drives partition structure is never again touched once created.
I've performed the install procedure many times, boot to coreplus cd - tc-install - using frugal - whole disk - select disk - install boot loader - format with ext2 - boot options for persistence etc etc.. then watch as the installer writes zero's to the beginning of /dev/sda, create new partition and format it etc etc then reboot to the drive and all old extensions are still present and loaded.
So far have used gparted to wiped the drive and create a new partition, after which the installer from coreplus cd works as advertised.
I found this anomaly can be reliably reproduced using a VM
Also would be grateful for some consistency in the use of the install buttons, like an "exit" button next to the grayed out "proceed" button on install completion, as it is i'm always suspicious if the install fully completed.
Obviously a virtual machine is not a real machine. I suspect that hdparm -z is not being supported by your vm. hdparm -z is required to re-read an in session change to a drive partition table.
-
"I am waiting to hear if the removal of the isohybrid solves the reported issue.
Just downloaded Tiny Core and Core Plus. Same as before, doesn't work. If iso hybrid removed, it is something else.
-
With TinyCore being only an example and CorePlus only a convenience installlation build.
Nothing should preclude you from proceeding with Core-4.2.iso with your desired collection of X/GUI extensions residing on your tcedir.
-
With TinyCore being only an example and CorePlus only a convenience installlation build.
Nothing should preclude you from proceeding with Core-4.2.iso with your desired collection of X/GUI extensions residing on your tcedir.
There are no reason to use 4.rc2, I will stay with stable 4.1 which runs smoothly on all machines here. Testing was done, result reported.
-
Obviously a virtual machine is not a real machine. I suspect that hdparm -z is not being supported by your vm. hdparm -z is required to re-read an in session change to a drive partition table.
Didn't notice hdparm in the list of installed extensions Am assuming some features of hdparm are included with the installer?
Many methods exist to write new partition tables I use gparted successfully on all VM's and real hardware included. Havent experience any negative issues using hdparm before but will investigate if you feel this is the cause of this issue.
I really like the installer, pity grub4dos has been depreciated, I still use it on older hardware which Syslinux v 4.x hasn't supported.
edit: syslinux has not changed (is still v4.01)
-
Hi coreplayer2
hdparm is provided by busybox through a link in /sbin.
-
thanks, although is busy box always installed with coreplus? ...?
-
BusyBox has been from day one at the very core of each "Core" release. In it's many "incarnations" (i.e. the so called applets) it provides the equivalent of ca. 225 different executables, whilst not even using up 500 kBytes. It is one of the main reasons why Core can be as small as it is.
The fact that someone with 300+ posts in this forum here is not even aware of such IMHO "basic fact about Core" makes me really wonder why people are seemingly not even reading the first line of the Welcome page (http://distro.ibiblio.org/tinycorelinux/welcome.html).
BTW that page probably needs some refresh to adjust to the fact that kernel v2.6 is now history, and possibly some more due to the change of focus from TC to Core.
-
Hi coreplayer2
Open a terminal an enter ls -l /bin
You will see that the majority of the commands listed (including ls) are really links to busybox.
Now enter ls -l /sbin
You will find that a lot of those commands are just links to /bin/busybox.
-
got it thanks
-
" seemingly" is the operative word as I find myself repeatedly reading the wiki and FAQ etc especially when scouring for answers. like you point out these docs are not always current but is still one of the many resources we have to learn with.
edit: I believe I'd confused busybox with something else..
-
While testing v4.2rc1, I noticed some similarity with marcus reports. My stick created with CorePlus show next boot problems:
Booting stick on the PC connected to the dhcp network blocked without any message.
After removing "quiet" boot option, I noticed that system is waiting for relatively long time in the text mode for establishing network connection.
With Icewm boot option, system booted into X environment without waiting, but after I created mydata.tgz I had problems with rebooting flwm option.
I tried different installations and boot options and it seems to me that problems with ethernet connection establishing and problems with /tce location identification (local or network) during the booting of the core.gz part can block the process before installation of X extensions, leaving user without adequate message .
Now I am testing v4.2rc2 on the dhcp connected PC and gprs connected laptop. I tried to take care of network connectivity, and I haven`t noticed any booting problem so far.
-
Starting point is mc4.0.2 + Xorg74 + all other files for making a TCL 4.0.2.
I made the update: Xlibs, Xprogs, Xorg76 instead of Xorg74 and putted core.gz in the grub menu, non persistent home.
Good: a screen appear (this was not the case with rc1). So, this is an improvement.
Still an Error:
- an X appear on the screen instead of an arrow; no control of the screen with the mouse.
- when a terminal windows opened, by putting "mnttool &", an error "missing libfltk.so.." appear; by putting "fluff", an error "missing fltk_images.. " appear despite the fltk-1.10 is in the directory "optional".
So, I made tce-load -wi libfltk. But the file seems not to be there.
I will try to complete this post because I currently cannot remember where the"missing libfltk appear". In dmesg or other.
-
You need:
http://distro.ibiblio.org/tinycorelinux/4.x/x86/release_candidates/fltk-1.10.tcz (http://distro.ibiblio.org/tinycorelinux/4.x/x86/release_candidates/fltk-1.10.tcz)
-
@maro:
Edited to say 3.0 kernel. The Core change should wait until 4.2 is stable.
-
The fact that someone with 300+ posts in this forum here is not even aware of such IMHO "basic fact about Core" makes me really wonder why people are seemingly not even reading the first line of the Welcome page (http://distro.ibiblio.org/tinycorelinux/welcome.html).
BTW that page probably needs some refresh to adjust to the fact that kernel v2.6 is now history, and possibly some more due to the change of focus from TC to Core.
i never thought that people can be judged by post count.
to me it was pretty obvious that busybox is used (as i am at least familiar with it), but mnany people do not care about internal workings of any given system, TC included. TC is fairly user friendly and can be used without extensive knowledge of its internals.
Booting stick on the PC connected to the dhcp network blocked without any message.
After removing "quiet" boot option, I noticed that system is waiting for relatively long time in the text mode for establishing network connection.
i am sometimes experiencing this on a system which has issues with r8169 network driver. r8168 driver is more stable for this particular hardware, but AFAIK it requires a manual build. the behavior is hard to connect to any specific software configuration.
-
Hm, having waitusb=5 in the TC iso gives a bad impression. If the TC iso is not to be an isohybrid, I don't think it should have that wait there.
Reading the original request, it was about a new menu option in CorePlus having such, not in the default boot of the TC iso.
-
Agreed and waitusb=5 have been removed.
-
While testing v4.2rc1, I noticed some similarity with marcus reports. My stick created with CorePlus show next boot problems:
Booting stick on the PC connected to the dhcp network blocked without any message.
After removing "quiet" boot option, I noticed that system is waiting for relatively long time in the text mode for establishing network connection.
With Icewm boot option, system booted into X environment without waiting, but after I created mydata.tgz I had problems with rebooting flwm option.
I tried different installations and boot options and it seems to me that problems with ethernet connection establishing and problems with /tce location identification (local or network) during the booting of the core.gz part can block the process before installation of X extensions, leaving user without adequate message .
Now I am testing v4.2rc2 on the dhcp connected PC and gprs connected laptop. I tried to take care of network connectivity, and I haven`t noticed any booting problem so far.
Interesting as initial dhcp request is backgrounded. Please provide very specific details on how pendrive from CorePlus was created? dd, unetbootin, tc-install, or ? Typically on any boot time access to a usb device generally requires a waitusb=5. Do you have such in your pendrive boot parameters?
-
Agreed and waitusb=5 have been removed.
Won't that break CorePlus dd-d to a pendrive?
What if the CD is USB connected?
How will it find cde ?
Perhaps label the CD and use waitusb with a label.
-
Curaga was talking about TC iso only. CorePlus is unchanged.
-
It will find 'cde' on a USB connected CD without the waitusb?
-
You need:
http://distro.ibiblio.org/tinycorelinux/4.x/x86/release_candidates/fltk-1.10.tcz (http://distro.ibiblio.org/tinycorelinux/4.x/x86/release_candidates/fltk-1.10.tcz)
this file was already in the "optional" directory.
the error came up by trying to start mnttool. Similar error by trying to start fluff.
Update: eveything work fine after the dep files are loaded. Thanks.
-
It will find 'cde' on a USB connected CD without the waitusb?
Right, I didn't think of that scenario.
I agree with using the TinyCore label, everyone should not wait for the few.
-
besides, the few can always add the waitusb=5 as needed
-
You should not have to do anything special to boot the CD just because it is connected by USB.
That would cause a storm of forum posts because it doesn't boot properly.
-
Interesting as initial dhcp request is backgrounded. Please provide very specific details on how pendrive from CorePlus was created? dd, unetbootin, tc-install, or ? Typically on any boot time access to a usb device generally requires a waitusb=5. Do you have such in your pendrive boot parameters?
After I read yoshi314`s post:
Booting stick on the PC connected to the dhcp network blocked without any message.
After removing "quiet" boot option, I noticed that system is waiting for relatively long time in the text mode for establishing network connection.
i am sometimes experiencing this on a system which has issues with r8169 network driver. r8168 driver is more stable for this particular hardware, but AFAIK it requires a manual build. the behavior is hard to connect to any specific software configuration.
I analyzed dmesg from my PC installation and noticed just what yoshi314 said - problem with r8169 driver which temporarily blocked on
eth0: link down
etho: link up
kernel boot phase.
So I can very gladly say that problem I had is not concerned with 2rc1 release !
With best regards
-
I suspect that hdparm -z is not being supported by your vm. hdparm -z is required to re-read an in session change to a drive partition table.
As you suspected hdparm -z is unable to reinitialize reading of partition table structures.
-
to me it was pretty obvious that busybox is used (as i am at least familiar with it), but mnany people do not care about internal workings of any given system, TC included. TC is fairly user friendly and can be used without extensive knowledge of its internals.
I too know what busy box is, just had a senior moment is all.. lol
i am sometimes experiencing this on a system which has issues with r8169 network driver. r8168 driver is more stable for this particular hardware, but AFAIK it requires a manual build. the behavior is hard to connect to any specific software configuration.
I have compiled the r8168 Ethernet driver for tc4.1 some weeks back and forgot to submit it. meanwhile it's been thoroughly tested so I'll get it submitted today.
hope it helps someone