Retaining alsamixer settings between boots

[SamK]

In OnBoot is alsa, alsa-oss and alsamixergui.  The mixer settings are lost between boots.  How to preserve them?

I am using persistent home, opt and tce on USB flash drive and not using TC backup when exiting.

[tinypoodle]

See info alsa.tcz

[SamK]

See info alsa.tcz

Tried alsactl store without success.

Not sure if it is necessary to start from bootlocal.sh as alsa initializes OK without it - but tried it anyway.  Again no success.

Is this meant to work as described when persistent storage is being used and backups are not run By TC on exit?
 
 

[tinypoodle]

See info alsa.tcz

Tried alsactl store without success.

Code: [Select]

alsactl restore -f /path/to/stored/statefile


[SamK]

The issue seems to be that the guidance in alsa.tcz favours users not using persistent storage and therefore backing up their data at the end of each TC session.  As I am using persistent storage the advice is not appropriate.

alsactl store by default creates /etc/asound.state.  This is in a non-persistent location and therefore does not survive between boots. 

I can see a couple of ways around this:

• Backup at TC close (which is unsuitable for my purposes)
• Save the output of alsactl store to /home/tc/.alsacfg/asound.state
  From /etc/bootlocal.sh run alsactl restore -f /home/tc/.alsacfg/asound.state

If this works, perhaps it might be added to the notes in alsa.tcz
 

[tinypoodle]

The issue seems to be that the guidance in alsa.tcz favours users not using persistent storage and therefore backing up their data at the end of each TC session.  As I am using persistent storage the advice is not appropriate.

alsactl store by default creates /etc/asound.state.  This is in a non-persistent location and therefore does not survive between boots.

Looks to me like your issue after all is more semantical than technical and generally about persistence of files in e.g. /etc rather than about alsa per se. If i understand correctly it is you NOT using any persistent storage for anything in /etc. Just for example: checking now i found i have 6 entries starting with "etc/" in my .filetool.lst - another classical one would be "etc/X11/xorg.conf" - and 1 in "usr/local/etc/"; that's where system wide configurations are stored.

I can see a couple of ways around this:

• Backup at TC close (which is unsuitable for my purposes)
• Save the output of alsactl store to /home/tc/.alsacfg/asound.state
  From /etc/bootlocal.sh run alsactl restore -f /home/tc/.alsacfg/asound.state

Suggestion: you could backup your customized /etc files to ~/.local/etc/ and then write a script to link them back to /etc/ at boot time.

If this works, perhaps it might be added to the notes in alsa.tcz

I can't see why this shouldn't work and after reading the info of alsa.tcz once again I  respectfully disagree with upper suggestion, as the instructions are very generally worded and IMHO giving examples of implementation for particular scenarios within an extension .info would rather lead to confusion than to clarification.

[roberts]

You decided what is in your backup! You could just an easily specify only  those non-persistent areas as shown in the .info file to have persistence and backup. Alternately you could make a tiny custom my_alsa_setting.tcz extension.

[SamK]

Looks to me like your issue after all is more semantical than technical and generally about persistence of files in e.g. /etc...

We may simply have to accept differing views on this.  My interpretation of persistence is the one given in the Core Concepts document which has been my reference.

Backup/Restore and Other Persistence Options:
...Tiny Core supports persistent/permanent:
Backup and Restore of personal settings, and
Persistent /home and /opt directories.

I feel this is indicating a difference between backup and persistence.  Backup is used to preserve the data in volatile storage areas between boots as the file and directory structure is destroyed at the end of the session.  Persistent storage is not destroyed but remains unchanged and available at the end of the session.  They are different mechanisms of ensuring the continuity of data depending on whether the storage is volatile or persistent.
My understanding is that only /home and /opt can be persistent in this way unless the hybrid/local install method is used.

...
When using the home boot code, mydata.tgz is not created - personal data backups must occur in a more traditional way.
...

This reflects my situation, the bootcode is used and persistent /home is created.

If this works, perhaps it might be added to the notes in alsa.tcz

I can't see why this shouldn't work and after reading the info of alsa.tcz once again I  respectfully disagree with upper suggestion, as the instructions are very generally worded and IMHO giving examples of implementation for particular scenarios within an extension .info would rather lead to confusion than to clarification.

The guidance in alsa.info will work as described for those using volatile storage alone as filetool will be used to create a backup.  The advice is less suited to those implementing the guidance in Core Concepts referring to persistent storage and backups.  The suggestion to amend alsa.tcz is intended to help this latter group.

It is good to have different opinions expressed; after all that is what a forum is all about.  Thanks for your suggestion to use alsactl restore as it had not occurred to me. As is often the case there can be many ways to resolve a problem and your input helped.

...You could just an easily specify only  those non-persistent areas as shown in the .info file to have persistence and backup. Alternately you could make a tiny custom my_alsa_setting.tcz extension.

Yet more examples of the multiple ways to resolve an issue.
 

[Jason W]

Since info files are geared towards those new to an extension, one simple and standard example is the way to go as I agree that multiple examples often would just lead to confusion.

I remember a time when folks and even myself were seeing issues with restoring alsa settings between reboots using the /usr/local/etc/init.d/alsasound script along with a backed up /etc/asound.state file.  Not sure if it was a timing issue or what, and I have not seen it happen in a long time.  But I see at least on my machine now that simply using "alsatcl -f /path/to/file store" before reboot and "alsactl -f /path/to/file restore" after rebooting, it works and restores alsa settings without the use of the /usr/local/etc/init.d/alsasound script.  So this may be an alternative method that can help.

The main reason for the alsasound script was to insert the proper kernel modules, which udev seems to handle now anyway, though I am sure there are cases with certain hardware the script needs to be run.  But at least here, a simple use of the alsactl store and restore is all that is needed to set up alsa between sessions, so I will make a mention of it in the info file.

[tinypoodle]

But I see at least on my machine now that simply using "alsatcl -f /path/to/file store" before reboot and "alsactl -f /path/to/file restore" after rebooting, it works and restores alsa settings without the use of the /usr/local/etc/init.d/alsasound script.  So this may be an alternative method that can help.

There are plenty of scenarios where using "alsactl -f /path/to/file restore" manually can be to great benefit:

• on resource challenged PC's one might only decide to load alsa in TC when it becomes really needed (as opposed to boot time).
  That of course is only if one is not too keen to be greeted by Bethooven's 5th or similar as could be default by various deskbloat environments 
• Porting same set of config files (e.g. mydata.tgz) between multiple PC's, e.g. having asound.state.Toshiba and asound.state.Thinkpad
• But most convenient for many users: Having several pre-configured mixer settings for different purposes, e.g. asound.state.VoIP, asound.state.playback and asound.state.record. "/etc/asound.state" is just a default path for convenience, but by no means compulsary.

[aus9]

hi

I would like to thank all members for their comments as I found this post by search.

however, it appears SamK did not use

Code: [Select]

sudo alsactl store
 as we need root powers to write to /etc.

[SamK]

Hi aus9

hi

I would like to thank all members for their comments as I found this post by search.

however, it appears SamK did not use

Code: [Select]

sudo alsactl store
 as we need root powers to write to /etc.

There seems to be some confusion here, perhaps I can help with a little clarification.

You are correct in observing that the use of sudo is required; behind the scenes I had also used sudo without success.  This was due to the persistent storage configuration used on the machine, allied to the information in the wiki Core Concepts document.

I was trying to highlight that when following the guidance in Core Concepts (particularly persistence and storage), a user would not be able to follow the advice in alsa.tcz.info to make the alsa settings persist between reboots.  Jason has subsequently added further guidance to the alsa information which can be used by those with persistent or non-persistent storage.
 

[tinypoodle]

You might wanna have a look at http://forum.tinycorelinux.net/index.php?topic=6943.0 in order to determine which files in /etc (and possibly other root dirs e.g. /usr) to save/backup 

[SamK]

You might wanna have a look at http://forum.tinycorelinux.net/index.php?topic=6943.0 in order to determine which files in /etc (and possibly other root dirs e.g. /usr) to save/backup 

You point to a fine piece of work. It gets a list of files from mydata.tgz, presumably created by filetool.lst. In the terms of this thread this may have limited the value of the script.

For this particular purpose filetool.lst and mydata.tgz are not used; this also correlates with the guidance given in Core Concepts relating to the backup of persistent storage.

...
When using the home boot code, mydata.tgz is not created - personal data backups must occur in a more traditional way.
...

Also I tried to indicate in my opening post that the standard TC backup will not be used.  Amongst other reasons, it is intended that ultimately the machine will join a LAN based backup system.
   

[tinypoodle]

Umm, have you looked at all options in detail?