Tiny Core Linux
Off-Topic => Archive / Obsolete => Release Candidate Testing => Topic started by: roberts on January 17, 2010, 06:13:28 AM
-
The Third Release Candidate of Micro Core v2.8 (microcore_2.8rc3.iso), is now posted and ready for testing.
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/2.x/release_candidates/microcore/
microcore_2.8rc3.iso
microcore_2.8rc3.iso.md5.txt
Change Log for Micro Core v2.8
rc1:
* Updated tce-load to allow miltiple loading, e.g., tce-load -i *.tcz
* Updated tce-load to drop ".tcz" requirement.
* Updated cd_dvd_symlinks.sh for better multiple cd and dvd devices.
* Cleanup of tce-setup & tce-update of l,m,lm, and ml code.
* Updated tce-fetch.sh to cleanup old dual repository support.
* Updated tce-update to prompt before beginning easy mode batch update operation.
* After much Team testing and input, the upx'ed kernel returns, prior kernel is in distribution files.
* Dropped symlinker by using builtin cp construct.
rc2:
* Updated tce-update for selective interaction via CLI options "query", "list", and "update".
* Dropped dropbearmulti from base.
* Updated rc.shutdown by reverse umount loops to support tcvd virtual drive.
rc3:
This release candidate changes the storage of extensions to a single location, the optional directory located under your "tce" directory. Boot time loadind of application extensions are provided by links into the optional directory. These links are easily maintained with the new OnBoot section of appsaudit. This will better support the trend to use more "OnDemand" items, make it easy to "move" applicatons into and out of the "OnBoot", tce, directory. This also greatly improves systems resources by having a single copy of dependencies. Having a single area to host all extensions & dependencies also greatly improves auditing and both batch and selective updating.
* Updated tce-setup, tce-load, and tce-audit to support new extension support structure.
* Updated 'ab' shell appbrowser for more consistent input handling.
* Updated udev rules for much quicker boot times with loop mount extensions.
* Updated rebuildfstab for faster response.
* Updated filetool.sh to ignore sockets.
* Updated tc-terminal-server typo.
We now have a single directory from which to audit dependencies, perform selective updates, and pick and choose our on boot selection of applications.
New all core elements are now cpio'ed .gz and can be located in the boot directory for loading via your boot loader or can be placed in the main "tce" directory and loaded after boot via tce-setup
Example boot loader stanza for new core elements
label tinycore
kernel /boot/bzImage
append initrd=/boot/microcore.gz,/boot/Xprogs.core.gz,/boot/Xlibs.core.gz,/boot/Xvesa.core.gz quiet noswap vga=773 tce=UUID=aaab6273-4a6c-4118-8eb2-e31a9b31edb3 waitusb=5 max_loop=255
-
New all core elements are now cpio'ed .gz and can be located in the boot directory for loading via your boot loader or can be places in the main "tce" directory and loaded after boot via tce-setup
Do tce-setup load the .gz (initramfs file) or do the core elements exist in two packages, .tcz and .gz ?
/Lars
[fixed quote]
-
Only .gz see the microcore download section. tce-setup has been modded to load the cpio'ed core elements as well as your collection of OnBoot tczs.
-
OK, thanks.
/Lars
-
Loaded the .gz files into the tce directory.
Booted with norestore and flwm loads.
No menu popup with mouse buttons.
Windows have no top or side bar.
Tinycore is fine.
-
You need the latest flwm - maybe it's not posted yet?
-
flwm.tcz & flwm_topside.tcz built for new fltk-1.1.10 in Core v2.8rc3 are now posted in the repository.
These are primarily for use with microcore.
-
That did it. Thanks.
-
booting microcore_v2.8rc3 with norestore in the bootline and encountering following issues:
- bzImage and microcore.gz are in my /mnt/hda1/boot folder; hda1 is a cf-card pluged in a ide/cf cardreader in my computer (imb thinkpad x31);
- all my extensions which should be loaded at boot are in /mnt/hda1/tce; they were not loaded at boot; i have cut and copy them to /mnt/hda1/tce/optional (newly created folder), but they were not loaded either;
- i am using scripts together with /opt/bootlocal.sh in order to execute commands at boot; one of them call a script named 'ln' (which symlinks other scripts to /home/tc) placed on /mnt/hda1; the execution of bootlocal.sh returns that the file 'ln' does not exist; while using
sudo /mnt/hda1/ln or cd /mnt/hda1 && ./ln
mc tells that there is no such a file; it tells me the same while i want to execute other scripts in /mnt/hda1; loading the extensions at the command line with tce-load -i works;
- while loading the X*.core.gz elements with tce-setup:
sudo tce-setup /mnt/hda1/tcz/Xvesa/Xprogs.core.gz
tc tells that there is neither a *.gz.tcz (??) nor a *.tcz extensions; i can't get the core elements loaded using tce-load -i either.
-
alu, Move all your apps from tce to tce/optional.
Run appsaudit and use OnBoot to select which applications you want booted.
I you are not running X, just make symlinks in tce to the programs you want in tce/optional.
Dependencies will be loaded automatically as before.
-
thanks gerald_clark, i did move my extensions from /tce to /tce/optional, but still, they don't load at boot; i have only two tcz extensions which i want to be loaded at boot, there are bash.tcz and kmaps.tcz.
on OnBoot: how do i use it? i still remain with tce-load -i in order to load extensions.
-
OnBoot is an option in the "Apps Audit" program in the control panel.
If you cannot run the control panel, you can make the symlinks mmanually
cd mnt/hdXy/tce
ln -s optional/bash.tcz .
ln -s optional/kmaps.tcz .
-
- all my extensions which should be loaded at boot are in /mnt/hda1/tce; they were not loaded at boot; i have cut and copy them to /mnt/hda1/tce/optional (newly created folder), but they were not loaded either;
/tce should contain symlinks to the extensions in /tce/optional that you require to be loaded at boot
- while loading the X*.core.gz elements with tce-setup:
sudo tce-setup /mnt/hda1/tcz/Xvesa/Xprogs.core.gz
the *core.gz elements should be in /tce (or in /boot and called by the bootloader) and then everything should work by entering "sudo tce-setup" without any argument
-
the *core.gz elements should be in /tce (or in /boot and called by the bootloader) and then everything should work by entering "sudo tce-setup" without any argument
would this mean that the *.core.gz extension must be loaded at boot either by the bootloader or by the tce command? if so, it seems to me that we are loosing the ability not to load the X*.core.gz elements while remaining at the command line with mc, or to load them later. or do i always have the possibility to load the X*.core.gz elements later (i understood Robert's post that way), and if so how should i do that?
-
If you use the boot loader method then you would have two boot stanzas one for full X and the other without.
If you choose to place the .gzs into the base of your "tce" directory, then as before booting base norestore provides the base cli and after boot tce-setup will allow to use full X. This is operationally the same as before.
-
i get it slowly; what i have found until now:
- placing any tcz extension in a /tce directory causes issues; in my machine, those extensions won't be loaded, and then i can't execute any script; so, it seems to be compulsory to place the extensions in /tce/optional directory and to symlink those needed at boot; that was not clear for me;
- placing the core.gz extension in /tce makes them loaded at boot; if i type 'base restore=hda1' in my bootline, X won't be loaded as other tcz extensions symlinked to /tce; i get a prompt line, as i want it, but the command that i have placed in bootlocal.sh (as the one to change the keyboard layout from us to another layout) won't be executed because de corresponding extension has not been loaded
to sum up: if i boot mc without base, and with restore=hda1 in my boot line, i am directly in X; if i boot with base and with restore=hda1, i have to run bootlocal.sh again in order to have the commands that i have written in bootlocal.sh executed; the behavior of 2.8rc2 was for me better, because i can boot without base and with restore=hda1 in my bootline, while keeping the possibility to load the core extension later (with a script), and while having all commands in bootlocal.sh executed at boot.
-
Are you suggesting to load X required extensions without loading X ?
There is no way to know by extension name which extensions would only apply to a CLI envirnoment.
I would think there would be so few CLI only that the way you are doing via /opt/bootlocal is perhaps the way.
-
i should be more accurate:
- with mc 2.8rc2, i was booting with the following bootline:
kernel /boot/bzImage swapfile noicons embed nodhcp restore=hda1 vga=792 quiet
i kept my backup in /mnt/hda1; i had only two tcz extension in /mnt/hda1/tce, which were bash.tcz and kmaps tcz; my *.core.tcz extensions were place in /mnt/hda1/tcz/X/; and these are my commands in bootlocal.sh
loadkmap < /usr/share/kmap/fr_CH-latin1.kmap
/mnt/hda1/ln <---- a script making symlinks to /home/tc
tce-load -i /mnt/hda1/tcz/Nano/nano.tcz
tce-load -i /mnt/hda1/tcz/Mc/mc.tcz
tce-load -i /mnt/hda1/tcz/Links/links-2.2.tcz
after the boot process, i get the prompt and i can work at the command line, or load the core extensions and my wm in order to work in X with the usual tce-load -i command (i am using a script for that).
- with 2.8rc3 i have exactly the same structure except for the *.core.gz extensions which are not in /mnt/hda1/tcz/Xvesa, but in /mnt/hda1/tce; booting mc 2.8.rc3 with the bootline above brings me directly in X; booting mc 2.8rc3 with 'base' in the bootline above brings me at the command line, but won't execute the command in bootlocal.sh; i have first to perform a tce-setup in order for bash.tcz, kmaps.tcz and the *.core.gz extensions to be loaded, and second i have to re-run bootlocal.sh in order to have all commands executed.
I would like to keep the behavior of mc 2.8rc2 while keeping the innovative management of extensions which 2.8rc3 brings.
-
You have already deviated quite a bit from the standard, having each extension in its own directory. The whole point of the new structure is to ensure a single common directory so that updates, whether batch or selective, dependency auditing, etc. can be supported. I can not be expected to support a custom installation via custom user scripts. None of the appsaudit functions would be successful in such a setup.
-
i see, and i have moved to standard placement of extensions; appsaudit is nice; however:
if i want to boot mc at the command line without the *.core.gz extensions loaded, and if i want to keep some commands in bootlocal.sh in order, for example, to keep my keyboard layout loaded at boot without the *core.gz extensions loaded, how should i do it ? i mean, the purpose of mc is to enable the boot without x, and with customized preferences which can be placed in the bootlocal.sh file. Or not?
-
Your directory name should be tce, not tcz.
You can use midnight commander to manage symlinks from tce/optional to tce.
-
If you wish to load some extensions always, even with the base bootcode, just make bootlocal.sh load them first:
tce-load -i /path/to/kmaps.tcz
tce-load -i /path/to/bash.tcz
loadkmap < ....
This shouldn't hurt in a normal boot either, because if already installed tce-load just exits.
-
at gerald_clark: my folder is /tce, maybe i wrote 'tcz', but it's /tce; my tcz extensions are now in /tce/optional; bash.tcz and kmaps.tcz have been symlinked to /tce.
at curaga: yes, this is already what i do with kmaps.tcz; however, you put me on a possible solution: can i do the following?
- i have kmaps.tcz and bash.tcz symlinked from /tce/optional to /tce;
- i place the *.core.gz extensions in /tce/optional;
- i boot mc without base, and with 'restore=hda1' in order to load my preferences;
- i write in my bootlocal.sh the following lines:
loadkmaps < /user/share....
ln -s /mnt/hda1/tce/optional/Xlibs.core.gz /mnt/hda1/tce
ln -s /mnt/hda1/tce/optional/Xprogs.core.gz /mnt/hda1/tce
ln -s /mnt/hda1/tce/optional/Xvesa.core.gz /mnt/hda1/tce
i assume that i can keep my customize keyboard layout, and that i would have the possibility to run 'tce-setup' in order to load the *.core.gz extension when i need to boot into X? (this is a question)
what do you think? (i don't have the possibility to control it by myself right now, sorry)
EDIT: actually, i think that my main concern is that tce-setup seems to look only in the /tce directory, even if you write full path (as for example: tce-setup /mnt/hda1/tce/optional/Xprogs.core.gz returns an error message).
-
.core.gz are not extensions. They are initramfs. tce-setup is not just for core.gz
tce-setup has been in use for many releases.
It has been explained to load your bash and keyboard which are extension via /opt/bootlocal.sh
Change your boot loader to include base
Boot. You have microcore CLI + bash + your keymap.
If you want full X, then run tce-setup, it will load the core.gz from tce folder and your selected tczs via links into tce/optional. You can use MC to update the links for extensions or if in X use appsaudit.
Operationally this is as it was before. Only you never used it before because of your custom setup requiring custom scripts.
-
I'm not at a tc machine to try, but wouldn't bootlocal try to run tce-load as root?
-
@Juanito: I believe that can be resolved with: sudo -u tc tce-load -i ...
-
adding base in my bootline prevent not only to mount Xprogs.core.gz, Xlibs.core.gz and Xvesa.core.gz stored in /tce (that's fine); it also prevents to mount other extensions not symlinked to /tce that i want to mount at boot with such a line like
tce-load -i /mnt/hda1/tce/optional/nano.tcz
in /opt/bootlocal.sh (i don't add sudo because bootlocal.sh is executed with root privileges at boot) for which i get:
tce-load -i /mnt/hda1/tce/optional/nano.tce not found!
if i don't add base in my bootline, nano is loaded and i get no error message.
-
..but the idea of "base" is not to load extensions, no?
-
according to Robert:
It has been explained to load your bash and keyboard which are extension via /opt/bootlocal.sh
Change your boot loader to include base
Boot. You have microcore CLI + bash + your keymap.
so my bootline is:
kernel /boot/bzImage swapfile noicons embed nodhcp base restore=hda1 vga=792 quiet
i keep 'restore=hda1' in order to keep my customized bootlocal.sh at boot. i have kmaps.tcz and bash.tcz symlinked from /tce/optional to /tce. the *.core.gz initramfs are in /tce.
in bootlocal.sh, i have the following lines:
loadkmaps < /user/share.... <--------- in order to load my keyboard layout
tce-load -i /mnt/hda1/tce/optional/nano.tcz
and i get:
tce-load -i /mnt/hda1/tce/optional/nano.tcz not found! (it's nano.tcz, not .tce, sorry for the typo in my last post)
kmpas.tcz and bash.tcz as well as the initramfs have not been mounted (but that was expected). So i get mc CLI without bash and without keyboard.
Again, there is nothing wrong with that; i am just saying that if I put 'base' in the boot line, i have mc without the customized preferences written in bootlocal.sh; and if i drop 'base', i can't have mc CLI + customized preferences, i get mc + *.core.gz initramfs + customized preferences.
So, what do i need to do in order to have mc CLI (without the *.core.gz initramfs loaded) + customized preferences as keyboard layout + some useful applications for me as nano or mc directly at boot? For example, do i have to place the *.core.gz initramfs in the /tce/optional directory, and add the following lines to bootlocal.sh:
cp /mnt/hda1/tce/optional/Xprogs.core.gz /mnt/hda1/tce
cp /mnt/hda1/tce/optional/Xlibs.core.gz /mnt/hda1/tce
cp /mnt/hda1/tce/optional/Xvesa.core.gz /mnt/hda1/tce
in order to load the initramfs with 'tce-setup' if needed? I can't test it now (i am at work), but would appreciate any advice.
-
Ah, Juanito is correct. alu, the base code doesn't prevent manual loading of extensions, my fault for forgetting bootlocal.sh ran as root.
su tc -c "tce-load ..."
instead of mere tce-load would run it as user tc. Try it with the base bootcode.
-
thanks curaga, that solves the problem
-
Just a friendly reminder, release candidates are for public preview and testing only.
Anything can change based on public input before final release or next release candidate.
As such, one should not use release candidates as their primary system.
Thank you for your participation in testing and feedback.
-
After reflecting on feedback from both microcore and tinycore topic areas, regarding both the .core.gz/initramfs change and the vfat/symlinks change.
Here is what I done:
1. Drop symlinks and use a simple text file, onboot.lst, for determining which to load on boot. I have modified tce-load, tce-setup, and appsaudit.
2. Add a new boot code lst=mylist.lst. This will skip the onboot.lst and load up only that which is in mylist.lst I have modified tce-setup.
This should satisfy microcore users that need to 'preload' special extensions, keyboard, etc...,
then after boot can run tce-setup to get full X with onboot specified extensions.
3. Update tc-config to ensure persistent home and/or persistent opt is on a supported Linux file system. If not such boot code(s) will be ignored. I have modified tc-config.
4. Leave usbinstall script as is. Fat support not cut. onboot.lst being a simple text file should present no issues hosted on fat file system.
I feel this will solve most issues and concerns expressed from the combined microcore and tinycore communities' feedback, while also providing even greater flexibility moving forward.
I have coded these changes and am in early testing phase. As such, I will issue a release candidate 4.
Robert