This information is already included in RemasterDog post:
http://murga-linux.com/puppy/viewtopic.php?p=773212#773212

Ok, that's good, didn't notice that.

Quote:

Also for my personal use I prefer the default shutdown menu and keeping obshutdown only for porteus boot, but if you like to work on excluding porteus module we will install obshutdown.

Oh, no, it wasn't my intention to change anything from original JWM setup.
I just didn't think of the ~/.jwmrc and other files (on second thought these would make it extra difficult or even impossible to exclude the 021-apps-porteus module).

But... I thought it would be nice to make some scripts usable for both boot methods so then the user doesn't get confronted with strange surprises.
If I'm correct it's only about 4 scripts: remastercow, loadmodule, mk-save.gtkdlg and rc.local.

Attached: both-boot-methods.zip

These scripts can be replaced then in the main module.
What should be removed then from the 021-apps-porteus module:
remastercow, loadmodule, mk-save.gtkdlg (symlink), rc.local and makepfile.sh.
And I think then the /live/cow and /live/image symlinks needs to be removed also.
I'm not completely sure but I think they have no function anymore then.
To be honest I didn't test, just modified the 4 scripts for now.

Thank you, Fred!
I will start using the changed scripts from now to see how it works.
I have some more stuff to add in Howto thread in the next days and i will focus on the changed scripts and RemasterCow cleaning suggestions.

I think to leave /live/cow and /live/image links. It is comfortable to use them with porteus-boot.

I think to leave /live/cow and /live/image links. It is comfortable to use them with porteus-boot.

Yes, you're right, it's ok, I wasn't thinking clearly, thought these were included with a remaster.
Btw, just now I reproduced the situation of making a remaster with porteus-boot incuding the 4 new scripts and then boot with live-boot, then porteus-boot and they all work fine with both boot-methods

Just some notes to myself on what also can be changed in RemasterCow safely. It is only list of changes for discussion and to have it easy to be found later. Maybe someone will see some files/folders needed:

Renaming dpkg data files will make the module safe to be loaded on any system but keeps the installed package hidden for dpkg.
The question is manually renaming to use on our own system, or manually renaming to share the module with others? But even using the module on our own system means we need to be sure it will be loaded all the time after creating another module with RemasterCow later. So I'm for default renaming.
There is one more option here which is the best one - some script for the future that will auto separate the packages from /var/lib/dpkg/info in new status and available and auto-make update-script.

Btw, just now I reproduced the situation of making a remaster with porteus-boot incuding the 4 new scripts and then boot with live-boot, then porteus-boot and they all work fine with both boot-methods

Thank you! I can confirm this from first test.
If you make remaster from porteus-boot still 021-apps-porteus.squashfs is included in the main module and not needed anymore. But this way all is working for live-boot even if porteus-boot remastered module is loaded.
I will test it this way for a while to confirm there is no issues.

Just some notes to myself on what also can be changed in RemasterCow safely. It is only list of changes for discussion and to have it easy to be found later. Maybe someone will see some files/folders needed:
Auto-remove:
Code:
/etc/fltk folder
/etc/frisbee folder
/etc/network folder
/etc/blkid.tab
/etc/blkid.tab.old
/etc/fstab
........

Seems like a good list to me except for /etc/frisbee which is part of the package and includes config files.
Some files from it can be removed safely I think:

Code:

/etc/frisbee/interface
/etc/frisbee/interfaces
/etc/frisbee/iface/*

EDIT: On second thought; it could be the purpose of a user when making a module from changes to save the by frisbee detected interfaces, so maybe better just to leave all in.

From /var/log I always remove the files, not the folders, don't know if it's safe to remove folders also.

Quote:

The question is manually renaming to use on our own system, or manually renaming to share the module with others? But even using the module on our own system means we need to be sure it will be loaded all the time after creating another module with RemasterCow later. So I'm for default renaming.

I'm also for default renaming but shall I look at an option to choose yes or no for remastercow?

Quote:

If you make remaster from porteus-boot still 021-apps-porteus.squashfs is included in the main module and not needed anymore. But this way all is working for live-boot even if porteus-boot remastered module is loaded.

Yes, if it works alright it's a good improvement.

Another thing:
You use mksquashfs a lot; do you have the experience that it totally fails at around 70-80% with message something like "read only filesystem".?
Then also my system is messed up (cannot open drives anymore).

I had this a couple of times and it seems like it has to do with changing/replacing files in the directory to be squashed just before making squashfs module.

Seems like a good list to me except for /etc/frisbee which is part of the package and includes config files.
Some files from it can be removed safely I think:

Code:

/etc/frisbee/interface
/etc/frisbee/interfaces
/etc/frisbee/iface/*

EDIT: On second thought; it could be the purpose of a user when making a module from changes to save the by frisbee detected interfaces, so maybe better just to leave all in.

I agree.

Quote:

From /var/log I always remove the files, not the folders, don't know if it's safe to remove folders also.

It is a second module which wiil be used on top of the main module. /var/log exists with all files in the first module. I think it is safe to remove /var/log folder using RemasterCow.

Quote:

I'm also for default renaming but shall I look at an option to choose yes or no for remastercow?

Yes, option to confirm renaming is good solution.

Quote:

Another thing:
You use mksquashfs a lot; do you have the experience that it totally fails at around 70-80% with message something like "read only filesystem".?
Then also my system is messed up (cannot open drives anymore).

I had this a couple of times and it seems like it has to do with changing/replacing files in the directory to be squashed just before making squashfs module.

Never had this behaviour but I use most Cancel to create module from RemasterDog. It takes too much time to compress the file on my hardware just to test something. I use gzip compression from terminal till everything is ready for creating new module for upload. Just then I let RemasterDog to finish the compression. I will test this more now since you have a problem sometimes.

What I can confirm is if you do not have enough RAM mksquashfs command will exit with error message killed in a few minutes. Usually you need at least 1Gb RAM to be sure with DebianDog module size. If you have 512Mb use SWAP with the same size or more for mksquashfs.

Never had this behaviour but I use most Cancel to create module from RemasterDog. It takes too much time to compress the file on my hardware just to test something. I use gzip compression from terminal till everything is ready for creating new module for upload. Just then I let RemasterDog to finish the compression. I will test this more now since you have a problem sometimes.

Just for info:
Using gz compression doesn't make any difference and I have 1GB RAM.
I learned now that if I'm making major changes in the folder to be squashed I better reboot and do mksquashfs after that.(it runs always ok then)
What I call major changes is:
- replacing files or directories
- chown or chmod directories or files.

Can you do these to see if you get the same problem then?
I've done a search on google for this but couldn't find anything.

Quote:

I use gzip compression from terminal till everything is ready for creating new module for upload.

Yes exactly the same for me, it's not so damn slow to compress and btw, with it the system runs smoother, boots up faster, I'm beginning to wonder why we use xz compression!
For that few MB's less size? (yes, I know, more then a few, but AFAIK that's the only real advantage of xz )

Just to add this CPU usage result means nothing to me, William. It may look funny I use such old hardware for DebianDog, but there is a good reason and it gives the results I want.
Toni

Good that your old machine is playing videos well. Nevertheless, many older machines will play videos and flash with less CPU load and smoother with DpupWheezy out of the box because it includes /usr/lib/i386-linux-gnu/swrast_dri.so to provide graphics software rendering. Perhaps your old machine is so old that that driver adds too much load itself or is somehow not compatible, I don't know. I do note from your DpupWheezy Xorg.0.log:

Perhaps you would note a significant improvement with mplayer CPU load when running DpupWheezy if your graphics are set to 16bit (I'm assuming above means 24bits at the moment). But as I say, I don't know and my purpose of studying DpupWheezy/GuyDog performance is to try and improve graphics cpu load/speed on my DebianDog install. I do note that GuyDog includes both swrast_dri.so and also r300_dri.so, which is the correct hardware driver for my old AGP radeon graphics, which explains why I get such low CPU load and smooth video (including flash) when running GuyDog on this machine. With most machines apt-getting mesa will sort things out - just that on older machines that newer mesa driver support seems to have removed some legacy drivers (such as those for my computers).

16 Bit will change nothing. The problem is DpupWheezy works much slower on this machine like opening Rox window is much slower. Also gmplayer starts slower. Maybe because the system loads more things on boot. I have the same experience with Wary which is made for old hardware.
The only Puppy that runs well and better than DebianDog in opening file manager windows speed for example is Turbopup but still this video playing slow and skip there.
You are right the performance should be much different on other hardware but I still doubt the tests results give proper comparing.

Yes exactly the same for me, it's not so damn slow to compress and btw, with it the system runs smoother, boots up faster, I'm beginning to wonder why we use xz compression!
For that few MB's less size? (yes, I know, more then a few, but AFAIK that's the only real advantage of xz )

Hi, Fred.
The only advantage of XZ is the smaller size and we pay for it with a little bit slower boot, but I doubt many users will experience slower boot or any difference from gzip compression. For Example William did not notice any difference except growing up the module size. I guess it depends on the hardware.
For JWM version the size difference is 32Mb. It counts for Copy to RAM option.

Testing mksquashfs with chown and chmod commands before making new module works OK for now two times using RemasterDog to finish the compression. I often change files like adding symlink in /mnt to /media/ changing sources.list with new one and fstab with empty. I will try changing folders like /root for example.

Testing mksquashfs with chown and chmod commands before making new module works OK for now two times using ReasterDog to finish the compression. I often change files like adding simlink in /mnt to /media/ changing sources.list with new one and fstab with empty. I will try changing folders like /root for example.

Thanks for testing.
To avoid misunderstanding:
The replacing or changing files, you do it in the working directory, right?
I'll test myself also some more, it could maybe have to do that I always use copy2ram boot option.

Here's concept of new remastercow:
- Added more cleaning
- Added checkbox to disable dpkg registration.
- Added sort of help button which displays info window.
The last I didn't finish (it has only some kiddy text for now).
Can you make a text for it? I'm no good with it.
If you want, it starts at line 24, don't use any quotes (so instead of for example: it's, must be: it is).
But you can also send the text to me.

Btw, the remastercow included in "both-boot-methods" was not good, somehow it misses the deletion of e.g. /tmp, /media,/mnt

The replacing or changing files, you do it in the working directory, right?

Yes, just now I'm making test delete /root and /usr in the work dir and copy them back from the running system with XFE copy/paste. Then chown and chmod commands in the work dir inside /root and /usr executed for some folders and now RemasterDog makes new module. 80% till now and all looks fine. Using both versions last RemasterDog.

Hi Toni, here is something for you to add or modify for the Howto section:

Quote:

How to boot DebianDog-Wheezy live-boot-2x from directory other than /live

The trick here is simply to provide the correct paths to vmlinuz1 and initrd1.img and to use kernel line parameter "live-media-path" to point to where 01-filesystem.squashfs is stored (or to storage location of whatever your squashed filesystem is named).

For example,

If you extracted the whole live folder INCLUDING the containing directory called 'live' from DebianDog-Wheezy iso and put it in /debiandog_jwm on say /dev/sda1 (i.e. first partition of device sda) the following menu.lst stanza could be used:

If alternatively you extract the CONTENTS ONLY OF DebianDog-Wheezy iso's 'live' directory into /debiandog_jwm on partition /dev/sdb2 (i.e. the second partition of device sdb), the following menu.lst stanza could be used:

If you extracted the whole live folder INCLUDING the containing directory called 'live' from DebianDog-Wheezy iso and put it in /debiandog_jwm on say /dev/sda1 (i.e. first partition of device sda) the following menu.lst stanza could be used:

If alternatively you extract the CONTENTS ONLY OF DebianDog-Wheezy iso's 'live' directory into /debiandog_jwm on partition /dev/sdb2 (i.e. the second partition of device sdb), the following menu.lst stanza could be used:

Yes, these examples work for live-boot but it should be noted that in case a user wants to switch to porteus-boot: When changing name of "live" folder, porteus-boot doesn't work anymore.
So the first example works with porteus-boot when "from=/debiandog_jwm" is used but the second doesn't because there's no "live" directory.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum