Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Thu 18 Sep 2014, 22:01
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Derivatives
Light-Debian-Core-Live-CD-Wheezy + Porteus-Wheezy
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 169 of 238 [3558 Posts]   Goto page: Previous 1, 2, 3, ..., 167, 168, 169, 170, 171, ..., 236, 237, 238 Next
Author Message
fredx181

Joined: 11 Dec 2013
Posts: 764
Location: holland

PostPosted: Fri 02 May 2014, 14:10    Post subject:  

Hi Toni,
Quote:

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.
both-boot-methods.zip
Description 
zip

 Download 
Filename  both-boot-methods.zip 
Filesize  7.42 KB 
Downloaded  35 Time(s) 
Back to top
View user's profile Send private message 
saintless


Joined: 11 Jun 2011
Posts: 2445
Location: Bulgaria

PostPosted: Fri 02 May 2014, 14:22    Post subject:  

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.

Toni
Back to top
View user's profile Send private message MSN Messenger 
fredx181

Joined: 11 Dec 2013
Posts: 764
Location: holland

PostPosted: Fri 02 May 2014, 16:07    Post subject:  

Toni wrote:
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 Smile

Fred
Back to top
View user's profile Send private message 
saintless


Joined: 11 Jun 2011
Posts: 2445
Location: Bulgaria

PostPosted: Sat 03 May 2014, 06:52    Post subject:  

Hi, Fred.

I will test the new scripts today and tomorrow few remasters.

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

/var/cache/debconf/templates.dat-old
/var/log folder

/var/lib/apt/lists folder
/var/lib/sudo folder
/var/lib/urandom/random-seed
/var/lib/xkb

/var/lib/dpkg/available-old
/var/lib/dpkg/status-old
/var/lib/lock


As option or default behaviour or just to forget about this:
Code:
mv /var/lib/dpkg/info /var/lib/dpkg/info-new
mv /var/lib/dpkg/status /var/lib/dpkg/status-new
mv /var/lib/dpkg/available /var/lib/dpkg/available-new


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.

Just thoughts to think about for the future.

Toni
Back to top
View user's profile Send private message MSN Messenger 
saintless


Joined: 11 Jun 2011
Posts: 2445
Location: Bulgaria

PostPosted: Sat 03 May 2014, 10:14    Post subject:  

Hi, Fred.
fredx181 wrote:
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 Smile

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.

Toni

_________________
Farewell, Nooby, you will be missed...
Back to top
View user's profile Send private message MSN Messenger 
fredx181

Joined: 11 Dec 2013
Posts: 764
Location: holland

PostPosted: Sat 03 May 2014, 11:33    Post subject:  

Hi Toni,
Quote:
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.

Fred
Back to top
View user's profile Send private message 
saintless


Joined: 11 Jun 2011
Posts: 2445
Location: Bulgaria

PostPosted: Sat 03 May 2014, 12:13    Post subject:  

Hi, Fred.
fredx181 wrote:
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.

Toni
Back to top
View user's profile Send private message MSN Messenger 
fredx181

Joined: 11 Dec 2013
Posts: 764
Location: holland

PostPosted: Sat 03 May 2014, 13:05    Post subject:  

Toni wrote:
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 Smile 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 )


Fred
Back to top
View user's profile Send private message 
mcewanw

Joined: 16 Aug 2007
Posts: 2346
Location: New Zealand

PostPosted: Sat 03 May 2014, 22:43    Post subject:  

saintless wrote:

Xorg log for Dpup-Wheezy:
http://smokey01.com/saintless/Fredx181/Temp-stuff/dpup-wheezy-Xorg.0.log

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:
Code:

[  367.425] (WW) intel(0): Direct rendering disabled


I don't know enough about this, but also noted:

Code:
[   365.391]    ABI class: X.Org Video Driver, version 12.1
[   365.391] (WW) intel(0): DRI is disabled because it runs only at 16-bit depth.


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).

I doubt these mesa graphics drivers will actually work (provide acceleration), even if they load, unless they have been specially compiled for the kernel being used (but again I don't know about that).

_________________
Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
Back to top
View user's profile Send private message Visit poster's website 
saintless


Joined: 11 Jun 2011
Posts: 2445
Location: Bulgaria

PostPosted: Sun 04 May 2014, 01:48    Post subject:  

Hi, William.

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.

Toni

_________________
Farewell, Nooby, you will be missed...
Back to top
View user's profile Send private message MSN Messenger 
saintless


Joined: 11 Jun 2011
Posts: 2445
Location: Bulgaria

PostPosted: Sun 04 May 2014, 01:55    Post subject:  

fredx181 wrote:
Yes Smile 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.

Toni

_________________
Farewell, Nooby, you will be missed...
Back to top
View user's profile Send private message MSN Messenger 
fredx181

Joined: 11 Dec 2013
Posts: 764
Location: holland

PostPosted: Sun 04 May 2014, 04:54    Post subject:  

Hi Toni,
Quote:
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

Fred
remastercow-new.zip
Description 
zip

 Download 
Filename  remastercow-new.zip 
Filesize  2.54 KB 
Downloaded  25 Time(s) 
remastercow-new-setup.png
 Description   
 Filesize   88.3 KB
 Viewed   103 Time(s)

remastercow-new-setup.png

Back to top
View user's profile Send private message 
saintless


Joined: 11 Jun 2011
Posts: 2445
Location: Bulgaria

PostPosted: Sun 04 May 2014, 05:18    Post subject:  

Hi, Fred.
fredx181 wrote:
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.
Quote:
Here's concept of new remastercow:
... Can you make a text for it?

Sure, Fred. Thank you! I will test it and add help text later today.

Toni

_________________
Farewell, Nooby, you will be missed...
Back to top
View user's profile Send private message MSN Messenger 
mcewanw

Joined: 16 Aug 2007
Posts: 2346
Location: New Zealand

PostPosted: Sun 04 May 2014, 05:29    Post subject:  

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:

title debiandog_jwm (on first partition of drive /dev/sda = hd0,0)
root=(hd0,0)
kernel /debiandog_jwm/live/vmlinuz1 boot=live config persistent swapon quickreboot noprompt autologin showmounts live-media-path=debiandog_jwm/live/
initrd /debiandog_jwm/live/initrd1.img


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:

title debiandog_jwm (on second partition of device /dev/sdb = hd1,1)
root=(hd1,1)
kernel /debiandog_jwm/vmlinuz1 boot=live config persistent swapon quickreboot noprompt autologin showmounts live-media-path=debiandog_jwm/
initrd /debiandog_jwm/initrd1.img

-----

Note that I'm actually using it in practice on /dev/sdb1 with:

title debiandog_jwm (on my usb flash /dev/sdb1/debiandog_jwm)
root=(hd1,0)
kernel /debiandog_jwm/vmlinuz1 boot=live config persistent swapon quickreboot noprompt autologin showmounts live-media-path=debiandog_jwm/
initrd /debiandog_jwm/initrd1.img

Note that it also works with live-media-path=debiandog_jwm/base/ if you have copied 01-filesystem.squashfs into directory 'base'

_________________
Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
Back to top
View user's profile Send private message Visit poster's website 
fredx181

Joined: 11 Dec 2013
Posts: 764
Location: holland

PostPosted: Sun 04 May 2014, 05:52    Post subject:  

William wrote:
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:

title debiandog_jwm (on first partition of drive /dev/sda = hd0,0)
root=(hd0,0)
kernel /debiandog_jwm/live/vmlinuz1 boot=live config persistent swapon quickreboot noprompt autologin showmounts live-media-path=debiandog_jwm/live/
initrd /debiandog_jwm/live/initrd1.img

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:

title debiandog_jwm (on second partition of device /dev/sdb = hd1,1)
root=(hd1,1)
kernel /debiandog_jwm/vmlinuz1 boot=live config persistent swapon quickreboot noprompt autologin showmounts live-media-path=debiandog_jwm/
initrd /debiandog_jwm/initrd1.img


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.

Fred
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 169 of 238 [3558 Posts]   Goto page: Previous 1, 2, 3, ..., 167, 168, 169, 170, 171, ..., 236, 237, 238 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Derivatives
Jump to:  

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


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.2143s ][ Queries: 13 (0.0914s) ][ GZIP on ]