> i think one thing is obvious: too little information on the website, and a > lot of separate informations on the forum (sometimes confusing, as in every > forum).
The default slaxchanges is configured to be a root-fs I want add a filesystem to work as /home
I want to setup /dev/sda1 as part of unionfs, but limited on /home zone, and in read-write.
It's this possible?
while I believe you can layer read/write and read-only branches in a great many ways (man aufs, /mnt/live/linuxrc and /mnt/live/liblinuxlive for aufs syntax), let me offer another approach (maybe solution) to the problem
make a module for your customizations with symlinks to the relevant place where changes can be saved … this may need be a linux filesystem … ie /root/.kde/share/apps/amarok is a symlink to your /mnt/sda1/amarok directory … from there linux permissions can be applied …
another approach may be to modify the offending modules to save someplace other than /home
somewhere on the net I've seen a quote something like this … "Those who don't know linux are forever doomed to reinvent it" … I have tried to not fall in this pitfall of spinning my wheels needlessly …
plus, I always like the easy answer … I just might be the laziest person ALIVE
documented on: 2007-10-31, Guest
Aufs currently doesn't support multiple writable branches, thus you can't save changes to more then one place.
Junjiro is working on multiple rw branch support, so we can expect the feature sometime sooner or later.
documented on: 2007-10-31, Tomas
This is all working for me on a newer PC, with 640MB RAM and an old nVidia TNT2 card:
Downloaded the RC3 .iso, burned it to CD, then booted from it
Created two partitions on a 512MB USB flash drive: first one FAT16 (type 6), second one Linux (type 83)
Formatted partition 1 using mkdosfs, and partition 2 using mke2fs
Mounted 1st (FAT) partition as -t vfat on a new /mnt/sda1 directory
Copied the slax/ and boot/ directories from /mnt/live/mnt/hda_cdrom/ to /mnt/sda1 in Konqueror
Changed to /mnt/sda1/boot in Konsole and ran the install script
Mounted 2nd (ext2) partition on a new /mnt/sda2 directory
Created /mnt/sda2/slaxsave.dat and formatted it with mke2fs
Rebooted and chose Slax Persistent Changes from the boot menu, changing the option to: changes=/dev/sda2/slaxsave.dat and adding nocd and vga=normal
Ran xconf and startx, then customized Konsole, Konqueror, and sounds
Logged Out of KDE with my customized windows still open
Rebooted again, entering the same cheatcodes as above
Ran startx and everything was restored as it had been before last Log Out
One quirk I learned to avoid: since Linux treats a USB flash drive as a SCSI hard drive, you can't use the nohd cheatcode to avoid mounting real hard drive partitions. UPDATE: The noauto cheatcode solves this issue.
documented on: Sun May 06, 2007, jayseye
before explaining my problem, i think one thing is obvious: too little information on the website, and a lot of separate informations on the forum (sometimes confusing, as in every forum).
so, as far as i could gather them: config.lmz; slaxconf.mo; slaxsave.dat… it seemed to me that slaxsave.dat is the one to use if you don't want to bother with typing commands everytime you boot and log off;
so i extracted the save128.zip, put in on my usb stick, added changes=/slaxsave.dat to grub's menu.lst; didn't work;
then found on a topic that it's better to put it on a slax/ directory on the stick: didn't do any good…
Vector
> i think one thing is obvious: too little information on the website, and a > lot of separate informations on the forum (sometimes confusing, as in every > forum).
Couldn't agree more!
When doing changes saving configuration, I always reboot 3 times to verify.
boot my USB Slax to make the modification.
boot my USB Slax again, and do the following in root's home dir.
echo abc > abc
then reboot the 3rd time to verify that the abc file is there and the content is kept.
Have you tried reboot enough time?
PS.
It doesn't matter whether changes=/slaxsave.dat or changes=/slax/slaxsave.dat
just make sure the file is there!
documented on: 2007.06.02, xpt
it works just fine now, with the file provided : slax128.zip it just didn't work when created with dd if=/dev/zero of=slaxsave.dat bs=1k count=20k (seen somewhere in the forum)
Just for the archive, you miss the 2nd step, which is the most important one.
xpt
> > Just for the archive, you miss the 2nd step, which is the most important > > one. > > mke2fs slaxsave.dat, you mean?
FWIW, Tomas suggested and used mkfs.xfs as the filesystem for it.
documented on: 2007-06-05, bb as guest
ok, everything alright then. Whistle
Not really — that 20k count produces a 20mb save file — not large enough to be useful at all, could easily fail on the first attempt to use it. Even 128 and 256mb are not enough if you expect it to also hold downloaded modules.
I suggest that anyone using a slaxsave.dat file should periodically boot without it, then loop mount it to examine what you are actually saving — it might surprise you what's in there. The save function will definitely fail when it gets full.
documented on: 2007-06-05, bb as guest
Actually a ~20mb save file is the maximum I can afford — small USB. Are all changes goes into the file; i.e., is there any exception, e.g., /tmp that I can safely use?
for a 20mb space, configsave is the only useful option — you'll just have to remember to run it after every significant change, and even then you'll have to modify your standard practice — for example, clearing the Firefox cache and /tmp before saving. That FF cache alone can get to 50mb size.
Linux filesystems tend to be very messy, lots of additional copies of things, immense numbers of 0-length files, empty directories, etc. I'm not prepared to rewrite linux, so we just have to work with it.
documented on: 2007-06-07, bb as guest
It's easy to make your own slaxsave.dat file of any size you might want —
# dd if=/dev/zero of=mysave.dat bs=1024 count=64k # mkfs.xfs mysave.dat # mv mysave.dat slaxsave.dat
which would produce a slaxsave.dat of 64mb size. Adjust that count value to suit what you want.
A file like this, loop mounted, can also be a convenient destination for a mo2dir operation — on a machine with no linux-format partitions.
# mkdir temp # mount -o loop mysave.dat temp # mo2dir some.mo temp
After which you can use konqueror or whatever util to examine or modify the internals of a .mo file.
documented on: 2007-01-29, bb as guest
Subject: configsave is needed
Please Tomas configsave script is needed for users with less space in usb-memory and that only want a basic customization of kde(icons,fonts,menus…) all the rest is saved if the user wants,in a partition or in the same usb-memory and configsave script is not opposing to other methods like slaxsavedat.
Please add a simple script like configsave in slax-5.Thanks.
Configsave should not be used anymore.
You may use:
dir2lzm /mnt/live/memory/changes /mnt/your_usb_stick_with_slax/slax/modules/config.lzm
If you like to save only small settings, simply create small slaxsave.dat and use it.
For example, a 1MB slaxsave.dat:
dd if=/dev/zero of=slaxsave.dat bs=1k count=1k mke2fs slaxsave.dat
Then, save this file in YOUR_USB_DRIVE/slax/slaxsave.dat if you are using USB Slax, or save it in ANY_WRITABLE_DISK_OR_USB/slaxsave.dat if you're using the ISO version (and boot with second boot option).
People should really learn how to use the Persistent changes feature.
documented on: Apr 16, 2007, Tomas
> For these things i'm using /slax/rootcopy ... works fine
No it does not. Tomas and others (with whom I concur) have reported that /rootcopy isn't a wholly reliable means of bringing files into the system, for lack of file modes+ownership info. In fact, Tomas was on the verge of removing that feature from Slax 6, quite recently. Unless it's only a matter of importing data, one can never be completely certain the /rootcopy mechanism will work. Even in the case if importing data, file modes+ownership issues could unexpectedly bite you in the ass.
I haven't used CONFIGSAVE in at least six months, nor have I even tried the persistent filesystem trick (altho I must change that soon.) DIR2LZM/DIR2MO serve well, in fact have never failed.
mkdir -p /temp/root cd /temp cp -R /root/.kde /root/Desktop /root/.mozilla /temp/root dir2lzm . /mnt/hda1_disk/root.settings.lzm
Those five commands will save your KDE, Firefox and Desktop settings to a module on your hdrive. I do this manually, simply bec I haven't taken the time to make this into a script for routine use. However, this is just one way that will reliably preserve settings under Slax.
Other people have their own ways-and-means and Tomas' earlier recommendation is probably the most straight-forward approach, esp if one wants to avoid typing commands or figuring how to write scripts….Jet
documented on: Apr 16, 2007, mr-roboto
I think /rootcopy is very useful for patching a live-cd among other uses but it's not a mean for persisting changes.
If used with care and from a filesystem that supports linux permissions then it is reliable. The problem arises when people uses it from a FAT filesystem. But that's a problem of the FAT filesystem not the rootcopy feature.
documented on: May 02, 2007, zariweb
I agree that configsave is extremely useful. Since it's the only system which allows selective saving of changes which can have huge advantages over manditory systems which deny your freedom.
I don't see why configsave can't be just left there for those who want to use it, rather than being dropped/removed from Slax. (which I don't really believe will happen. At least I hope not)
I personally feel if it is removed and not replaced with some other method of doing selective saving, I would have to find a way to replace it or I'd have to reluctantly go elsewhere.
I simply don't want a system that dictates to me, and takes away my freedom to experiment.
Here's just one example, but there's a lot more. Right now I can try all kinds of crazy experiments. Some of which can completely mangle and wreck the system. I then simply reboot without saving changes and I'm instantly back to a perfect system with all my previous changes.
Try doing that with changes= or a real install. I don't think so.
documented on: 2006-09-08, by Guest
I think I need to bring up this old post again.
I 100% agree with what he said. I'll take a note of it in my note collection.
documented on: 2007-08-06, by xpt
I am using configsave slax5 with a little modification and is working good for me. I only need a little changes and I don't change my changes frecuently.
Make a text file with this content and rename it to configsave then make executable and make a module with it put it in /usr/bin inside module.
I use in terminal:
configsave /Where/I/want/store/slaxconf.lzm
This is the code equal configsave for slax5 from Tomas but a little modification:
#!/bin/bash # save and restore SLAX config to a file # $1 = full path to new slaxconf.mo file PATH=$PATH:/usr/sbin # only root can run this if [ "0$UID" -ne 0 ]; then echo "Only root can run `basename $0`"; exit 1 fi SLAXCONF=slaxconf.lzm MEMORY=/mnt/live/memory CHANGES=$MEMORY/changes CONFFILE=$1 if [ "$CONFFILE" = "" ]; then echo "usage: $0 [-f] /mnt/hda?/$SLAXCONF"; exit 1; fi if [ -d "$CONFFILE" ]; then CONFFILE=$CONFFILE/$CONFSAVE; fi if [ -e "$CONFFILE" -a ! -f "$CONFFILE" ]; then echo "not a regular file $CONFFILE"; exit 1; fi # directory with changes is only in SLAX LiveCD, not in installed version if [ ! -d $CHANGES ]; then echo "This script can work only from SLAX Live CD"; exit 1 fi # INIT # *********************** MYSELF="`basename \"$0\"`" # SAVE # *********************** if [ "$MYSELF" = "configsave" ]; then echo "saving changes to $CONFFILE..." rm $CONFFILE 2>/dev/null touch $CHANGES/{etc,home,root,var} mksquashfs $CHANGES/{etc,home,root,var} $CONFFILE -e $CHANGES/var/{run,log,man,tmp} /etc/fstab >/dev/null 2>/dev/null if [ $? -ne 0 ]; then echo "can't write config to $CONFFILE"; exit 1; fi fi # RESTORE # *********************** if [ "$MYSELF" = "configrestore" ]; then echo "restoring changes from $CONFFILE..." lzm2dir $CONFFILE $CHANGES uniondbg -g / fi
documented on: 2007-08-06, by gusterrapolis
Using the changes= cheat code / method.
They may need to:
preserve configurations, settings, etc. so that they don't need to redo those changes over and over again on each boot,
carry the settings with them so they don't need to redo those changes whenever they use a new PC.
People who boot slax off a CD, USB, or hard disk frugal installation.
On the contrary: according to a poll on SLAX forum, over half of slax users boot slax using USBs; CD-ROMs and hard disks are about another 30%. Ref: http://www.slax.org/forum/viewtopic.php?t=17676
I don't recommend using the changes= method to save changes for USB users. It is bad practice. That would mean over half of the total number of slax users don't have any way to save changes in slax6.
In summary, the changes= method is bad practice for USB users because of the following reasons. Refer to the following articles for details.
It wears your USB flash out pretty quickly.
The dilemma between having a big run-time root file system and the limited & precious space on a USB.
It collect more garbage than useful files; the S/N ratio is too low to be practical.
It is impractical even for a hard disk frugal installation: to get reasonably sized run-time root file system, the slaxsave.dat needs to be 2G to 4G in size, if you intend to use slax as a tool instead of a toy; only less than 0.01% of the space will be used to save the configurations and settings that you really need. Moreover, you can't take your configurations and settings to a new PC.
It is unsafe. Thinking the read-only frugal installation is rather robust, right? Well, normally it is — no need to worry that you will accidentally delete (or silently move) some system files or directories, nor to worry about sudden power loss, nor even the system being hacked. But think again if you are using the changes= method: you lose all the above frugal installation advantages. Even worse, you can trash your system very easily. When you do, it is very hard to fix (unless you decide to lose all your changes and return to ground zero).
It solves one problem but brings more problems. While Unix's approach is to educate people, M$'s approach is to bury details with a "simple" solution in hoping that it will be fool-proof. However this changes= fool-proof solution can cause troubles elsewhere which could seems to be entirely unrelated to it. This post is a good example, http://www.slax.org/forum.php?action=view&parentID=14318. I don't think the OP get the idea that the whole problem is due to the changes= method in the end, after being humiliated several times.
just for economy it's better to boot without a changes= setup, then installpkg to a /temp directory, then use dir2lzm to make a module of it, then use that lzm module ideally by copying it to your /modules subdir. This will avoid carrying around multiple copies of every piece you add. Don't forget to reenable your changes= cheat when through with making modules.
I suggest that all who use changes= should periodically boot without invoking it, then loop mount the changes directory and go through it with file manager, get some insight into what's going on in there. You may be surprised at what you find — saw a post the other day where some user was reporting a changes dir with 600+mb of stuff in it.
documented on: 2008-03-19, burninbush
I have build an lzm module for my home directory, to provide a starting point for a fresh-installed system, then use save changes further on.
Today, I noticed that some of my files from my built lzm home module is missing. In the effort to restore everything to my initial lzm module files, I deleted the screwed directories in hoping that when reboot, the screwed-up files/directories will restore to my initial lzm module files/directories.
However, to my astonishment, the deleted directories are no longer there! Listing the files from lzm module show the directories are there.
So, how come the deleted directories are not restored from lzm module? If I want to restore to my initial lzm module files/directories, how should I do?
To test for yourself (if you have save changes enabled), try run
rm -rf /usr/doc
then reboot. I bet the /usr/doc directory will not be there.
I incidentally deleted my rssowl directory once (it is on a lzm module) and i had to restore it this way (not sure of the detail, just explaining the process)
start LIVE, no changes files
backup your slaxsave.dat file somewhere
mount slaxsave.dat:
mkdir /mnt/test mount -t xfs slaxsave.dat /mnt/test (may be it need "-o loop ")
now you have your changes on mnt/test
find for the wh.yourdeleteddirectory file on xfs filesystem (not sure about the right name, i guess wh.youdir, or something like that, you will recognize it, it is the stranger file in your dir ehehe)
it restored my missed module, not sure if this is a legitimate way to do it, so please before to try backup your slaxsave.dat
documented on: 2007-07-05, by jimjams
How can I install CPAN modules as slax lzm modules when save changes is enabled?
The general procedure would be:
install CPAN modules
convert the installed into slax lzm modules, and put it into proper place
remove the installed CPAN modules because they are going to be provided from lzm
But the problem is, save changes will remember that the installed CPAN modules are removed. As the result, after the CPAN lzm modules have been loaded, save changes will then remove them. So even the CPAN lzm modules are loaded, I can't see them.
documented on: 2007-10-12, by xpt
While using the latest RC, I started to use persistent changes in slaxsave.dat for the 1st time. It more or less worked as expected, exc for what I'm pretty sue is a bug. While doing some development work, I routinely extract the tarballs into a sub-dir of my own making, /temp, then compile and test there.
The problem is that the contents of /temp were preserved across sessions over several days. I'm pretty sure it's not supposed to work like that. The larger problem is that later in the week, as I compiled more, I found a few DSOs which were in base Slax modules, were no longer loading. I believe bec I'd created conflicting DSOs during my development work and somehow only the 1st (my) copies of these files were being loaded. Before you ask, I never installed any of the files from my /temp sub-dir.
documented on: 2007-08-18, by mr-roboto
The problem is that the contents of /temp were preserved across sessions over several days. I'm pretty sure it's not supposed to work like that.
If you use persistent changes, ALL changes to the filesystem are remembered. If you extract files to /tmp, they will stay there. Simply remove them manually.
Is there a reason why slaxsave is invisible (from the mount list) when mounted at boot time ? It's helpful to be able to inspect how space is avail on slaxsave.
you can't see it because 'df' and 'mount' tools work with /etc/mtab, while this file doesn't exist yet at the time when changes file/dir is mounted. Nevertheless, if you do 'df', you'll save the changes file as 'tmpfs' or 'aufs' and so the free space for 'tmpfs' is the free space in your changes.
documented on: 2007-09-12, by Tomas
This problem isn't only showing up between sessions but also when some program needs space for temporary files. For example, I'm using a slaxsave.dat which have a size of 100 Meg and the content of my root directory is around 50 Meg. If I need by example to uncompress with midnight commander a big compressed file to show it's content, I automatically have an error message telling me I don't have enough space left on disk and the program abort. With smaller slaxsave.dat files, this problem is even more problematic as there is almost no free space left.
documented on: 2007-09-12, by martinlmtl
I would really love to upgrade to Slax 6.x.x (still using 5.0.6 right now). I use my current version customized and in CD format.
The problem that prevents me from moving up to ver. 6 and > is that I often use Slax on the fly on host computers (with proper permission granted by the machines' owners, of course!) to do my work (website management, etc.) at different physical locations, and it is therefore very important that the host computers' hard drives NOT be modified in any way.
Now, Slax 5.x.x allows that, no problem, but currently I cannot use ver. 6 and above because of lack of an option for disabling persistent changes ("there is no option to not save changes").
> I think that the problem is only the way it's described. > Always fresh in the real means that doesn't load and doesn't save.
OK, great if true. Again, I was puzzled by the statement in the manual: "there is no option to not save changes - there is an option to start slax fresh without changes." IF what you say is true, then maybe Tomas should consider changing that statement because it would be obviously misleading.
The description is here:
nicoli
I get a "Well Done … Module Activated Sucessfully" bubble
You can see above that there are more files and some directories in the fakeroot directory before I run dir2lzm, but they are not seen after module insertion.
What am I doing wrong here?
documented on: 2008-03-19, webboy
If you deleted libImlib2* files from /usr/lib before you activated the module, Slax remembers that and it will not show the files even if exist. This may be considered a bug, but I'm afraid it won't be fixed any time soon.
Please review /mnt/live/memory/changes/usr/lib/ If you find .wh..libImLib* files there, delete them all.
documented on: 2008-03-19, Tomas M
Thank you for the workaround. I deleted the files and they are now visible after after module activation.
I think you were correct, I had previously installed with installpkg and I then removed with removepkg before proceeding to try and create a module.
documented on: 2008-03-19, webboy
Something very strange has happened with my 6.0.3 : I have it installed on my 2Gb usb,and it takes 204Mb,but today I was forsed to reinstall 6.0.3 again as it suddenly (and I have no idea why) became 1.4Gb!!I have no idea why it increased so much and didnt know how to solve it so I reinstalled it.Do you have any ideas what was that?
format usb and start over
documented on: 2008-03-28, podlinux
boot with the cd, use "Slax always fresh mode", ie no changes= specified, and do all your initial setups — which are clearly being stored in memory at this moment. When you have it as you like, before exiting do a #dir2lzm /mnt/live/memory/changes ./changes.lzm. When that finishes, copy that changes.lzm file off to whatever media you like.
Then, the next time you boot slax, after root/toor login, run #activate /mnt/path-to/changes.lzm. Then do your #startx command to get kde running — you will see that all your changes are back. If you copy that changes.lzm to your /slax/modules subdir then they'll automatically appear at the next bootup. If you need to do more changes, boot again with no changes= specified, and do the same dir2lzm, only this time name it changes2.lzm, etc — so when you boot after that your changes will get loaded in sequence.
If you include these changesN.lzm files in your remaster, they'll then be a permanent part of your slax cd.
There is IMO a fundamental problem with using changes= in the standard way — you'll wind up carrying around 2 copies of everything you add to your slax system.
documented on: 2008-03-28, burninbush
It seems that 'changes' in Slax 6.0.3 eat to much :) . I cant start slax with changes if there is less than 70 mb on my drive. and in fiew hour of uptime 'changes' grew up to 200 mb (i was only listening music).
I have a basic question (I did a lot of reading, but I am still unsure about it…):
When saving changes via dir2lzm /mnt/live/memory/changes /somemountpoint/somedir/mychanges1.lzm, creating a CD and expanding mychanges1.lzm into /rootcopy, booting again, working with the system again, saving changes again via dir2lzm /mnt/live/memory/changes …./mychanges2.lzm etc. etc., isnt't it so that the last .lzm file (let's say: mychanges5.lzm) contains all the previous changes - or is that NOT so?
To give an example:
"Incremental and cumulative SPs"
A service pack can be incremental, which means it only contains the updates that were not present in the previous service packs or, more commonly, cumulative, which means it includes the contents of all its predecessors. In the case of Microsoft's product, incremental updates are usually called service release. For example, Office 2000 must be upgraded to service release 1 (SR1) before one can install SP2."
So my question is:
Are such changes.lzm files incremental or cumulative?
I would guess, they are cumulative - and that I could just take the latest .lzm file and copy it into an empty /rootcopy directory and create a new CD.
I dit it, but found that not all my changes were in there! In fact, I had installed the nvidia driver, but it wasn't loaded, nor were other changes activated.
Only when I did another lzm2dir mynewestchanges.lzm / I found my system up to date and fully working (after booting into the live system, completely in RAM).
Thanks for your help, sempronius
I believe it should be cumulative. However, I do believe that sometimes not everything gets saved and when one reboots, we lost several of the things that we wanted to save. I am not an expert on this issue. I prefer to always boot fresh without changes and in text mode to load openchrome driver so I can watch movies in slax without the CPU hogging 100%.
There are several approaches you can try to save the changes. There are several save scripts you can try just search the forum.
documented on: 2008-06-11, tonio
I remember Puppy had a feature where it tries to minimize read/write to the USB flash drive to enhance its life span. I installed SLAX today, it works but I noticed that there was frequent activity (as indicated by an LED on the thing) whilst using SLAX. My question would be whether I should be concerned about my drive dying early from all these read/write cycles.
OMGsplosion
> The more modern flash drives, made within the last 2 years or so, are much > more durable than the older ones
I think he is referring to the amount of write to the usb type memory. Puppy has the whole file system in RAM and only writes back to the usb drive every 30 minutes or so. The is supposed to increase the life of the usb drive.
visionary
the newest flash drives (at least the good ones), have "controlers" the assure, that the writing on the memory is homogeneous, that is that one place in the chip is not writen many times and other one is writer less, this assure a life time much longer then the older ones. i have a corsair voyger gt that acording to corsair have a 100.000 write cycle life. that mean i can write 210gb of data per day for 10 years. i guess this is enought cause i will probably lost the pen drive before that.
link to the doc http://www.corsair.com/_faq/FAQ_flash_drive_wear_leveling.pdf
sadrunk
Flash memory, whether it be USB thumb drive or media card, comes in two flavors: SLC or MLC. SLC stands for Single Level Cell — traditional binary memory where each cell is either zero or one. MLC stands for Multi Level Cell — each cell can represent two or more bits. MLC memory is less expensive because it take less real estate for a given size. Most consumer flash memory is MLC for competitive reasons. The disadvantages of MLC are:
Lower endurance, typically 10K erase/write cycles versus 100K-1M cycles for SLC
Lower read/write speeds
Higher error rates placing more dependence on error correction algorithms
Most manufacturers of flash media are loath to tell you which they use, or specify endurance, for fear of exposing their inferiority. SanDisk, for example, makes no mention of SLC or MLC, and omits any mention of endurance, even in their OEM flash memory documentation. They apparently subscribe to the marketing theory that if you keep the customer ignorant, he/she will be dumb enough to buy your product. Transcend (www.trandsendusa.com) is more forthcoming about the technical aspects of their products.
As sadrunk mentioned above, flash media have a controller that implements wear leveling, spreading the erase/write cycles around to improve lifetime. As a practical matter in many applications, such as digital cameras, the SLC vs MLC question may be irrelevant. For critical applications, or where extensive writes are anticipated, SLC would be the better choice. This explains why Live CD type distributions are more suitable for flash based systems, why Tomas M's posting above is important, and why industrial compact flash cards and solid state disks utilize SLC.
Mike (mikep)
Thanks Mike for your insightful info. One further question,
Is there any way to tell if a USB thumb drive/media card a SLC or MLC based?
> that mean i can write 210gb of data per day for 10 years
sadrunk's flash must be SLC. Mine are the smallest and cheapest ones available on the market. I bet they are MLC. According to the endurance rate difference between SLC and MLC posted by Mike, at such writing rate, mine would wear out with a year or even a month.
No wonder there are people who don't care about the wear out of their flash media, and those who care a lot.
xpt
I don't know of any way to distinguish MLC from SLC in a flash drive if the manufacturer does not specify the type or the erase/write cycles. However, I wouldn't despair about the life of your flash drive if it is MLC. sadrunk posted the link to a Corsair document that explains wear leveling and estimates write capacity to be 120GB/day for ten years with an 8GB SLC flash drive rated for 100,000 erase/write cycles. If you have a 1 GB MLC flash rated for 10,0000 cycles, that still means you could expect to write 1.5GB/day, (divide 120 by 80) and that is a lot of data. You may be more dependent on error correction but the chance of a fatal error is very small. I use MLC compact flash cards as well as SLC because they are cheap and I know I will replace them before they wear out. This is one of those cases where you don't need a Ferrari if the speed limit is 100 km/hr.
Mike (mikep)
documented on: 2008-03-02
In the 5.1.8.1 version of Slax, I used "configsave/configrestore" commands to save any changes made to the file system in my USB flash. Those commands worked like a charm! I noted that on Slax 6 RC3, those commands were removed. So, after some research, I find out that I could use "changes=slaxsave.dat" to save some changes made in my USB flash Slax.
But the problem is that I didn't get it to work!
slax.bat is using a file called 'config'. Add a new line at the end of this file with
changes=/slax/slaxsave.dat
It should work. Make sure you have slaxsave.dat in the /slax/ directory on your USB.
documented on: May 07, 2007, Tomas
I'm trying to use configsave in order to save my kde settings (wallpaper etc.). So I do "configsave /mnt/sda1_removable/modules/slaxconf.mo", settings get saved, but after a reboot I have to do the Setup wizard again and all my settings are gone too.
So I do configrestore ……, but same result.
at a quick guess, you did the configsave once, then made some trivial changes and did it again — and the only changes that survived is the trivial 2nd try.
Be aware that configsave overwrites any previous file of the same name — it doesn't append to it, and on the 2nd save, it only saves changes made since the last reboot.
So … suggest you try again.
To be clear, I'm guessing that you have slax copied to the top level of your sda1 usbstick? And, was the write successful? Can you browse to that folder and see the file?
Guest
It is possible to have evolutionary changes over time, but each time save to another .mo
For example, …….the original save might be saveconf.mo …….the next might be to z1conf.mo …….the next might be z2conf.mo …….etc
All are placed in the modules directory and are loaded in the proper order: …….saveconf.mo, then z1conf.mo, then z2conf.mo , etc
This DOES work. I have been using this method.
documented on: May 25, 2007, slaxkudos
Sure it does work, but not for me.
The thing wont save any kde settings like wallpapers or other simple settings.
I set a wallpaper, do configsave. Reboot, do configrestore. Result: No wallpaper, no settings saved.
documented on: May 25, 2007, tbb
> So I do configrestore ......, but same result. > What's happening?
Try this path, it always works for me:
configsave /mnt/sda1_removable/slaxconf.mo
This way it will prompt you on boot, asking if you want to restore your configuration. This means you will have to attend to the boot, watch for the prompt to hit "enter" to restore. It times out in 10 seconds, and if you don't catch it, it will not restore your settings.
You are putting it in a subdirectory of the root. To prompt automatically for save/restore it has to be in (any) root partition.
documented on: May 25, 2007, catworld
> The thing wont save any kde settings like wallpapers or other simple > settings.
OK, that's a different problem. Wallpapers are stored in a directory location that configsave doesn't monitor. If you are running as root, then most changes you make will be in one of those hidden directories under /root — but not wallpapers.
I suggest that you copy the wallpaper you like to /root, point KDE Control Center [look & feel] at that location, and then do a configsave — now it'll come back.
documented on: May 25, 2007, bb as guest
tbb,
To confirm what may be part of your problem, you provided the following path:
configsave /mnt/sda1_removable/modules/slaxconf.mo
Is that the actual command you use?
Have you tried what I suggested? I have used the below since I first figured it out, and all my wallpapers, desktop names, color schemes, even my email account settings have been solidly persistent.
I think what bb says is perhaps true if you are not yet telling us something else which is important, such as the unsaved wallpapers are custom ones you have added…
documented on: May 25, 2007, catworld
> I decided that a bigger one would be useful. But, I had already made lots of > changes and really didn't want to lose any data.
I believe that the size of slaxsave.dat can be easily increased.
You simply enlarge the slaxsave.dat by zeros (using dd or cat /dev/zero >> slaxsave.dat for a while), and then you use xfs_growfs command to grow the XFS filesystem to fully fit the file size. All data will be preserved.
documented on: May 01, 2007, Tomas
I could not run the xfs_growfs command directly on the slaxsave.dat file. It returned me this error : slaxsave.dat is not a mounted XFS filesystem.
So in order to make it successfull, you just need to restart your Slax without using your slaxsave.dat file. With Slax 6 press tab during the boot splash screen then delete "changes=slax/slaxsave.dat" part of the command, then press enter. After boot is done, mount your slaxsave.dat like this :
Create first a temp mount point :
mkdir /mnt/temp
Then mount your slaxsave.dat like this (I run slax from a usb stick) :
mount -t xfs /mnt/sda1_removable/slax/slaxsave.dat /mnt/temp -o loop
And finally use the xfs_growfs command like this :
xfs_growfs /mnt/temp
Tested with the fresh Slax 6 rc3.
documented on: May 04, 2007, Frederic GROSSE
> Is a 256mb slaxsave.dat big enough? And can I remove anything out of > slaxsave.dat? I'm using Slax-6.0.0rc3.
You can check usage of slaxsave.dat by mounting it using some variation of these commands:
mkdir /mnt/tmp mount -o loop /mnt/sda2_removable/slaxsave.dat /mnt/tmp df -H /mnt/tmp
After a couple of uses, the commands above show only 3% usage for my own 256MB slaxsave.dat or, in this case, just 5MB used.
You can also browse to /mnt/tmp in a Konqueror file browser and, presumably, remove anything you don't want. But the changes will probably be re-written each time you boot with changes=/slaxsave.dat
Be sure to umount slaxsave.dat when you're done:
umount /mnt/tmp
documented on: May 05, 2007, jayseye
I loaded Slax6rc5 on a 256 MB pen drive. At first boot, the file slaxsave.dat grew to take up all free space (over 47MB). What would be the best thing to do to leave some free USB space?
hearsay
Slax for USB is designed to create 256MB slaxsave.dat
If you don't like this feature, edit syslinux/syslinux.cfg … and remove 'chexpand=256' or change it for example to chexpand=20.
documented on: 2007-07-26, Tomas