[solved] Unexpected Restore during bootup in persistence mode

[souren]

I have setup Tiny Core to run on VirtualBox. Now, I wanted to have a persistent home and opt folder, so I modified menu.lst to contain home=hda1 and opt=hda1 as parameters to the kernel command.

I also created the respective folders in /mnt/hda1 (home and opt)

Now, I have an app that I wish to get invoked each time TinyCore reboots, so I copied my_app.tcz file to /mnt/hda1/tce/optional
and edited /mnt/hda1/tce/onboot.lst to include my_app.tcz

Following that, I edited /mnt/hda1/opt/bootlocal.sh to contain sudo my_app

Now, after I reboot the VirtualBox I find the bootlocal.sh no longer contains the line to invoke my_app on bootup..!!!! It seems to have been reset back to the original content....!?!?

Can someone please advice me what I might be doing wrong now...  

[souren]

To add more info, this is what my menu.lst in /mnt/hda1/boot/grub looks like:

default 0
timeout 10
title tinycore
kernel /boot/bzImage home=hda1 opt=hda1 quiet
initrd /boot/tinycore.gz

I just can't figure out why the /mnt/hda1/opt folder keeps getting reset back to default state every time I reboot TC!!?!?

[aus9]

hi

until you get a better reply...I think you have not backed up correctly.

http://wiki.tinycorelinux.com/Backup-check

will show you whats currently in your mydata file....which is what is going to be restored.

2) I am guessing opt is in your mydata file

3) and not sure if you know but you need full pathways in your bootlocal file please.
Normally this file is run by root so there is no need to use sudo but you do need to specify
/usr/local/bin/myapp -switch (switch or parameter if needed)


good luck

[TaoTePuh]

Have you modified /opt/.filetool.lst correctly to your persistent setup?

[souren]

@aus9: Thanks mate...will try that out tomorrow.

@TaoTePuh: I find that the whole /opt folder gets reset everytime I reboot the system. So, that includes .filetool.lst as well...

[TaoTePuh]

Can you please post the content of .filetool.lst? E.g. "cat /opt/.filetool.lst"

[gerald_clark]

You cannot launch interactive programs in bootlocal.sh, only daemons.
If you want to launch a console application add it to /home/tc/.profile.
If you want to launch an X application, you need to create a startup script in /home/tc/.X.d/

[souren]

@TaotePuh: The contents of my .filetool.lst:
opt/bootlocal.sh
opt/shutdown.sh
opt/tcemirror
opt/.filetool.lst
opt/.xfiletool.lst
home

[souren]

It's wierd. I seem to be having the same problem with the .profile file in /mnt/hda1/home/tc!

Does this have anything to do with the fact that I am trying this under Virtual Box...I doubt it!

Why is it that none of the changes I am making to /home and /opt is being maintained after a reboot, althought I am passing home=hda1 and opt=hda1 to the kernel parameter list!?!?

[gerald_clark]

You need to delete all the lines from .filetool.lst and do a save.
The saved files keep overwriting the persistant /home/tc and /opt files.

Please read the wiki articles on persistant home and opt.

[maro]

Yesterday I was just about to comment the same as aus9 did, so I stopped and considered the issue resolved. Have you actually paid attention to what has been posted here? I'm sure that none of this is related to operating in a VM.

At least to myself it is quite obvious that the restoration of your backup file (i.e. 'mydata.tgz') overwrites your persistent '/opt' and '/home' files. The '/opt/.filetool.lst' file still contains the entries of 'opt/bootlocal.sh' and 'home'. The latter explains why you now observe the fact that '/home/tc/.profile' gets overwritten. To check the content of your backup file you could use: tar tvzf /mnt/hda1/tce/mydata.tgz Don't be surprised to see 'bootlocal.sh' and 'home/tc/.profile' to show up there, and the file size and timestamp should indicate that they are the versions that keep on overwriting the ones in '/opt' and '/home'.

I guess you have a few different options in how you can resolve this:

• (1) remove all 'opt/...' and the 'home' entries from '/opt/.filetool.lst'. Please note that the file can't be removed, or be completely empty as it would otherwise lead to a (silent) problem with BusyBox 'tar' (as was identified earlier). Therefore if nothing else would needed to be included in the backup a simple echo ' ' > /opt/.filetool.lst should do the trick.
• (2) Add two entries (of 'opt' and 'home') to '/opt/.xfiletool.lst', in which case you don't need to change anything in '/opt/.xfiletool.lst'. This is a bit "cute" to have files included in one list and excluded via another and might confuse some users that are unaware of it, but it would work.
• (3) If nothing else needs to be restored you could avoid it completely by using the 'norestore' boot code (e.g. by adding it to your bootloader stanza). To be on the safe side I would also remove the 'mydata.tgz' file from 'hda1', and change 'BACKUP=1' in '.profile' to 'BACKUP=0'

In case you are wondering why would one want to keep the backup/restore capability available when using persistent '/opt' and '/home, and therefore not opt for option (3) from above: Well, there are situations when files from '/etc' will need to "survive" a reboot (e.g. when using user passwords), and then backup/restore will be required again.

[souren]

Thanks maro and gerald.

Yes, I did look at aus9's suggestion...and I did try removing all entries from the .filetool.lst

But I am definitely missing something else, because although I deleted all the lines from .filetool.lst they just came back after the reboot! The bootlocal.sh timestamp was also reset back to Sept 13 - which is the timestamp stored in the mydata.tgz.

[maro]

...and I did try removing all entries from the .filetool.lst

But I am definitely missing something else, because although I deleted all the lines from .filetool.lst they just came back after the reboot!

An empty '/opt/.filetool.lst' leads to the (silent) failure of the backup process, which means that the 'mydata.tgz' file reamains unchanged to what it was before the alteration to '/opt/.filetool.lst'. Removing 'mydata.tgz' should help in this situation.

The bootlocal.sh timestamp was also reset back to Sept 13 - which is the timestamp stored in the mydata.tgz.

As was to be expected.

BTW, you might want to consider changing the title of the thread to something more appropriate considering the recent change of tack. This could help other users to find the information more easily in the future.

[souren]

Ok so having a space in .filetool.lst is not enough to trick TC into skipping the restore, becuase I used the echo command that you suggested.

Anyhow, if that is true, then in my last attempt I deleted everything from .filetool.lst except the last line 'home'.

After the reboot...well it's been restored again!!

[souren]

Ok...I am not happy with this solution, but unless I come across a better way of doing it this will have to do I suppose.

I got rid of mydata.tgz so that no restore happens at all...

For the life of me I can't figure out how .filetool.lst is getting reset to the default state...and if that's getting reset...well of course bootlocal.sh and all other files would too! <SIGH>