swapping between vesa and nvidia, what do the gurus use?

[aus9]

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

[aus9]

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

[coreplayer2]

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

[Lee]

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. 

[aus9]

Lee

sends Lee  ....a virtual carton of Becks....the standard price to pay

[Misalf]

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

[gerald_clark]

Use different lst= boot codes to load different sets of tczs.

[Misalf]

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

[curaga]

Use bootsync instead of bootlocal for loading Xorg/Xvesa, that way it will happen in time.

[Misalf]

That worked.
Thanks

[Lee]

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.

[Misalf]

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.

[coreplayer2]

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

Code: [Select]

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)

[Misalf]

[...] 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).

[coreplayer2]

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