Problem with tce stored on ISO

[SvOlli]

It seems that since 3.7 I get a warning when I try to load tczs and mydata.tgz from a CD-ROM.

Up to 3.6 it worked just fine, after starting up from ISO it used /tmp/tce for storage of downloaded tczs.

I was using onboot.lst to load everything into RAM during startup, as copy2fs.flg was set. Losing this ability killed one option of an easy remaster. It could be converted to initrds.gz, but this one gets in the way of using the contents of the CD to create a new Tiny Core system to set up a new installation.

As this behavior seems to be a workaround for some problem that occurs when using tczs from CD-ROM, I suggest the following behavior: when a tcz is loaded during startup, treat it like copy2fs.flg is set, and switch to /tmp/tce _after_ the loading of the initial tczs.

Or an even more elegant way to solve this (as a suggestion for 4.x): when detecting that tczs are loaded from CD-ROM, put a tmpfs "over" it using unionfs / aufs.

Digging into the problem looking for a simple workaround, noticed something quite odd:

Code: [Select]

yes y | cp -ai "$TCEDIR"/optional/upgrade/* "$TCEDIR"/optional/. 2>/dev/null && rm -rf "$TCEDIR"/optional/upgrade
Why isn't this just

Code: [Select]

cp -a "$TCEDIR"/optional/upgrade/* "$TCEDIR"/optional/. 2>/dev/null && rm -rf "$TCEDIR"/optional
It looks to me, that the "yes y |" is a workaround for a problem introduced by the "-i"-flag of cp.

[SvOlli]

Thinking about it, there could be an easy workaround for the problem:

Instead of printing out the warning, and doing nothing, copy the contents of <cdrom>/tce to /tmp/tce and print out a notice like: "Warning! Since tce can't be on a read-only medium contents are copied to RAM."

Even better: either of these both behaviors could be made selectable with a boot option.

[roberts]

This was done to protect the integrity of the system.

Having users with cdroms that backup does not work. AppBrowser does not work. AppsAudit does not work. Does not make for a very good impression of Tiny Core.

Of course one can hack their way around this. But does hacking make for a good impression either. I think not.

There is a proper way to make a remaster.

[SvOlli]

Browsing through the wiki, I noticed that converting tczs to initrds.gz is indeed the way to go since 3.7.

I will have to think over on how to integrate it into thefullcore.sh.

But it also leaves me with two question: are the "setup-scripts" in /usr/local/tce.installed executed? Iirc, that was one of the drawbacks switching to initrds.gz? And why couldn't I find it in the release-notes of 3.7?

[curaga]

Extensions in /opt/tce are processed normally. Extensions extracted into the initrd do not run startup scripts.

Thus, pack them into /opt/tce in the new initrd

[SvOlli]

One of the main ideas of The Full Core is, that you just copy the whole contents of the ISO onto a harddisk or an usb stick, make it bootable, and you get a full featured Tiny Core Linux system. I was using it as a base to set up new systems, as well as running it from network or CD as a rescue system. The later use case is now broken by the "read-only" fix introduced with 3.7.

After thinking quite some time about it, I can't come up with a good solution to this problem. Generating an initrd containing /opt/tce won't work for me, because it either breaks the ability for updating or wastes diskspace by keeping the same package in two versions (/opt/tce and <hd>/tce) aroud.

From my point of view, the only way to get it working properly from CD again would be to load the extensions from CD, and switch to /tmp/tce after that. Why shouldn't this work almost the same like a frugal start? Please explain this to me.

Every other option I came so far, is at least one step back from the straight forward design ideas I had for The Full Core. I'm open to any suggestions.

[roberts]

Installation expediency for a remaster should not trump integrity of the base system,

Based on your post, I have burned a copy of Full Core and there it is. /opt/.backup_device as well as /opt/.tce_dir both point to the read-only cdrom.Thus using this cd as one would expect it to perform as a typical Tiny Core cd, backup fails, appsbrowser fails, appsaudit fails, ondemand fails. wbar_conf fails. All the normal Tiny Core specific functions fail. It would then appear that then the function of this cd is a medium for installation. Yet I saw no warnings and no such intended use. Your opening salvo would also suggest such is the intended use.

With Tiny Core v3.7 many new features are present to facilitate installations. New GUI install programs, starter packs, and loadpack GUI. All of which operate without compromising the integrity of the base system. 

It is not a priority to know what is going on in each remaster. Nor is it a goal to support remasters at the expense of the integrity of the base system.

A properly created remaster which supports all normal operations of the Tiny Core release should be the goal of any public remaster.

[SvOlli]

Yes, I stated that it's broken the way it is now.

The idea I have for making remastering with tczs from ISO possible is the following:

Code: [Select]

--- tce-setup-3.7.1 2011-06-27 14:47:14.712526828 +0200
+++ tce-setup-svolli 2011-06-27 18:37:27.326985309 +0200
@@ -73,7 +73,10 @@
 
 MOUNTPOINTFS="$(grep ${MOUNTPOINT} /etc/fstab | awk '{print $3}')"
 if [ "$MOUNTPOINTFS" == iso9660 ]; then
-  echo "Request for ${MOUNTPOINT}/${TCE_DIR} ignored. Not supported on Read-Only File System." | tee /tmp/aberr
+  TCEDIR="$MOUNTPOINT"/"$TCE_DIR"
+  LOADFROM="$TCEDIR"/optional
+  TARGETLIST="onboot.lst"
+  [ -e "$TCEDIR"/"$TARGETLIST" ] && for FILE in `cat "$TCEDIR"/"$TARGETLIST"`; do FILE="$LOADFROM/$FILE" && process; done
   TCEDIR=/tmp/tce
 else
   TCEDIR="$MOUNTPOINT"/"$TCE_DIR"
This way /opt/.backup_device is empty, and /opt/.tce_dir contains "/tmp/tce". All I'm offering here is an easier way for remastering, that'll help my work as well.

Greetings,
SvOlli

P.S.: Robert, a link to a hacked up remaster containing the change of tce-setup as an additional initrd is in your pm.

[roberts]

Nothing is currently broken now. All official iso images that are distributed work as intended.

I am aware of such a change. The problem with it is that it then breaks the long standing, actually, original tce boot code. One would expect the tce boot code to work. It will, but then the tce directory on the cd would not be read. Therefore the read-only tce delivery method is not effective as it would be ignored by use of the boot option. To achieve both would require a double scan or scan and boot param check. That effectively penalizes everyone with a slower boot sequence for the sake of a custom "installation" cd.  I am still not convinced.

[SvOlli]

Nothing is currently broken now. All official iso images that are distributed work as intended.

There is where one part of the misunderstanding is: I intended to state that my remix is broken, not Tiny Core. Sorry if that's been misleading.

I too think that there no benefit that justifies the penalty of a "double scan". But in most cases, if someone uses boot options pointing out to a different tce directory, he knows, what he's doing, and probably doesn't want the tczs from CD-ROM anyway, and if he does, he can still install them by commandline to AppBrowser local install.

So at the end of the day, we can agree, that we don't agree. Thinking back about a year, we couldn't agree on booting up using an ntfs-partition for tczs, and it got me to do my remix. Since 3.7, that's now supported with Tiny Core Linux and an additional starter package. Maybe it will be implemented in a year or so, and I get the "told you so"-feeling once again. (Imho, the patch I posted above is a more elegant solution than the "/opt/tce"-initrd one.)

I'll start looking for a way to patch this change in using another initrd.

Thanks,
SvOlli

[danielibarnes]

FWIW, I also have .iso images with a /tce directory. I will share my solution so that it may help others which remaster in the same way. Anyone smart enough to need it (like SvOlli) will understand my script and technique. This injection technique can be used whenever you must modify a file in core.gz and do not (or cannot) simply replace it.

cd /tmp/
mkdir -p etc/init.d/
cat <<EOF > etc/init.d/rcS
/bin/sed s/iso9660/foo9660/ -i /usr/bin/tce-setup
exec /etc/init.d/tc-config
EOF
echo etc/init.d/rcS|cpio -o -H newc|gzip -9 > /tmp/svolli.gz

Then simply add this .gz to your isolinux.cfg in the conventional way. Disclaimer: It works for me with 3.7.1, but it might not in a future release. The intelligent reader will also realize that /etc/inittab could be modified to execute a different sysinit script in order to achieve the same objective and thus leave the rcS symlink intact, but I was lazy.

[roberts]

Support of a remaster and/or posting hacks in this section is way off topic.

[danielibarnes]

Good point. Probably should have been a PM to SvOlli, but I thought others might be interested. The thread is not about a bug, so it truly belongs elsewhere.

[roberts]

It is one thing for advanced users to hack the system and even make their own personal remaster. But a public distribution of a read-only tce directory results in a very discouraging experience for the new or casual user. Lest we forget http://forum.tinycorelinux.net/index.php?topic=9883.0

It is the shared experience of others that drives me to make Tiny Core easier, better, and hopefully not a discouraging experience.

[SvOlli]

I did take a look at my older versions, where loading tczs from cdrom worked. Back then I noticed that problem and did a quick workaround by executing

Code: [Select]

echo /tmp/tce >/opt/.tce_dir in /opt/bootlocal.sh

Sorry for not reporting that back then, but using that workaround instead. It would have saved us a lot of trouble. Nevertheless it worked fine the last couple of months. The tczs were loaded from ISO and I could download new stuff using the appbrowser.

I've updated the script and the ISOs. The boot menu entries containing the ntfs-3g.gz now also contain cdromfix.gz, which in itself contains the patched /usr/bin/tce-setup. It now works the way I'd expect it: download tczs from ISO, if there are no boot options configuring the system otherwise. After the loading of the tczs is completed, the tce directory is switched to ram-disk.

So, the initial bug was already fixed with the release of 3.7, and the fix prevented my old workaround.

Robert, thanks for the discussion.

Greetings,
SvOlli