Tiny Core Linux
General TC => General TC Talk => Topic started by: aus9 on October 30, 2012, 03:49:41 AM
-
EDIT I have changed my mode of backup to none.
bootlocal.sh has stripped of everything except the "create your own bootcode"
being lazy I kept the formula in the alsa wiki so contents now:
#!/bin/sh
# put other system startup commands here
RUNME=""
for i in `showbootcodes`
do
case $i in
snd*) RUNME=${i#*=} ;;
esac
done
[ -n "$RUNME" ] && $RUNME
I have a persistent opt
This allows me to have a number of grub2 bootloader entries that go like
menuentry "nv" {
set root=(hd0,msdos2)
linux /vmlinuz tce=sda2 opt=sda2 home=sda2 blacklist=snd_hda_intel tz=UTC-8 lst=nv.lst snd=/opt/nv.sh
initrd /47.gz
}
menuentry "vesa" {
set root=(hd0,msdos2)
linux /vmlinuz tce=sda2 opt=sda2 home=sda2 blacklist=snd_hda_intel tz=UTC-8 lst=vesa.lst snd=/opt/vesa.sh
initrd /47.gz
}
menuentry "test" {
set root=(hd0,msdos2)
linux /vmlinuz tce=sda2 opt=sda2 home=sda2 blacklist=snd_hda_intel tz=UTC-8 lst=vesa.lst snd=/opt/test.sh
initrd /47.gz
}
vesa.sh has only the barest stuff in it but more than the Xvesa.lst
test.sh is subject to frequent changes
nv.lst obviously has more stuff in it and I won't show all .sh files but nv.sh is like bootlocal.sh
#!/bin/sh
/bin/cp -f /opt/nv.conf /etc/X11/xorg.conf
/sbin/modprobe snd_hda_intel model=auto
/usr/local/sbin/alsactl -f /opt/asound.state restore
/usr/local/etc/init.d/dbus start
Naturally what I am trying to do is control environments when I need to swap to do things. And the list files take care of exactly what tczs to load.
edit (3) full pathways should exist for your personal bootlocals but just discovered
you should not use full pathway for tcz lists, which reside under tce
YMMV
-
thought I might add some more explanation to my idiotiness
opt is persistent same as tce
opt contains base files that are used by various "bootlocal" type scripts to copy into the filesystem
This means that the .filetool.lst is kept very basic
tce is where your "onboot" lists are but if you want certain packages for something its list will differ from a more basic list
The purpose of these complications are for my selfish needs, to jump back and forth from vesa to nviidia closed source driver
but you could easily use it to have one user boot with some things and another user use a different set to achieve something different.
Naturally when you first start out, you are likely to copy your onboot.lst and give it a copy name like nv.lst and keep it under tce
Naturally when you first start out, your bootlocal.sh becomes roughly your nv.sh
but you strip bootlocal down to have only the personalised bootcode
I suspect I can't get any support from my lovely team mates if they knew what I do with this, but it works for me
YMMV
The only files to have in .filetool.lst must be files that are universal
To have other files kept, I keep a copy under /opt and use a script to copy into the file system
hope that makes sense
PS if it does make sense, you may like to turn off automatic backups as yours scripts now do that job
edit .profile
export BACKUP=0
-
Good job, interesting variation and yet surprisingly familiar.. Many of my systems employ similar techniques to boot into particular environments.
I find protecting configuration files like onboot.lst, boot.conf and filetool.lst files etc. etc. the biggest challenge in these multi-environment systems. I can't tell you how many of those critical files i've hosed while attempting to make a small correction, so I make backups of them and backups of the backups, then chattr those ;D
-
Sorry aus9 - you've made me think and now you have to pay the price.
<thinking out loud>
I try to stick to a few constraints for personal reasons - some of which I don't even remember right now.
1) I try to keep my boot menu (menu.lst in grub4dos) to one entry per distribution - one for Core, one for CorePure64 and all that across many hardware platforms (I boot from a USB stick on any of several physical hosts).
2) I don't want to have to enter boot codes by hand except in some unusual circumstance.
3) The only persistence I want to use is the tce directory and mydata.tgz
Currently I use a script called whathost to figure out from various system features (blkid, mac or overriding bootcode) what physical host I'm running on and configure Core accordingly. In addition to different hardware, various systems are used for different activities. Since the entire whathost system lives in mydata.tgz, it really doesn't concern itself with what extensions get loaded. I load a few extensions onboot, none ondemand and a list, determined by the host, that are stuffed into a menu to be loaded manually (though I invariably choose the "load'em all" option because I've gotten lazy).
I haven't used the lst= bootcode for anything yet, though it has been on my todo list to play with it some.
I have created, but don't currently use, an extension called onload.tcz that does nothing but execute a script when it is loaded (which, if loaded onboot, is before bootsync runs - even before restore). If the whathost tables and script were included in there, then I might be able to select what extensions get loaded based upon the physical host. (Might there be a simpler way to do host-based extension loading by determining the host in the bootloader and using a calculated lst= boot code?)
How about this:
*) onboot.lst contains whathost.tcz and everythingelse.tcz
*) the install script for whathost.tcz determines the physical host and creates everythingelse.tcz.dep as a symlink to the appropriate list of extensions
*) everythingelse.tcz is a meta-extension existing only to load its deps.
+ #1) I get just the set up I want without having to do anything interactively during boot.
+ #2) I get the whathost system out of my backup, since it doesn't change all that often (but I have to rebuild it every time I add a new host to the tables)
- #1) For those more concerned with a particular purpose or task than with running on different hosts, probably not so effective - the hardware doesn't know which video driver you want.
----
Backup... I currently keep separate copies of mydata.tgz in
/mnt/sdc1/boot/core4.7.4/tce/ and
/mnt/sdc1/boot/core4.7.4/tce64/
but it seems like I ought to just keep one copy in
/mnt/sdc1/boot/core4.7.4/
-----
While I'm mucking around with onload.tcz / whathost.tcz, I think I'll also make a tcz out of my firefox profile. I currently have that locked up in a .tgz file that gets restored at boot time - security/privacy/ad-blocking extensions installed in an otherwise fresh minefield profile... no cookies, no sqlite databases containing who-knows-what, no client side bugs/trackers etc. Any new bookmarks are maintained externally (gotta script that up).
-----
OK. Done thinking for the day. Tomorrow (or Friday) I'll completely overhaul my system, no doubt trashing it thoroughly in the process - its nice to have a spare USB stick, and even nicer to have two. :)
-
Lee
sends Lee ....a virtual carton of Becks....the standard price to pay
-
Hey Lee
Would you mind sharing the script you have in your whathost.tcz?
I'm trying to create a bootcode for choosing Xvesa/Xorg and graphics driver but bootlocal.sh seems to run too late for that matter.
Thanks
-
Use different lst= boot codes to load different sets of tczs.
-
Thats what I have at the moment and it basically works but its very long winded.
I have to adjust every onboot-*.lst manually in case I want to add/remove .TCZs unrelated to Xorg or grapgics driver.
Lee, I might be more / also interested in your onload.tcz.
I understand we cannot check which video driver to use but I'm searching for examples; not a final solution.
Thanks
-
Use bootsync instead of bootlocal for loading Xorg/Xvesa, that way it will happen in time.
-
That worked.
Thanks
-
Misalf - I am stuck on a WIn7 box at the moment but I hope to have some time on my real computer this evening - and if I do, some onload and whathost updates just happen to be on my todo list.
-
Thanks for informing me.
If you feel like you got something worth sharing whenever you're 'done', I'd be glad to learn a little bit from your scripts.
-
I have to adjust every onboot-*.lst manually in case I want to add/remove .TCZs unrelated to Xorg or grapgics driver.
Why manually? Using APPS > Maintenance > OnBoot maintenance will load only the onboot-vesa.lst or onboot-xorg.lst you are booted with, then adjust tcz's as necessary, should never have to adjust onboot*.lst file manually (If I understand the scenario correctly)
Listing various lst=onboot*.lst configurations in your bootloader config file allows to boot either with Xorg or Xvesa, here is a portion of my extlinux config file
LABEL TinyCore32Xo base
MENU LABEL Boot TinyCore32 Xorg base, norestore
TEXT HELP
Boot 32bit Xorg base, norestore
ENDTEXT
KERNEL /tce/boot/vmlinuz-50rc1
APPEND initrd=/tce/boot/core-50rc1.gz loglevel=3 waitusb=5:UUID="c4d1fd25-16d2-41bf-8de4-2986104f99a4" tce=UUID="c4d1fd25-16d2-41bf-8de4-2986104f99a4" lst=base32Xorg.lst tce-norestore
LABEL TinyCore32Xv base
MENU LABEL Boot TinyCore32 Xvesa base, norestore
TEXT HELP
Boot 32bit Xvesa base, norestore
ENDTEXT
KERNEL /tce/boot/vmlinuz-50rc1
APPEND initrd=/tce/boot/core-50rc1.gz loglevel=3 waitusb=5:UUID="c4d1fd25-16d2-41bf-8de4-2986104f99a4" tce=UUID="c4d1fd25-16d2-41bf-8de4-2986104f99a4" lst=base32Xvesa.lst tce-norestore
..and screenshot of Apps with " base32Xvesa.lst " configuration loaded (looks like I have to adjust it to match the current base config)
(https://db.tt/J7wqQghw)
-
[...] will load only the onboot-vesa.lst or onboot-xorg.lst you are booted with [...]
Exactly..
If I want to have a certain application to always start onboot, no matter what graphics driver I use, I would have to edit onboot.lst, onboot-vesa.lst, onboot-nv.lst, onboot-nouveau.lst, onboot-nvidia.lst, onboot-ati.lst, onboot-intel.lst.
I'm now using only onboot.lst which is always handled by Appsbrowser if I install something OnBoot, no lst= boot code but instead a custom boot code checked via bootsync.sh (i.e. video=vesa or video=nv).
-
Oh I see, but while that is an interesting approach.... IMO one driver per onboot file (particularly the Xorg-drivers) is not the intention of lst= boot option
onboot.lst, onboot-vesa.lst, onboot-nv.lst, onboot-nouveau.lst, onboot-nvidia.lst, onboot-ati.lst, onboot-intel.lst
all these should be consolidated in one onboot.lst file, no need to have a different onboot.lst file for different drivers, it's kinda redundant. Nothing wrong with loading all these drivers in one onboot.lst file, the most appropriate driver will be determined by Xorg and used depending on the hardware detected, I believe this is how Xorg functions.
try loading all drivers in one onboot.lst then check the Xorg log to see how Xorg tests each driver selecting the best for your hardware
-
I think you're right but would't that slow down the boot process (a little bit) an comsume more RAM?
The NVidia drivers at least are pretty big (on TC 4.7 I made myelf even bigger extensions from latest drivers via scripts by Rich).
Also I want to be able to specifically choose Xvesa because, at least on my home PC which has a NVidia graphics card, the nv and nouveau drivers seem to be unusable (very poor display performance).
-
Only the modules actually loaded will be in RAM. The extensions will be loop mounted, and reside on flash/disk.
-
Your list above indicates all Xorg drivers (which are the most basic of drivers), the additional few Kb they consume is a moot point IMO
I find the way to reduce boot times with xf86 drivers is intelligently selecting only those which are required for all systems, like xf86-input-xxx .
The other nv, nouveau, etc etc drivers (not likely to support modern hardware anyhow) are all unnecessary when loading up proprietary Nvidia drivers.
When you bring in real proprietary Nvidia and ATI drivers into the mix, this changes perspective somewhat. But I would argue that a few Mb of memory unnecessarily used against several Gb of available memory and the few extra milliseconds it takes to load or mount is almost negligible in today's systems, the upside of this is functionality across many systems. If you are still thinking lst files based on configuration, by now we're down to maybe only two lst options, which is much more manageable Xorg + Nvidia or Xorg + ATI lst files.
Striving for a balance of minimal drivers to support the most hardware configurations is always challenging, but can be done
-
Oh, yes. It's mounted but not loaded into RAM. Silly me..
--
True, I might ignore and not even notice any very little extra boot time or a few KB of RAM (if even used).
Though, my main intention is to get rid of additional .lst files (and the need to remember their names) which have basically the same contents (exept graphics drivers). Furthermore, if I want/need to have an alternate onboot.lst containg a totally different setup of extensions, I might have to create dublicates of all my current .lst files.
Could there be any downside by loading extensions from inside bootsync.sh?
-
Could there be any downside by loading extensions from inside bootsync.sh?
The only downside is that it's slower than when done via onboot.lst (as all lib/module/desktop updates are done for each extension, instead of deferred and done once).
-
If you feel like you got something worth sharing whenever you're 'done', I'd be glad to learn a little bit from your scripts.
'Done' seems like too strong of a word, as this project is kind of on-going. But last night even "started' would be too strong of a word... I had forgotten (but remembered in the nick of time) that it was my mothers' birthday, so I never did get any geekery done.
Maybe tomorrow evening, if the real world doesn't somehow intrude.
-
slower than when done via onboot.lst
Hmm, I indeed noticed booting has slowed down a little bit (3 or 4 sec.) by looking at the uptime value that Conky shows me but I didn't yet tryed to figure out what was causing this. bummer.
Maybe I should edit /etc/init.d/tc-config then and repack core.gz which is totally update unfriendly though.
--
, as this project is kind of on-going.
I guessed so. (: