Tiny Core Linux
Tiny Core Base => TCB News => Release Candidate Testing => Topic started by: roberts on July 31, 2011, 01:32:52 AM
-
The Third Release Candidate of Tiny Core v3.8 is now posted and ready for testing.
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/3.x/release_candidates
tinycore_3.8rc3.iso
tinycore_3.8rc3.iso.md5.txt
Change log:
rc1
* New icons for AppBrowser and AppsAudit.
* Updated mnttool - added a refresh button.
* Updated AppsBrowser - clear Search&Provides field upon results.
* Updated Wallpaper - Improved GUI. Now with a single window.
* Updated AppsAudit - updated error reporting and now reports stale extensions.
* Updated tce-load - now allows re-downloading non-installed extensions to better handle download failures.
* Updated tce-setup & tce-load to ensure busybox calls thus avoiding conflicts with gnu utilities.
* Updated rc.shutdown - removed sleep to improve shutdown speed.
rc2
* Updated AppsAudit - md5 function slowness corrected.
* Updated wbarconf - support for no initial .wbar
* Updated busybox - 1.18.5 new depmod applet and audit of required applets.
* Updated search.sh - improved searching by title results and support for fat file-system.
* Updated provides.sh - support for fat file-system.
* Updated tce-setup, tce-load, and loadpack.sh - alias for new depmod applet.
* Updated .profile - new user login sudo issue resolved.
* Removed remnant .wbar from /etc/skel
* Updated AppBrowser & AppsAudit icons - slightly larger
Note: depmod has been moved to extensions, gnu depmod may be required by certain extensions, e.g., alsa.
rc3
* Updated rebuildfstab and tc-config for AOE support.
* Updated tc-functions getpassword to support backspace during input.
* Updated screenshot to display file name created upon completion.
* Updated tc-audit added "fetchmissing" to fetch missing dependencies.
* Updated AppsAudit dependencies menu grouping and added "Fetch Missing Dependencies".
* Updated tce-setup for loading tce directory on cdrom and installable via updates to tc-install & tc-grub4dos
* Updated multicore.iso to use CD tce directory together with specific boot lists for network, install, or grub4dos.
* Updated tce-setup, tce-load, and loadpack.sh to ensure busybox is not trumped by coreutils or util-linux-ng.
Thanks go to Gerald Clark for the new AOE support.
-
Thanks go to Gerald Clark for the new AOE support.
What is AOE?
-
Robert,
Ever since I read your "teaser (http://forum.tinycorelinux.net/index.php?topic=10305.msg57167#msg57167)" about it I was curious what these
* Updated tce-setup for loading tce directory on cdrom and installable via updates to tc-install & tc-grub4dos
* Updated multicore.iso to use CD tce directory together with specific boot lists for network, install, or grub4dos
might mean. Would you please care to elaborate (either here or in the other thread)?
bmarcus,
Not that I know anything about it, but taking a guess it might be: ATA over Ethernet (http://en.wikipedia.org/wiki/ATA_over_Ethernet) (purely on the basis that it is the most likely "candidate" showing up here (http://en.wikipedia.org/wiki/Aoe)).
-
AOE is ATA over Ethernet. Since I don't have such equipment I will let Gerald comment further on it.
Brian (ixbrian) also tested AOE in previews of 3.8rc3 so both would be better to comment further.
The tce directory on CD and new multicore are in response to:
http://forum.tinycorelinux.net/index.php?topic=10305.0
The new multicore is no longer using starter packs, but instead individual tczs. This not only proves the new support but was my response to seeing a new user not having easy access to GUI installation program because of the high demand of memory of starter packs, even when booting from existing multicore. With the new multicore, using network or installation tools, has much lower memory requirement because of regular tcz mounting. Also Brian helped modify both installation programs to install whatever is in the CD tce directory.
So once, again, we have an easy remaster but now the remaster will be completely installed not just the base. The mods made to tce-setup to support CD tce will no longer cause a broken or discouraging experience.
-
There is a Wiki page for AOE see: http://wiki.tinycorelinux.net/wiki:netbooting?s#aoe_for_a_tce_directory
-
I'm unable to mount any dvd if a disc was in the player during boot. Mounting dvds works if player was empty during boot.
I'm running mc with xorg 7.5.
I'm still having this issue but I've discovered that this only occurs when there is a video-dvd left in the drive (not data dvds). I'm using a laptop with internal dvd. It used to work with earlier versions of mc but I can't say for sure if this issue was introduced with 3.8.
Regards
Uggla
-
Big smiles and thank yous for the Fetch missing dependencies function update! ;D ;D ;D
-
I'm unable to mount any dvd if a disc was in the player during boot. Mounting dvds works if player was empty during boot.
I'm running mc with xorg 7.5.
I'm still having this issue but I've discovered that this only occurs when there is a video-dvd left in the drive (not data dvds). I'm using a laptop with internal dvd. It used to work with earlier versions of mc but I can't say for sure if this issue was introduced with 3.8.
Regards
Uggla
I was able to reproduce and have a fix for 3.8 final. Thanks for reporting.
-
My bootlocal.sh has lines such as:
echo "/mnt/hda2/backgrounds /opt/backgrounds nfs defaults 0 0" >> /etc/fstab
echo "$SERVER:/mnt/music /mnt/music none bind 0 0" >> /etc/fstab
echo "$SERVER:/mnt/stuff/TCL /mnt/TCL nfs defaults 0 0" >> /etc/fstab
mount -a
These lines disappear from fstab with tinycore, but not with microcore.
Microcore is using the supplied Xlibes.tcz, Xprogs.tcz, and Xvesa.tcz,
so there should be no difference in behavior.
-
Found while trying to troubleshoot previous post:
When using the 'base' boot option, a large section of code is skipped, so /opt/.tce_dir is not set, and restore does not happen.
-
It can mount tcz in ISO, but mydata.tgz in iso, it will not restore .
-
Oh please. The backup file mydata.tgz is for doing backups. Which won't work very well when you try to write to a CD! If you must then make it into a tcz.
-
Oh please. The backup file mydata.tgz is for doing backups. Which won't work very well when you try to write to a CD! If you must then make it into a tcz.
but tce in a CD , if it can load mydata.tgz , it will be a liveCD system . of couse I don't need to backup mydata. I just use this in vm or test a system.
and mydata.tgz can use win-7zip to change data directly in Windows. but .tcz need to unmksqush and than mksqush.
-
It may not be what you want, but it is the expected and defined behavior that upon shutdown personal files to saved (written) to mydata,tgz.
-
@ roberts
I have a suggestion
first: disable $MOUNTPOINTFS" == iso9660 check of tc-setup like tc3.6 and before
MOUNTPOINTFS="$(grep ${MOUNTPOINT} /etc/fstab | awk '{print $3}')"
if [ "$MOUNTPOINTFS" == iso9660 ]; then
TCEDIR="$MOUNTPOINT"/"$TCE_DIR"
LOADFROM="$TCEDIR"/optional
[ -s "$TCEDIR"/"$TARGETLIST" ] && for FILE in `cat "$TCEDIR"/"$TARGETLIST"`; do FILE="$LOADFROM/$FILE" && process; done
#### TCEDIR=/tmp/tce
else
TCEDIR="$MOUNTPOINT"/"$TCE_DIR"
echo "$MOUNTPOINT" > /etc/sysconfig/tce.mount
sync
fi
echo "$TCEDIR" > /opt/.tce_dir
chown -R "$USER".staff "$TCEINSTALLED"
than add tc-setup2iso like this
#!/bin/sh
#(c) Robert Shingledecker 2009-2011
. /etc/init.d/tc-functions
#########
[ -z "$TCE" ] && TCE="$(autoscan 'tce' 'd')"/tce
if [ "$TCE" != "/tce" ]; then
TCE_DEVICE="${TCE%%/*}"
TCE_DIR="${TCE#*/}"
if [ "$TCE_DEVICE" = "$TCE_DIR" ]; then TCE_DIR="tce"; fi
find_mountpoint "$TCE_DEVICE"
if [ -n "$MOUNTPOINT" ]; then
if [ "$MOUNTED" == "yes" ]; then
if [ ! -d "$MOUNTPOINT"/"$TCE_DIR"/optional ]; then
mkdir -p "$MOUNTPOINT"/"$TCE_DIR"/optional
fi
else
mount "$MOUNTPOINT"
if [ $? == 0 ]; then
UMOUNT="yes"
if [ ! -d "$MOUNTPOINT"/"$TCE_DIR"/optional ]; then
mkdir -p "$MOUNTPOINT"/"$TCE_DIR"/optional
fi
fi
fi
fi
else
MOUNTPOINT="/tmp"; TCE_DIR="tce"
fi
MOUNTPOINTFS="$(grep ${MOUNTPOINT} /etc/fstab | awk '{print $3}')"
if [ "$MOUNTPOINTFS" == iso9660 ]; then
# TCEDIR="$MOUNTPOINT"/"$TCE_DIR"
# LOADFROM="$TCEDIR"/optional
# [ -s "$TCEDIR"/"$TARGETLIST" ] && for FILE in `cat "$TCEDIR"/"$TARGETLIST"`; do FILE="$LOADFROM/$FILE" && process; done
TCEDIR=/tmp/tce
#else
# TCEDIR="$MOUNTPOINT"/"$TCE_DIR"
# echo "$MOUNTPOINT" > /etc/sysconfig/tce.mount
# sync
#fi
echo "$TCEDIR" > /opt/.tce_dir
fi
at last : add tc-setup2iso in /opt/bootlocal.sh
I tryed it can mount tce in CD and load mydata.tgz like a LIVECD.
and /opt/.tce_dir set to /tmp/tce like the tinycore_3.8rc3.iso
-
Obviously you can hack the system as you please but I am not going to bastardize the definition or expected behavior of mydata.tgz in the base system.
-
and I don't want to hack the intrid tinycore.gz too. like tc3.6 and before, they can mount tce and
mydata.tgz , but they can not set the /opt/.tce_dir to /tem/tce . if tc3.8 can add the $MOUNTPOINTFS" == iso9660 check at last , they all can done.
someone want to burn his hard-disk system to .iso , It can add his tce and mydata.tcz to the CD directly . and other can share .iso in VMware. just like a pure tinycore.iso.
-
Icon definition in tinycore-appsaudit.desktop is buggy:
[Desktop Entry]
Name=AppsAudit
Exec=appsaudit
Icon=gear
X-FullPathIcon=/usr/share/pixmaps/appsaudit.png
Type=Application
Categories=System;
Proper one:
[Desktop Entry]
Name=AppsAudit
Exec=appsaudit
Icon=appsaudit
X-FullPathIcon=/usr/share/pixmaps/appsaudit.png
Type=Application
Categories=System;
-
Thanks. Updated the icon entry.
-
and I don't want to hack the intrid tinycore.gz too. like tc3.6 and before, they can mount tce and
mydata.tgz , but they can not set the /opt/.tce_dir to /tem/tce . if tc3.8 can add the $MOUNTPOINTFS" == iso9660 check at last , they all can done.
someone want to burn his hard-disk system to .iso , It can add his tce and mydata.tcz to the CD directly . and other can share .iso in VMware. just like a pure tinycore.iso.
I am not going to rehash 3.6 and the broken isos that could be created and resulting posts that many things did not work. Instead of hacking...
Convert mydata.tgz to a .gz Voila!
-
Under 3.8rc3, the environment that is set up in .profile does not seem to be in effect for an app loaded as an extension.
This is a change from 3.8rc2 and earlier and it breaks, for instance, some scripts associated with custom buttons in emelfm2. I don't have a convenient way to test other extensions right now and this is not something that really lends itself to testing in a "base norestore" environment, however, the only difference between the two environments is the instance of bzImage and tinycore.gz (and the bzImage files do in fact match)... using the same tce directory with the same contents (including the same mydata.tgz). emelfm2 is loaded from the command line after bootup is complete.
Under 3.8rc3 -and- 3.8rc2, the PATH as reported in a shell is:
/home/tc/.local/bin
/usr/local/bin
/usr/local/sbin
/usr/sbin
/usr/bin
/sbin
/bin
Under 3.8rc3, the PATH as reported by emelfm2 is:
/usr/sbin
/usr/bin
/sbin
/bin
/usr/local/bin
/usr/local/sbin
But, under 3.8rc2, the PATH as reported by emelfm2 is:
/home/tc/.local/bin
/usr/local/bin
/usr/local/sbin
/usr/sbin
/usr/bin
/sbin
/bin
-
I am not going to rehash 3.6 and the broken isos that could be created and resulting posts that many things did not work. Instead of hacking...
Convert mydata.tgz to a .gz Voila!
ok , I convert mydata.tgz to data.gz in iso , but it also like not work .
# Process any .gzs before attempting to mount tce directory.
# /opt/tce support provided only for the purpose of a remaster.
if [ "$(ls -A "/opt/tce"/*.gz 2>/dev/null)" ]; then
process_gz "/opt/tce"
fi
[ -z "$TCE" ] && TCE="$(autoscan 'tce' 'd')"/tce
if [ "$TCE" != "/tce" ]; then
TCE_DEVICE="${TCE%%/*}"
TCE_DIR="${TCE#*/}"
if [ "$TCE_DEVICE" = "$TCE_DIR" ]; then TCE_DIR="tce"; fi
find_mountpoint "$TCE_DEVICE"
if [ -n "$MOUNTPOINT" ]; then
if [ "$MOUNTED" == "yes" ]; then
if [ ! -d "$MOUNTPOINT"/"$TCE_DIR"/optional ]; then
mkdir -p "$MOUNTPOINT"/"$TCE_DIR"/optional
fi
else
mount "$MOUNTPOINT"
if [ $? == 0 ]; then
UMOUNT="yes"
if [ ! -d "$MOUNTPOINT"/"$TCE_DIR"/optional ]; then
mkdir -p "$MOUNTPOINT"/"$TCE_DIR"/optional
fi
fi
fi
fi
else
MOUNTPOINT="/tmp"; TCE_DIR="tce"
fi
MOUNTPOINTFS="$(grep ${MOUNTPOINT} /etc/fstab | awk '{print $3}')"
if [ "$MOUNTPOINTFS" == iso9660 ]; then
TCEDIR="$MOUNTPOINT"/"$TCE_DIR"
LOADFROM="$TCEDIR"/optional
[ -s "$TCEDIR"/"$TARGETLIST" ] && for FILE in `cat "$TCEDIR"/"$TARGETLIST"`; do FILE="$LOADFROM/$FILE" && process; done
TCEDIR=/tmp/tce
else
TCEDIR="$MOUNTPOINT"/"$TCE_DIR"
echo "$MOUNTPOINT" > /etc/sysconfig/tce.mount
sync
fi
echo "$TCEDIR" > /opt/.tce_dir
chown -R "$USER".staff "$TCEINSTALLED"
# Process any .gzs in tce directory before regular extensions.
if [ "$(ls -A "$TCEDIR"/*.gz 2>/dev/null)" ]; then
process_gz "$TCEDIR"
fi
Where can I put .gz in CD directory ? add new directory /opt/tce/*.gz in CD or /tce/*.gz in CD.
I tried it not work.
-
Is there a reason why there are no '*.dep' files in the 'tce/optional' directory of 'multicore_3.8rc3.iso'?
I guess that will make it difficult for a system installed via 'tc-install' as all files from that directory are getting copied to the installation device. On second thoughts is forcing to copy all those files onto the target device really a good idea? Currently the user ends up with all those extensions on the target device (including those not required for the installation mode used).
Furthermore there are also no '*.md5.txt' files present, but maybe that's just me who thinks that those are useful. I'm not really a user of 'appsaudit', but I've got the hunch that the lack of those files might hamper the usefulness of that tool.
Note: I was not sure whether multicore related issues should be added here, or whether there is an already existing thread for them. So mods please move this one, if here is not the right place.
-
ok , I convert mydata.tgz to data.gz in iso , but it also like not work .
You should look at microcore_3.7.1.iso as it loads multiple .gzs
-
Under 3.8rc3, the environment that is set up in .profile does not seem to be in effect for an app loaded as an extension.
This is a change from 3.8rc2 and earlier and it breaks, for instance, some scripts associated with custom buttons in emelfm2. I don't have a convenient way to test other extensions right now and this is not something that really lends itself to testing in a "base norestore" environment, however, the only difference between the two environments is the instance of bzImage and tinycore.gz (and the bzImage files do in fact match)... using the same tce directory with the same contents (including the same mydata.tgz). emelfm2 is loaded from the command line after bootup is complete.
Under 3.8rc3 -and- 3.8rc2, the PATH as reported in a shell is:
/home/tc/.local/bin
/usr/local/bin
/usr/local/sbin
/usr/sbin
/usr/bin
/sbin
/bin
Under 3.8rc3, the PATH as reported by emelfm2 is:
/usr/sbin
/usr/bin
/sbin
/bin
/usr/local/bin
/usr/local/sbin
But, under 3.8rc2, the PATH as reported by emelfm2 is:
/home/tc/.local/bin
/usr/local/bin
/usr/local/sbin
/usr/sbin
/usr/bin
/sbin
/bin
Not being am emelfm user please provide specifics.
-
Is there a reason why there are no '*.dep' files in the 'tce/optional' directory of 'multicore_3.8rc3.iso'?
I guess that will make it difficult for a system installed via 'tc-install' as all files from that directory are getting copied to the installation device. On second thoughts is forcing to copy all those files onto the target device really a good idea? Currently the user ends up with all those extensions on the target device (including those not required for the installation mode used).
Furthermore there are also no '*.md5.txt' files present, but maybe that's just me who thinks that those are useful. I'm not really a user of 'appsaudit', but I've got the hunch that the lack of those files might hamper the usefulness of that tool.
Note: I was not sure whether multicore related issues should be added here, or whether there is an already existing thread for them. So mods please move this one, if here is not the right place.
The load lst files are simply the contents of the starter packs. But I see your point for management after performing an installation.
Currently the user has the following Installation options available:
1. If one has wired ethernet, download tc-install.tcz
2. If you have an existing running system, Windows or any Linux distro with net (wired or wireless) access, download starter pack install.gz then boot tinycore, mount and loadpack
3. If you have neither of the above, then you are left with multicore.
You raise a valid point on installation, but perhaps not with regard to network. The only real stumbling block to performing an installation is the case when no wired network (item 1 above) or no net access via alternate OS (item 2). Then perhaps multicore should only contain the network tools collection! As typically one would want those tools installed. The installation would then be relegated to item 1 & 2 above. Hopefully only item 1.
-
...
Under 3.8rc3, the PATH as reported by emelfm2 is:
/usr/sbin
/usr/bin
/sbin
/bin
/usr/local/bin
/usr/local/sbin
But, under 3.8rc2, the PATH as reported by emelfm2 is:
/home/tc/.local/bin
/usr/local/bin
/usr/local/sbin
/usr/sbin
/usr/bin
/sbin
/bin
Not being am emelfm user please provide specifics.
I have configured a pair of buttons on the central toolbar of emelfm2, each of which calls a script that is located in ~/.local/bin/
Since /.local/bin/ is added to the PATH by ~/.profile, it was not necessary to configure the buttons with the full path to the scripts because the application, emelfm2, used a PATH inherited (possibly indirectly) form the login shell.
With 3.8rc3, the buttons no longer work. They do work in 3.8rc2. A little investigation revealed the PATH listings shown above, which were generated from within emelfm2 under 3.8rc2 and 3.8rc3.
While it would be relatively simple to reconfigure the buttons to use full paths to the scripts they invoke, I worry that this or other environment settings required by this or other applications might cause problems if not set.
I'm supposing that the Xserver gets its initial environment from the login shell and the application gets its initial environment from the Xserver. Since my working environment is the same other than the rc level of tinycore.gz, I'm wondering what change in tinycore.gz might have caused the observed behavior.
-
Connection issues with AppBrowser! Am using Virtual Box for both tc3.7.1 & tc3.8RC3 on a Windows7 machine. Both VM's use the same hardware (Intel Pro1000) and both are assigned an IP address, yet while the 3.7.1 version 9of AppBrowser connects via the hard line eth0 immediately, the 3.8RC3 beta reports a connection issue when selecting "AppBrowser Connect"
Note: while I misinterpreted this as an internet connection issue it is not but only the App-browser in 3.8RC3 only is unable to connect. In troubleshooting, I copied firefox.tcz over from the other installation loaded it and it connected as expected.
Even selecting a mirror the connect button fails to connect.
ok try this!
tc@box:~$ tce-load -wi firefox.tcz
Downloading: firefox.tcz
wget: can't open 'firefox.tcz.md5.txt': Permission denied
Connecting to ftp.vim.org (192.87.102.43:80)
wget: can't open 'firefox.tcz': Permission denied
md5sum: firefox.tcz.md5.txt: No such file or directory
Error on firefox.tcz
tc@box:~$ tce-load -wi firefox.tcz
Downloading: firefox.tcz
wget: can't open 'firefox.tcz.md5.txt': Permission denied
Connecting to distro.ibiblio.org (152.19.134.43:21)
wget: can't open 'firefox.tcz': Permission denied
md5sum: firefox.tcz.md5.txt: No such file or directory
Error on firefox.tcz
tc@box:~$
-
You should look at microcore_3.7.1.iso as it loads multiple .gzs
Thanks
I think another method will better
I set the MOUNTPOINTFS == iso9660 check before the file " tc-config " #After restore items
both mydata.tgz and *.gz in CD all done. and I tested it like a pure tc.iso .
-
@Lee
I have a proper path (echo $PATH in mc 3.8rc3 after login). The path mentioned is only active during extension loading; does emelfm create a config file on load? Perhaps it grabs the wrong path there.
Could you check in a shell too?
-
To answer my own question:
Not being am emelfm user please provide specifics.
There is a run command input area at lower right bottom of emelfm2.
Typing echo $PATH displays the PATH issue that Lee is experiencing and can be reproduced.
-
Hi Curaga,
In either 3.8rc2 or 3.8rc3, at a shell prompt, I get the expected PATH:
/home/tc/.local/bin
/usr/local/bin
/usr/local/sbin
/usr/sbin
/usr/bin
/sbin
/bin
Its only in emelfm2 that I see the difference. I don't see any config files getting created at extension load time, but shouldn't they be the same anyhow?
--- a little time passes, during which I do some testing and roberts does also ---
I'm not a rox-filer user but I was able to verify that this issue affects rox-filer as well. I also determined that if I close down X completely (exit to prompt) and restart it, the symptoms disappear.
-
I have a fix. I was attempting a temporary PATH for the coreutils and util-linux-ng issues. I will use an alternate method. Now that I know how to use emelfm2 to test. I can verify all three cases for the next cut.