I made a customized ISO image and install it to USB key without any issue: Laptop can boot up with all the changes I made.
But after I burn the ISO image to CD and boot laptop using the CD, all customized changed are gone. Please advise me how to solve this issue.
Is it because the CD is ready only, so Slax can not write/save to it then lost all changes?
But after I burn the ISO image to CD and boot laptop using the CD, all customized changed are gone. Please advise me how to solve this issue. >yys2000
++++++++++++++++++
Kinda depends on how you save changes. If you are using a slaxsave.dat file, then when you run make_iso.sh [or make_iso.bat] none of your changes -- which are stored in that external file -- will be included.
Easy enough to get around this; just boot to always fresh mode and then loop-mount your slaxsave.dat file, and then make a module of it's contents.
and when that finishes [wait for the prompt!], copy the mychanges.lzm to your /slax/modules subdir and only then run your make_iso step.
(I added the rm -r command to the procedure to get rid of some subdirs that slax recreates on bootup; wouldn't matter if you were always going to use the new iso on the same machine where you made it, but they can cause trouble if you boot it on something different)
Now, if your frugal install is on a linux filesystem, and you are using the stock changes=/slax ... then make_iso should have included the changes.
To answer one of your questions, when you run from cd -- without specifying a changes file -- then all changes are just stored in memory and of course will not survive a reboot.
Thanks for the reply!
I saved the changes to a file: config.lzm and put the file in the /slax/modules.
Then I did more testing:
- If I burn this image into CD, then after boot up with the CD, the Slax looks quite different: It keeps changes, but most changes are gone.
- If I burn this image into a USB key, then make USB key readonly with a flip switch. It have same behaviour as the CD.
- If I make the USB key above writtable, then it has all the changes I made after boot up.
Please provide the insights of how to solve this issue.
:)
burninbush wrote:
But after I burn the ISO image to CD and boot laptop using the CD, all customized changed are gone. Please advise me how to solve this issue. >yys2000
++++++++++++++++++
Kinda depends on how you save changes. If you are using a slaxsave.dat file, then when you run make_iso.sh [or make_iso.bat] none of your changes -- which are stored in that external file -- will be included.
Easy enough to get around this; just boot to always fresh mode and then loop-mount your slaxsave.dat file, and then make a module of it's contents.
and when that finishes [wait for the prompt!], copy the mychanges.lzm to your /slax/modules subdir and only then run your make_iso step.
(I added the rm -r command to the procedure to get rid of some subdirs that slax recreates on bootup; wouldn't matter if you were always going to use the new iso on the same machine where you made it, but they can cause trouble if you boot it on something different)
Now, if your frugal install is on a linux filesystem, and you are using the stock changes=/slax ... then make_iso should have included the changes.
To answer one of your questions, when you run from cd -- without specifying a changes file -- then all changes are just stored in memory and of course will not survive a reboot.
- If I make the USB key above writtable, then it has all the changes I made after boot up.
Please provide the insights of how to solve this issue.
++++++++++++++++++++
Let's try one experiment, on the usb key; rename your /slax/modules/config.lzm file to z-config.lzm, and then reboot. Does it make a difference?
Slax, when booting. unions those lzm files in alpha order, and having it named config.lzm means that any added module with a higher [alphanumeric] name could mask the changes in your config.lzm file.
And of course, you must be booting the usbstick to always fresh mode to do this test to prevent previous changes from confusing the issue.
bb as guest wrote:
- If I make the USB key above writtable, then it has all the changes I made after boot up.
Please provide the insights of how to solve this issue.
++++++++++++++++++++
Let's try one experiment, on the usb key; rename your /slax/modules/config.lzm file to z-config.lzm, and then reboot. Does it make a difference?
Slax, when booting. unions those lzm files in alpha order, and having it named config.lzm means that any added module with a higher [alphanumeric] name could mask the changes in your config.lzm file.
And of course, you must be booting the usbstick to always fresh mode to do this test to prevent previous changes from confusing the issue.
This should have worked. Will you please tell us specifically what method you use to save changes? Is your usbstick formatted vfat? And when you try converting changes to an .lzm file, and then reboot always fresh mode, are some of your changes visible, or do none of the changes appear?
I follow these steps (http://www.ab9il.net/slax/slax-customization1.html):
Boot SLAX with all desired modules included in the /modules folder.
Add any new wallpapers to the /usr/share/wallpapers directory
Configure the desktop background, themes, visual effects
Go online and install all desired browser plug-ins, software updates, etc
Configure all software as desired, including bookmarks, email settings,etc.
Navigate to the /mnt/live/memory/ folder
Open a console window, and enter (without quotes): "dir2lzm changes /dev/sda1/slax/modules/slaxconf.lzm"
Navigate to the /dev/sda1/slax/modules/ folder and verify that it contains a new new module, slaxconf.lzm.
Also please let me know how to create the slaxsave.dat file. Thanks!
bb as guest wrote:
@ yys2000 ....
This should have worked. Will you please tell us specifically what method you use to save changes? Is your usbstick formatted vfat? And when you try converting changes to an .lzm file, and then reboot always fresh mode, are some of your changes visible, or do none of the changes appear?
Also please let me know how to create the slaxsave.dat file. Thanks! >yys2000
++++++++++++++
The way to get a slaxsave.dat file is to unzip one from slaxsave.zip on the distribution.
Once again asking the questions: is it the case that none of your changes appear in the new iso, or only some of them? What is the format on your usbstick?
bb as guest wrote:
Also please let me know how to create the slaxsave.dat file. Thanks! >yys2000
++++++++++++++
The way to get a slaxsave.dat file is to unzip one from slaxsave.zip on the distribution.
Once again asking the questions: is it the case that none of your changes appear in the new iso, or only some of them? What is the format on your usbstick?
My apologies ... tried to duplicate your issue, and realize I have been saying stuff that is wrong. Thought I knew something that I apparently don't.
-- dir2lzm on /mnt/live/memory/changes does NOT capture all setup changes
I will attempt to figure this out and get back.
@ jayflood ... I know you know more about this stuff than I -- what is dir2lzm capturing? Where are the setup changes that it is not getting?
It seems to me that this must implicate dir2lzm -- as I understand it, when you use a slaxsave.dat [which does remember all changes] the startup scripts are just loop-mounting that on top of /mnt/live/memory/changes??? Is that right?
Using dir2lzm to capture changes also gets directories it should not -- e.g., /mnt and /dev, which will cause problems if you run a make_iso and then attempt to run the result on a different machine.
@bb ... honestly i believe you are much for familiar with the workings of slax than i am. I remember joining the slax forum and you were giving me information while i was still cutting my teeth.
dir2lzm makes a call to mksquashfs (if i remember correctly) but it really should leave out the /dev/ and /mnt and other files/directories. Using mksquashfs directly you can accomplish this. As i understand it the 'changes' folder should record all changes made in the unionfs. The savedat file is mst certainly mounted after base modules but i think before the rootcopy is copied. Perhaps an example of what changes are NOT being saved would help narrow down the problem.
@bb ... honestly i believe you are much for familiar with the workings of slax than i am. I remember joining the slax forum and you were giving me information while i was still cutting my teeth.
dir2lzm makes a call to mksquashfs (if i remember correctly) but it really should leave out the /dev/ and /mnt and other files/directories. Using mksquashfs directly you can accomplish this. As i understand it the 'changes' folder should record all changes made in the unionfs. The savedat file is mst certainly mounted after base modules but i think before the rootcopy is copied. Perhaps an example of what changes are NOT being saved would help narrow down the problem.
++++++++++++++
Sorry about the name, all this time I have assumed you were a poster that is now a regular on Porteus.
I have found and read the dir2lzm script, which is really just a wrapper for mksquashfs, so that's no help. Neither avoids copying any directory [/mnt, /dev, /tmp]. And, for consistency they should not avoid -- it is just that is not a good way to capture changes. The same problem [unwanted dirs] would appear if you were to copy a slaxsave.dat file to a different computer.
The settings that aren't getting saved/restored here are all kde setups. You can make a change, copy that with a dir2lzm saved to /slax/modules, reboot, and find the changes saved & restored properly. Then do some more changes, repeat the dir2lzm action, and on reboot the result seems almost random, will sometimes reverse the first changes.
You =should= be able to make a .lzm file of a slaxsave.dat container, copy it into /slax/modules, then boot always fresh and see your previous changes restored, but that is also unreliable.
Porteus hasn't solved this; the weirdness is even more weird with kde4 setups.
Woke up this morning with a hint about this issue ... anybody wanting to pursue it further might be enlightened by searching the board on "whiteout".
The hint is that whiteout files are treated differently when saving changes to memory [i.e., without a disk file] than when saving changes with a disk file.
Solving this is probably above my job grade. Various people through the slax ages have invented their own changes-saving schemes.
@ yys2000 ... obviously, you can't save changes directly to a cd, at least the normal burn. But if you have a situation where you can use a slaxsave.dat on the hard disk, then changes saved into that will be restored on a reboot of the cd. And of course you can put slaxsave.dat onto a usbstick to travel with the boot cd. That was fairly common in the era before mobos would easily boot to a usbstick. You just have to issue the cheatcode at boot changes=slaxsave.dat; if one exists it will be used.
You might be interested in Puppy instead; they have long used a method where you make the initial iso burn as the first session of a multisession burn, and if you then boot from that, when you shut down it will ask if you want to add today's changes as a further session to the cd. I dunno how far that can be extended, but if you burn it to a dvd blank there will be a lot of free room.
Just thinking outloud:
If I boot with usb the setting you want to use will be loaded,
and the usb saves changes. What if you do lzm2dir save changes, this
should save it to live environment, open new lzm remove mnt,and
other you don't want.Move it to usb. Boot cd with the modules you
wanted, now copy the changes.lzm to desktop and install it.
If it works as you want, make new iso with it in it.
hope it helps
cat > /tmp/exclude.tmp (two left arrows) EOF
dev
tmp
mnt
EOF
I see what you are getting at with whiteouts. They merely 'white a file out' from it's physical disk space but i am not sure if this is the root of the problem. Perhaps a workaround for now is to make a kdeconfigs.lzm module from /root/.kde and /usr/share/applications/kde. A small script could accomplish this. I very rarely save changes anymore. Removing some (not all) .wh files could be beneficial when making a changes module. In any case i would recommend using a native file system for ANY linux OS instead of the awkward container bandaid solution.
PS: Sorry for double post. The code tag ironically misinterprets code.
