Tiny Core Linux
Tiny Core Base => TCB News => Release Candidate Testing => Topic started by: roberts on December 09, 2011, 06:48:15 PM
-
The first 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 relase 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 + (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.
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, 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.
-
Perhaps it changed earlier and I missed it, but ~/.xsession looks to have changed too.
Also, on boot udhcpc runs as "/sbin/udhcpc -b -i eth0 -h host -p /var/run/udhcpc.eth0.pid", but using the panel applet, it runs as "udhcpc -H host -b -i eth0"
-
Please clarify how users and extension makers should use udhcpc and possibly it's PID files.
Is the wifi script a good reference for such stuff (sadly I haven't managed to look at it yet)?
-
did you consider the actual fluxbox version 1.3.2 for your packaging?
-
CorePlus merely contains extensions from the repository. As per our policy please direct extension update/bug fix requests in the apprpriate forum area and directed to the specific extension maker. CorePlus is not to be construed as our distrubution but merely a convience for getting started with Core.
My sole involvement with the extensions was to facilitate the necessary mods to the interface files for 4.2 structural changes.
-
Perhaps it changed earlier and I missed it, but ~/.xsession looks to have changed too.
Also, on boot udhcpc runs as "/sbin/udhcpc -b -i eth0 -h host -p /var/run/udhcpc.eth0.pid", but using the panel applet, it runs as "udhcpc -H host -b -i eth0"
network GUI, typically accessibile from control panel, will have the -p option added in next cut.
.xsession has now added to the opening announcement post. Thanks!
-
A small error in the Сore-4.2r1.iso
Written in isolinux.cfg
append initrd = / boot / microcore.gz quiet
but should
append initrd = / boot / core.gz quiet
-
Hi glareboa
Please use proper syntax when posting commands or parameters. There should be no spaces by
those slashes. Someone who is unaware of this may cut and paste what you have posted only to
find out it does not work.
-
A small error in the Сore-4.2r1.iso
Written in isolinux.cfg
append initrd = / boot / microcore.gz quiet
but should
append initrd = / boot / core.gz quiet
Thanks! Corrected and reposted Core-4.2rc1.iso
-
Hi glareboa
Please use proper syntax when posting commands or parameters. There should be no spaces by
those slashes. Someone who is unaware of this may cut and paste what you have posted only to
find out it does not work.
it is possible that he has used google translate.
/ this / is / a / test / translated / with / google / without / spaces / inserted
-
hope for flwm_topside_unicode :D
-
Looks like some radical changes here, as always tc on the cutting edge..
8)
-
Longer-term is the plan to phase out "TinyCore" completely and have everyone start with Core or CorePlus? When I began using Tiny Core Linux (and maybe even now) it would have been a bit daunting to evaluate Xvesa vs. Xorg, or the merits of the various window managers. Having a TinyCore iso (as 4.2 does) or at least highlighting the equivalent extensions in the CorePlus menu (if the TinyCore iso is eventually phased out) seems like a good idea.
-
Not strictly an issue with 'Core.gz', but rather 'Xprogs.tcz' (and so one could argue whether this belongs to the TCE section instead of the TCB one): In 'startx' (which has now been moved from '/usr/bin' to '/usr/local/bin') there are three hard-coded occurrences of '/usr/bin/xsetup.sh '.
IMHO using a hard-coded path is generally not a good idea, in particular when things are moving around (e.g. '/usr/local/bin/xsetup.sh' in this case). The issue becomes obvious after booting 4.2rc1 with the default option (i.e. 'tc') and then trying to use a different X server, e.g. tc@box:~$ tce-load -wi Xorg-7.6 > /dev/null 2>&1 && startx
/usr/local/bin/startx: line 57: /usr/bin/xsetup.sh: not found
tc@box:~$
-
Longer-term is the plan to phase out "TinyCore" completely and have everyone start with Core or CorePlus?
I think it just happened! But I hear you also, the first look is as much important as the mechanism behind it. Having a xvesa outside of the base keeps core small (ie the magical 10MB goal) whilst providing more choices without interference from base incorporated features.
AISI core plus is a name change for tinycore with a windows manager extention outside of base.
Hopefully this does not mean leaving the initial choice up to a first time core user, as that is likely to turn people away before getting a chance to enjoy the core for what it represents.
Personally I don't fully understand why a user needs to choose a supported desktop environment. It's enough to know that coreplus can be booted with a windows manager or optionally changed at any time in the future. Forcing a new core user to make a choice they know nothing about may be intimidating and counter productive.
-
There are no plans to drop the "prebuilt example of what is possible with Core", TinyCore.iso.
The Core Project will continue to offer both isos MicroCore as well as TinyCore.
The change in 4.2 is to emphasize that our project is not dictating your desktop. Nor does one have a add on their preferred desktop. Using extensions choosing a desktop is just as easy as choosing a browser and without the extra bloat of unused or unwanted software.
I knew from the beginning, that if I offered a tiny CLI distro that it would not get much attention, but a tiny GUI Desktop would.
As users get comfortable using extensions, which is an absolute requirement in all cases, Such extension use is easily extendable to the the desktop GUI. I still get complaints about the default window manager. CorePlus showcases several Desktops, one of which the user may prefer.
The whole concept and philosopy of Core is Choice based on a tiny foundation.
I repeat TinyCore iso is not going away. It will continue to be offered as a working example of a very tiny GUI desktop.
Users may continue to use TinyCore as their main desktop from which to build upon.
4.2 moves the Core Project to a common foundation, which is easier to support both code and forums.
-
Not strictly an issue with 'Core.gz', but rather 'Xprogs.tcz' (and so one could argue whether this belongs to the TCE section instead of the TCB one): In 'startx' (which has now been moved from '/usr/bin' to '/usr/local/bin') there are three hard-coded occurrences of '/usr/bin/xsetup.sh '.
IMHO using a hard-coded path is generally not a good idea, in particular when things are moving around (e.g. '/usr/local/bin/xsetup.sh' in this case). The issue becomes obvious after booting 4.2rc1 with the default option (i.e. 'tc') and then trying to use a different X server, e.g. tc@box:~$ tce-load -wi Xorg-7.6 > /dev/null 2>&1 && startx
/usr/local/bin/startx: line 57: /usr/bin/xsetup.sh: not found
tc@box:~$
Agreed. This is what Release Candidate Testing is all about. 4.2 is a major change. I know have changed some 70+ programs. Surely I am not perfect. Bugs will found and can be addressed
-
Thanks roberts. That's actually the approach I was hoping for. It gives maximum flexibility to users who want it but provides a good example for less-experienced users to build on.
-
Robert, I've taken the liberty to run a quick loop over the "TC extensions" to search for other cases of '/usr/bin' files that have now "gone AWOL" :
tc@box:~$ for E in /mnt/sr0/cde/optional/*.tcz ; do sudo mount $E e ; find e -type f | while read F ; do strings $F | grep '/usr/bin/' | sed "s#^#[$(basename $E )] $F: # ; s#\] e/#] #" ; done ; umount -d e ; done > r
tc@box:~$ sed "s#.*/usr/bin/#/usr/bin/# ; s# .*##" r | while read F ; do [ -f $F ] || echo $F ; done | sort -u | while read F ; do grep $F r ; done
[flwm_topside.tcz] usr/local/bin/flwm_topside_makemenu: # Typically called from/usr/bin/desktop.sh
[Xprogs.tcz] usr/local/bin/screenshot.sh: /bin/sh -c "sleep 1 && /usr/bin/imlib2_grab $filename"
[Xprogs.tcz] usr/local/bin/setbackground: printf '\n[ -x /usr/bin/wbar.sh ] && wbar.sh' >> "$SETBKG"
[Xprogs.tcz] usr/local/bin/startx: [ -f /tmp/xsetup_requested ] && /usr/bin/xsetup.sh
[Xprogs.tcz] usr/local/bin/startx: grep -q $XSERVER $HOME/.xsession || /usr/bin/xsetup.sh booting
[Xprogs.tcz] usr/local/bin/startx: /usr/bin/xsetup.sh
tc@box:~$
Obviously the last three are the ones I had already reported in reply #13, but the others might deserve some TLC.
-
Thanks, extra eyeballs, especially during release candidate testing, are always welcomed ;)
-
TC here to stay, cool. glad we got that cleared up
-
I'm using TC 4.1 on a notebook. There are three partitions, /dev/sda1 is ext4 others or NTFS (for Vista). There is a /tce directory on sda1. TC is booted from USB stick created with Unetbootin. Works fine, this setup is used for extension building, testing, etc.
Now created a stick on the same way with 4.2rc1
Starting tc with base norestore brings up the system with usual tc look and works.
Starting with norestore ends up in infinite 'Checking for extensions... ' with rotating chars.
Doesn't like my collection of extensions.
-
Next test, I created a tce dir on sdb1 which is the USB FAT32 partion booting from and used
tinycore waitusb=5 tce=sdb1 norestore
expecting to hava a clean TC-like system using a /mnt/sdb1/tce to store downloaded extensions. But the result is just a command prompt.
-
If you use an Ext2 filesystem, what happens?
-
If you use an Ext2 filesystem, what happens?
Do not want to use ext2. It is working fine in TC 4.1 and no reason to drop this functionality.
-
If you use an Ext2 filesystem, what happens?
Do not want to use ext2. It is working fine in TC 4.1 and no reason to drop this functionality.
+1
(even though this is not an answer to the original question)
-
Testing it with Ext2 is just a way of narrowing down the cause.
If it works ok with Ext2, something has malfunctioned as a result of fat32.
If it does not work ok with Ext2, that is not the cause of the problem.
Knowing this may help resolve it.
-
You are free to make such test if you are interested in result :)
-
With a common foundation, being core.gz, base norestore will result in a command prompt.
As noted in the announcement post is xbase.lst, i.e., using lst=xbase.lst norestore will result in a base X/GUI system.
xbase.lst is delivered in the TinyCore iso and should be copied to your working tce directory. Of course it is editable and therefore as a benefit "base" can mean Xorg & jwm as an example, or even, Xorg/XFCE. Whatever is "your" base X/GUI.
-
I'm using TC 4.1 on a notebook. There are three partitions, /dev/sda1 is ext4 others or NTFS (for Vista). There is a /tce directory on sda1. TC is booted from USB stick created with Unetbootin. Works fine, this setup is used for extension building, testing, etc.
Now created a stick on the same way with 4.2rc1
Starting tc with base norestore brings up the system with usual tc look and works.
Starting with norestore ends up in infinite 'Checking for extensions... ' with rotating chars.
Doesn't like my collection of extensions.
Use boot option showapps to display each extension as it is being loaded should help in resolving this issue.
-
"Flash10.tcz is presently installed. Running this ..... y/n "
It is waiting for user input :)
Removing it from onboot list system starts with X, but screen is shifted, bottom 20% and right 20% cca. is blank. upper left corner is out of screen. Exit to prompt gives blank screen with no cursor, no prompt.
OK, maybe this test is not fair as I'm testing with an exiting tce dir, but do not see reason why it doesn't work with norestore
-
You might try the auto button on your monitor.
-
Relating to the booting lockup -
I added a timeout for the getFlash11.tcz that will exit and allow booting to continue. I thought I also added it to getFlash10, but I just did now, so an update would allow it to remain in onboot.lst.
-
You might try the auto button on your monitor.
It has nothing to do with the monitor.
BTW there are no such button on my notebook.
-
Tried TC on a different machine with no additional TCE dir with the USB stick used with notebook, see above. I get only a command prompt, no graphical interface.
-
My monitor has an auto button to auto set the size and phase. Originally you did not say you had a laptop.
-
My monitor has an auto button to auto set the size and phase. Originally you did not say you had a laptop.
Yes, I told. But doesn't matter. Issue is not created by the lack of a button.
-
How to upgrade from 4_1 (not working for me..) to 4_2?
Seems to be a headache with the amount of modification..
Startpoint is 4_1 Microcore and Xorg7_4 (and all others for looking like TCL).
When indicated; I will test.
-
Tried TC on a different machine with no additional TCE dir with the USB stick used with notebook, see above. I get only a command prompt, no graphical interface.
Results would depend on how installed. Use CorePlus for easy way for frugal or pendrive.
If manual or 3rd party results in no tce directory and only core.gz then a basic microcore is to be expected.
From the announcement post:
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 + (user's choice of Window Manager) + (optionally wbar.tcz)
Obviously tcz extensions are located in the tce directory.
-
How to upgrade from 4_1 (not working for me..) to 4_2?
Seems to be a headache with the amount of modification..
Startpoint is 4_1 Microcore and Xorg7_4 (and all others for looking like TCL).
When indicated; I will test.
If your starting point is 4_1 Microcore and Xorg7_4 then not difficult at all.
Replace microcore.gz with core.gz and be sure to update the files likely in your backup and ondemand (if any).
Update extensions from the release candidate area as explained in the announcement.
From the announcement:
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.
-
Robert,
if user has only Windows and downloaded ISO, how to create a bootable USB stick?
-
That's easy! maybe this is missing the point but, use Universal-USB-Installer (http://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/) Select "Unlisted Linux ISO (New Syslinux), the ISO and the usbdrive and it's done.
-
Did you try it with 4.2rc1?
-
Hang on..
-
Robert,
if user has only Windows and downloaded ISO, how to create a bootable USB stick?
CorePlus is a bootable isohybrid image. This means booting from cdrom or usb pendrive is supported.
Such user has two choices to use our provided installation tools,
1. Burn cdrom from CorePlus iso, boot CorePlus, select install choices.
2. Write the CorePlus.iso directly to pendrive, boot CorePlus from pendrive, and install to another pendrive with their choices.
I see many options for Windows users that are basically equivalents to nix dd command. I will leave recommendations to community members more familiar with Windows.
I am puzzled why now? CorePlus is a replacement for MultiCore with a much improved installer. The same methods to boot MultiCore apply to CorePlus. In fact, the genesis for MultiCore was with Windows and no net access users to get started with Core.
-
Did you try it with 4.2rc1?
yes it works great
-
Perhaps the issue is the booting of TinyCore-4.2rc1.iso and not the CorePlus iso.
I did not add the waitusb=5 to the default on TinyCore iso. In fact it *is* missing lst=xbase.lst which I will add.
But to boot the TinyCore iso from a dd'ed pendrive, or unetbootin, simply add the following two boot params.
lst=xbase.lst waitusb=5
HTH
-
I booted CorePlus with 'tce=sdb1' option.
The optional directory was created root.root and tce-load -iw was unable to download into it.
-
It would be nice if there was an additional CorePlus boot option that was just 'quiet waitusb=5'
After I dd CorePlus to a thumb drive, I like to add another partition with a custom tce directory.
-
Perhaps the issue is the booting of TinyCore-4.2rc1.iso and not the CorePlus iso.
I did not add the waitusb=5 to the default on TinyCore iso. In fact it *is* missing lst=xbase.lst which I will add.
But to boot the TinyCore iso from a dd'ed pendrive, or unetbootin, simply add the following two boot params.
lst=xbase.lst waitusb=5
HTH
Of course waitusb was there. Adding lst=xbase.lst result is the same.
-
Booting CorePlus with X/GUI no extensions (aka TC) from USB stick (sdc1) tce dir is in /tmp even if I have a tce dire manually created in the root of sdc1 (VFAT). tce=sdc1 has no influence.
Is it possible to setup a permanent tce dir as with previous versions?
-
You should be using TinyCore.iso.
boot: tc waitusb=5 tce=sdc1
Works as expected.
Your specs to CorePlus was no user extensions, i.e., lst=xbase.lst, therefore no user extensions were loaded.
-
It would be nice if there was an additional CorePlus boot option that was just 'quiet waitusb=5'
After I dd CorePlus to a thumb drive, I like to add another partition with a custom tce directory.
Typically dd'ing the iso image to a pendrive:
dd if=CorePlus-4.2rc1.iso of=/dev/sdb bs=1M
results in a read-only device.
Unless you are using a different scheme dd'ing into a partition and messing with the boot record. Otherwise I am not following.
-
Yes, but if you select the last option to boot cmdline only, you can add a partition, format it ext2, create a tce directory, and reboot.
Now when you edit the last boot option, remove the 'base' option, add 'waitusb=5' and boot, the second partition is mounted rw.
You can now mount the first partition and copy the desired Xprogs,Xlibs,Xvesa, window manager to the second partition, create an onboot.lst.
Now you have a custom boot partition that you can tce-load into for a utility boot.
The only thing missing is a boot selection that has "quiet waitusb=5" as the only boot options.
-
Booting CorePlus already searches for user tce directory and loads user extensions first before loading the extensions provided on the CorePlus media. This is done for two reasons:
1. User stored Extensions on a live drive will always be more recent than the "snapshots frozen" in the CorePlus iso.
2. Rarely used extensions in the CorePlus iso can easily be AppBroswer/Load Local when such might be needed.
CorePlus is not only an installation image but a utility resource for an existing system.
-
The only menu option that finds the tce directory is "BootCore to command line only. No X/GUI or extensions", and
then only if I remove "base" and add "waitusb=5".
-
Case 1.
sda1 is a live working system from established tcedir on linux filesystem.
Booting CorePlus from sdb1 pendrive, finds and loads all extensions from sda1 before the CorePlus utility extensions.
Case 2.
I purposely rename the tce directory on sda1 so as to disable CorePlus from finding it.
I insert a second pendive with a FAT32 fielsystem and a tce directory.
Booting CorePlus from sdb1 finds and loads all extensions from sdc1 (second pendrive) before loading the CorePlus utility extensions.
Works as described and expected.
Would need more details to try to reproduce other than expected results.
-
I do not misunderstand how CorePlus works.
I boot core plus from sdb1 using any of the first seven offered selections.
I have a tce directory on sdb2. It is not found.
This is because sdb2 cannot be mounted if sdb1 is mounted.
I select the eighth selection "BootCore to command line only. No X/GUI or extensions" and hit the tab key.
I delete the "nobase" option and add "waitusb=5"
My tce directory is found, my extensions are loaded, and my backup is restored.
This is because sdb1 is not mounted, so sdb2 can be, but only if there is no "nobase" option.
I would like to have a core plus thumb drive, but don't want to waste the whole thing with just one 50M partition.
I would like to use the rest of the drive for a full core system.
I can only do this if I manually edit the options at each boot.
My suggestion is that it would be nice to have another boot selection:
"BootCore and scan for tce" that only has the boot options: "quiet waitusb=5".
-
The whole point of offering these installation tools is to avoid manual setup.
However for the sake of using a disk image iso dd'ed onto a drive and then manual setup a second partition on the same drive.
On a single pendrive
Case 3:
1. dd if=CorePlus-42.rc1.iso of=/dev/sdb bs=1M
2. fdisk /dev/sdb
3. Create 2nd Linux partiion on the remaining unused drive.
4. hdparm -z /dev/sdb
5. mke2fs /dev/sdb2
6. mount /mnt/sdb2
7. mkdir -p /mnt/sdb2/tce/optional
8. chown tc.staff -R /mnt/sdb2/tce
9. copied sample extension, ace-of-penguins, to tce dir on sdb2 and onboot.lst
10 reboot.
Boot with no other drive with a tcedir other than sdb2 with CorePlus on sdb1
Works as expected with boot options 1-7. sdb2 scanned found mounted and ace-of-penguins loaded.
Followed by sdb1 mounted and CorePlus utilites mount loaded. Both sdb2 and sdb1 mounted in that order.
I am still unable to reproduce your case. You must be doing something else.
-
You should be using TinyCore.iso.
boot: tc waitusb=5 tce=sdc1
Works as expected.
Boots to command prompt, no graphics. startx command doesn't exist.
/mnt/sdc1/tce created. ab works as expected, using /mnt/sdc1/tce
All together tc waitusb=5 tce=sdc1 leads to mc instead of tc. WIthout tce=sdc1it boots to usual TC.
-
Hi bmarkus
On the off chance that it might be timing related, does extending the waitusb time a little change
anything?
-
Hi bmarkus
On the off chance that it might be timing related, does extending the waitusb time a little change
anything?
No.
-
I still think it is a timing issue. If you would, please use the LABEL option on your sdc1 together with the waitusb, e.g.,
waitusb=30:LABEL=MySdc1Label tce=sdc1
You won't have to wait 30 seconds only long enough for LABEL to be found, i.e., sdc1 to become ready.
-
I am still unable to reproduce your case. You must be doing something else.
And neither am I.
I tested this yesterday ( or so I thought ).
It is working today.
I would like to blame it on the late hour and diminishing pigment in my hair.
Sorry for wasting your time and bandwidth.
I think I will redo the second partition starting at 50M or so to provide a little more room
for updating the CorePlus partition with possibly slightly larger future versions.
I have been doing a lot of testing, and 4.2 is really nice.
Thanks.
---------------------
Revisiting this post, as I was not mistaken in what I was trying to explain.
There is no boot selection that does just "quiet waitusb=5"
The first 7 containe 'cde' and/or 'lst=xbase.lst' causing CorePlus preselected packages to be loaded.
The last contains 'base' which prevents packages from being loaded.
You are correct in how CorePlus is booting.
My request was for an entry that contains 'quiet waitusb-5' so that the pen-drive can be used to boot an existing tce configuration on another
drive or partition without including the contents of the cde directory.
I will just tab edit the last entry when booting.
-
I still think it is a timing issue. If you would, please use the LABEL option on your sdc1 together with the waitusb, e.g.,
waitusb=30:LABEL=MySdc1Label tce=sdc1
You won't have to wait 30 seconds only long enough for LABEL to be found, i.e., sdc1 to become ready.
Drive found in 2 sec, result is the same, no GUI.
-
1. When arrived at system prompt, please provide the results of showbootcodes
2. What filesystem is on sdc1? Does fdisk -l show clean partition table for this drive?
3. Does booting with showapps pause display any extensions from sdc1?
-
Where can I find the new
.setbackground
.profile
.xsession ?
In the ISO? In this case, could you please put them in the distribution_files?
I am making an upgrade from mc2_1 + Xorg74; so, downloading the ISOs is perhaps not necessary (normally...)
-
They are in /etc/skel.
-
My request was for an entry that contains 'quiet waitusb-5' so that the pen-drive can be used to boot an existing tce configuration on another drive or partition without including the contents of the cde directory.
Now that we are on the same page. Request granted! :)
-
Sometimes we get caught up in the details, especially after such a magnificent effort.
Thanks !!
-
They are in /etc/skel.
no /etc/skel in the coreplus 4_2rc1 ISO..
-
Boot, and look in /etc/skel.
-
1. When arrived at system prompt, please provide the results of showbootcodes
2. What filesystem is on sdc1? Does fdisk -l show clean partition table for this drive?
3. Does booting with showapps pause display any extensions from sdc1?
1) initrd=/boot/core.gz quiet cde waitusb=10 tce=sdc1 showapps pause BOOT_IMAGE=/boot/vmlinuz
2) FAT16 (Id 6), clean
3) No
-
Just tested a fat16 sdc1 no issues here. Works as expected.
How did you install TinyCore-4.2rc1.iso to pendrive?
What are the base directories on the partition that you booted from?
Should be two base directories:
boot/
cde/
-
I believe the default .filetool.lst can now be simply:
opt
home
And the following can be removed from .xfiletool.lst
opt/.tce_dir
-
Where can I find the new
.setbackground
.profile
.xsession ?
In the ISO? In this case, could you please put them in the distribution_files?
I am making an upgrade from mc2_1 + Xorg74; so, downloading the ISOs is perhaps not necessary (normally...)
If you boot up with the "comparerestore" boot code you can look at the files from your backup and the updated files in Core side by side. The files from you backup will have the normal file name, and the files included in the base Core system will have the file name plus ".orig_file"
For exmaple,
.profile - This is the file from your backup
.profile.orig_file - This is the file included in the base Core system
-
Just tested a fat16 sdc1 no issues here. Works as expected.
How did you install TinyCore-4.2rc1.iso to pendrive?
What are the base directories on the partition that you booted from?
Should be two base directories:
boot/
cde/
Installed with Unetbootin in fresh formatted stick. There are boot and cde directories and tce showing that tce=sdc1 was recognized.
Test repeated
- with two USB sticks
- on two different machines
- with another installer
- ISO checked against md5
Result is the same.
-
Burned TinyCore CD, result is the same. Issue is not related to USB.
-
Burned CorePlus CD, result is the same.
It is the point where I give up testing 4.2rc1
-
I Xprogs.tcz still needed for X to work? If so, could you please consider breaking out the essential parts to a new extension, leaving just the user tools in Xprogs.tcz?
-
I believe the default .filetool.lst can now be simply:
opt
home
And the following can be removed from .xfiletool.lst
opt/.tce_dir
Agreed. Done. Thanks!
-
I Xprogs.tcz still needed for X to work? If so, could you please consider breaking out the essential parts to a new extension, leaving just the user tools in Xprogs.tcz?
Is your suggestion to refactor Xlibs & Xprogs so that Xlibs is all that *is* required to run X.
Leaving Xprogs with only FLTK libs and the custom FLTK GUIs?
-
Yes :)
-
Let me test a proto-type.
-
Now there is some light in the tunnel booting from CorePlus CD, X/GUI no extensions.
On a notebook it works, boot messages:
...
Skipping regular Ext.....
XVesa Xlibs ...
Setting keymap...
...
On my desktop where all tries fail:
...
Skipping regular Ext.....
Done
Setting keymap...
...
-
I Xprogs.tcz still needed for X to work? If so, could you please consider breaking out the essential parts to a new extension, leaving just the user tools in Xprogs.tcz?
Is your suggestion to refactor Xlibs & Xprogs so that Xlibs is all that *is* required to run X.
Leaving Xprogs with only FLTK libs and the custom FLTK GUIs?
Will be available in rc2.
-
Now there is some light in the tunnel booting from CorePlus CD, X/GUI no extensions.
On a notebook it works, boot messages:
...
Skipping regular Ext.....
XVesa Xlibs ...
Setting keymap...
...
On my desktop where all tries fail:
...
Skipping regular Ext.....
Done
Setting keymap...
...
How is your desktop hard drive differ from notebook?
-
How is your desktop hard drive differ from notebook?
Desktop:
Disk /dev/sda: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 15170 121852993+ 7 HPFS/NTFS
/dev/sda2 15171 30401 122343007+ 7 HPFS/NTFS
Disk /dev/sdb: 400.0 GB, 400088457216 bytes
255 heads, 63 sectors/track, 48641 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 * 1 24320 195350368+ 7 HPFS/NTFS
/dev/sdb2 24321 48641 195358432+ 7 HPFS/NTFS
Notebook:
Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 1 1095 8795556 83 Linux
/dev/sda2 * 1275 10334 72774450 7 HPFS/NTFS
/dev/sda3 10383 19458 72892416 7 HPFS/NTFS
/dev/sda4 1096 1274 1437817+ 82 Linux swap
Partition table entries are not in disk order
[/font]
-
Ah NTFS. NTFS support is deprecated starting with 4.2
core.gz is not able to mount cde on NTFS to continue loading. However. the cde directory should only reside on iso and not be copied to any hard drive. Adding the X/GUI extensions to where your normal TCE directory resides will solve your issue, and is the expected location. This way individual updates to the X/GUI will occur as for any regular extension.
-
Ah NTFS. NTFS supported is deprecated starting with 4.2
core.gz is not able to mount cde on NTFS to continue loading. However. the cde directory should only reside on iso and not be copied to any hard drive. Adding the X/GUI extensions to where your normal TCE directory resides will solve your issue, and is the expected location. This way individual updates to the X/GUI will occur as for any regular extension.
Nothing is installed on NTFS, these are just reside inside of the box. See earlier posts, CorePlus CD doesn't boot to X/GUI as it doesn't load CDE from the CorePlus CD
-
Then I don't undetstand when you wrote earlier...
Skipping regular Ext...
from your desktop.
Add whatever X/GUI you want to your regular extensions.
Update. Went to visit friend with an Windows XP NTFS machine.
I took a TinyCore-4.2 and a CorePlus-4.2 both on cdroms.
Both cdroms booted to X/GUI as expected.
If I cannot reproduce then I cannot address.
-
How about permission denied errors when installing extensions in core using ab
"wget : can't open whatever_app.tcz : permission denied
all appsan md5 txt files, yet I can access info files. I'm suspicious that the tce local directory has not been defined..
Also how to install extensions using ab when the extensions are not in repo but are "locally" stored. ie already copied to optional directory?
edit: perhaps " tce-load -i /mnt/sda1/tce/optional/app.tcz?"
-
ab works fine. Check your tce directory permissions. For a new tce directory there was a bug; fixed in rc2 where new tce directories were created root.root.
Loading from a local directory with tce-load -i , you don't need the full path when target is tcedir.
-
Yes thanks root:root was the main issue, changed it to tc:staff and is functional, however am still getting random 404 and 416 errors with wget.
also had to add a tcedir file with the correct path as none had been created.
also created a onboot.lst file and added the extensions
core is functional albeit minor ab connection issues
tce-audit works great though.
-
Update. Went to visit friend with an Windows XP NTFS machine.
I took a TinyCore-4.2 and a CorePlus-4.2 both on cdroms.
Both cdroms booted to X/GUI as expected.
It has nothing to do with NTFS or drives, partitions. Disconnecting HD's physically keeping only DVD drive connected, no USB result is the same booting from CD.
-
Then I don't undetstand when you wrote earlier...
Skipping regular Ext...
from your desktop.
Just copied boot messages from the screen. This 'Skipping...' message is there in both cases, on desktop and notebook. See original message.
-
Thanks for your patience bmarkus. This is clearly a nasty one should it end up in the release.
-
Thanks for your patience bmarkus. This is clearly a nasty one should it end up in the release.
No problem I'm an IT professional. It's like my daily job :)
Let me know how can I help to find this ugly and dirty daemon.
-
"Skipping extensions... "is triggered by the boot option 'base'. In your case it needs to be determined from where that code is being sensed. Let's continue testing with rc2.