Light-Debian-Core-Live-CD-Wheezy + Porteus-Wheezy

For talk and support relating specifically to Puppy derivatives
Message
Author
User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#2521 Post by fredx181 »

Hi Toni,
This information is already included in RemasterDog post:
http://murga-linux.com/puppy/viewtopic. ... 212#773212
Ok, that's good, didn't notice that.
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.
Attachments
both-boot-methods.zip
(7.42 KiB) Downloaded 166 times

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#2522 Post by saintless »

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

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#2523 Post by fredx181 »

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

Fred

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#2524 Post by saintless »

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: Select all

/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: Select all

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

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#2525 Post by saintless »

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

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#2526 Post by fredx181 »

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

/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.
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?
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

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#2527 Post by saintless »

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: Select all

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

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#2528 Post by fredx181 »

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


Fred

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#2529 Post by mcewanw »

saintless wrote: Xorg log for Dpup-Wheezy:
http://smokey01.com/saintless/Fredx181/ ... 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: Select all

[  367.425] (WW) intel(0): Direct rendering disabled
I don't know enough about this, but also noted:

Code: Select all

[   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).
github mcewanw

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#2530 Post by saintless »

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

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#2531 Post by saintless »

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

Toni

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#2532 Post by fredx181 »

Hi Toni,
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
Attachments
remastercow-new.zip
(2.54 KiB) Downloaded 147 times
remastercow-new-setup.png
(88.3 KiB) Downloaded 142 times

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#2533 Post by saintless »

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

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#2534 Post by mcewanw »

Hi Toni, here is something for you to add or modify for the Howto section:
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'
github mcewanw

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#2535 Post by fredx181 »

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

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#2536 Post by mcewanw »

fredx181 wrote: 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.
Yes, just for live-boot Fred. But I'm surprised the Porteus-boot from= code isn't used to point to where the filesystem squashfile is. The changes= part does seem to logically point to where, for example, a changes directory would be. I'm thinking there is a mistake in the from= code. Was that all from Porteus or have you modified it somehow. If you modified it, perhaps it is possible to make it point to filesystem squash file whether it is in live folder or not, which would be more logical to me? I remember reading that, as things stand, you are able to just put from=/ (which again seems a bit illogical).

In other words, why is the from= in porteus-boot assuming 'live' rather than usefully being used to specify the full path to 01-filesystem.squashfs (i.e. from=/live/ or if you have 01-filesystem.squashfs in /portdebdog, from=/portdebdog/)?
github mcewanw

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#2537 Post by fredx181 »

William wrote: Yes, just for live-boot Fred. But I'm surprised the Porteus-boot from= code isn't used to point to where the filesystem squashfile is. The changes= part does seem to logically point to where, for example, a changes directory would be. I'm thinking there is a mistake in the from= code. Was that all from Porteus or have you modified it somehow. If you modified it, perhaps it is possible to make it point to filesystem squash file whether it is in live folder or not, which would be more logical to me? I remember reading that, as things stand, you are able to just put from=/ (which again seems a bit illogical).
Original Porteus has the "porteus" folder with folders 'base', 'modules' etc.. inside.
It's the variable "FOLDER" in the initscript.
For Porteus-Wheezy I changed that variable to "debian" to make distinction with original Porteus.
Then later changed to "live" to have it the same default name as live-boot.
AFAIK, that variable is needed, a whole lot of other things depend on it.
But maybe it's possible what you suggest (to point to filesystem squash file) but it probably needs changing a lot.
"from=/" works only when the live folder is at the root of the partition.(in fact "from" is parent directory of "live")
Btw, from= can be left out when live is on root of partition.

Fred

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#2538 Post by saintless »

Hi, William.
Here is the post from Fred:
http://murga-linux.com/puppy/viewtopic. ... 797#769797
It was a choice for using both boot methods without symlink in /live/base for Fat partition.
The changes are in porteus initrd1.xz file and are special for DebianDog now. Different from standard porteus boot code.
It was a choice to change porteus-initrd or eventually always to be forced to use live-media-path= for live-boot.
Some boot options for porteus don't work anyway with DebianDog. No use to try changing porteus initrd more. It is involved with a lot of testing which we do not have at the moment.
Also I do not like the idea to rebuild again all initrd.xz files included inside separate kernel modules.

Toni

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#2539 Post by mcewanw »

fredx181 wrote:in fact "from" is parent directory of "live"
Putting it that way does provide a logical understanding of from=. It's just a minor pity that a fixed folder named 'live' is required for porteus-boot case only, but as Toni and yourself say, trying to change that would involve a lot of work and not worth the effort really.

By the way, I like that conkytoggle in your openbox version Fred! Simple, but nice to have.
github mcewanw

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#2540 Post by saintless »

Hi, Fred.
can you, please, make final edit if needed and we can upload new version on the site.
/root changed to $HOME
added information for dpkg registration.

Code: Select all

rm -rf "/mnt/$DRV/$WRKDIR"$HOME/.fltk
rm -f "/mnt/$DRV/$WRKDIR"$HOME/.local/share/recently-used.xbel
rm -rf "/mnt/$DRV/$WRKDIR"$HOME/.local/share/Trash
Toni
Attachments
remastercow2.zip
(3.05 KiB) Downloaded 90 times

Post Reply