howto make my_unique_flashkey my working_computer, everywhere?

[frimical]

howto make my unique flash key my working computer everywhere (using other computers as dummy hosts)?

that is, when I boot on a certain machine for the first time, its configuration, when done, is remembered somewhere on the key, and used automatically next time on the same machine.
Any hint?

I have a vague idea:
booting>configuring>saving-a-backup-file-in-a-specific-directory>rebooting> loading my apps for a specific session ( ie any other session might use different apps for the job, thanks for TC flexibility) and so...

maybe there is another better approach?

[roberts]

Double post.
Doube answer.

As for pendrives, you can use the new usbinstall script found in 2.1rc2, which will setup the pendrive using UUID so that you don't run into the issue of on one machine it is sda and on another machine it would be sdb. See FAQ http://www.tinycorelinux.com/faq.html#pendrives

[linus72]

I also had this idea, "how to get apps restored at boot on unknown PC using USB"

there are a couple/3 ways

1)Best option, use UUID and Label the USB, this makes it easy too.

2) Tinycore has a auto-find for tclocal file/folder, good option on unknown PC
is to have a tclocal on usb and it will auto-find it.

3) this way will require reboot
Simply boot tinycore using "superuser" bootcode
at commandline enter "fdisk -l"
and it should display USB name,
now reboot and choose that usb name**

**Simple to make a syslinux.cfg or menu.lst for differing usb names(sdb1, sda1, sdf1, etc)
here is my syslinux.cfg and menu.lst(you will need menu.c32/vesamenu.c32 for syslinux.cfg)

Code: [Select]

label tce-sav2sda1
menu default
menu label ^TCE-Sav2 SDA1
kernel /boot/bzImage
append initrd=/boot/tinycore.gz quiet desktop=jwm restore=sda1 tce=sda1 waitusb=5

label tce-sav2sdb1
menu label TCE-Sav2 SDB1
kernel /boot/bzImage
append initrd=/boot/tinycore.gz quiet desktop=jwm restore=sdb1 tce=sdb1/tce  waitusb=5

label tce-sav2sdc1
menu label TCE-Sav2 SDC1
kernel /boot/bzImage
append initrd=/boot/tinycore.gz quiet desktop=jwm restore=sdc1 tce=sdc1/tce  waitusb=5

and menu.lst

Code: [Select]

title TinyCore_2.0rc2.1-SDA1
kernel /bzImage quiet desktop=jwm restore=sda1/tce tce=sda1 waitusb=5
initrd /tinycore.gz

title TinyCore_2.0rc2.1-SDB1
kernel /bzImage quiet desktop=jwm restore=sdb1/tce tce=sdb1 waitusb=5
initrd /tinycore.gz
etc, etc

Best option is as Roberts said, using UUID and label.

[frimical]

@Roberts
thank you Roberts, but sorry I guess I didn't double post.
( I might not be clear enough. But I understand that both posts are related definitely. the other post was about something like 'leave the hard disks in their deepest sleep and don't wake them up' )

this post is about saving hardware configuration of each different machine that this unique flash (using UUID) might be plugged on. Then, next time, TC identifies the machine and loads the related configuration previously saved on the same key.

@Linus72
thank you for all the helpful info. I think I'm getting closer to what I'm looking for.
ok for 1) , 2)  and 3)

My quest is for PCs specific config. (Apps are easier to reload).
 
I was wondering if there is any trick to make it recognise the PC automagically, then load the related config accordingly, without using a menu option per PC in menu.lst or similar .

I managed to make something work (recognise the key and it's mount point, while using UUID and blkid).

But I wonder if we can:
a) use in the kernel boot options, some user option that will help identify the PC,
or even,
b) in the boot process, a TC function that can extract/identify the PC,
then, restore a configuration file that holds the same name or so...

these are some thoughts, but are they far away from feasability?

 

[linus72]

Puppy Linux has a feature where it will auto scan( two folders deep) at boot looking for pup_save files
and will present you with a menu option to choose which save if more than one.

it also only needs the boot code "pmedia=usbflash" and it will autofind the usb and autofind any
pup_saves on hd/usb.

I am sure TC could implement something similar.

[^thehatsrule^]

TC autosearches for tce/ and the backup by default afaik

[frimical]

@linus72
yes,on  the paper, this puppylinux feature seems good, but many times it  didn't work, and was source of disaster for me  by loading only the first devsave file
it found, or making a  version upgrade when it wasn't asked for.
(by  the way, puppy linux is one of my stable favourite distros, I wished that  it has the good features and flexibility of TC too)

@thehatsrule
a  default  behavior is always welcome unless we need something else, very specific, but  that can  be automatized,resulting in a  default behavior too.

TC (same  for Puppy) uses a unique name for its backup file. We can put each in a different directory, then in a boot menu make  the right choice; but if we have  100  pcs we work  on we need to do it accordingly intheboot menu.

My  quest is  to have a different config file per pc, using a specific name (based on the serial number  of the PC  or so)  dealing only with  hardware configuration only (like display, sound,net etc...);  the set of apps that  a user might  need  for his session areeasily installed (thanx to tce/z);

the problem of backup files is this mixture of hardware  configuration  and apps configuration/preferences. I  think that  must be  possible  to  be separate;. (TC allows some sort  of  fine  tuning )

is there a possibility to  recognize a  PC  individually?

[^thehatsrule^]

Some ideas: Something unique from the hardware could be used... i.e. MAC addresses on NICs.

On the other hand, if you have the systems connected to a network statically, you could use their IP addresses.

[frimical]

ah finally I found what I'm looking for. A small utility that exists also as tce; it's 'dmidecode'.

Informations gathered are more than expected: there is a serial or uuid of the machine itself! great!
I will do some tests to see if my idea is really feasable now.

(à+)

[frimical]

@thehatsrule
yes the MAC address is an option, but thing is if the pc must have an onboard card not an external one when needed...

About 'dmidecode' it worked corretly for me upto a bios dating since 2000. It will work as long as the bios is SMBIOS compatible or an DMI entry point must be present. 5which is not the case for old ones)

Any other thoughts?