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

[saintless]

Hi, William.

This is DebianDog base (no WM):
http://live.debian.net/files/stable/ima ... andard.iso
You will find KDE, XFCE, LXDE, Gnome and rescue cd version there:
http://live.debian.net/files/stable/ima ... so-hybrid/

I will see if I can make older 2.6.x kernel to work in DebianDog as separate module. But it will work only with gz compressed main module since xz is not supported in 2.6.x

Toni

[saintless]

Hi, Stemsee.

Is there any chance some of the modules were compiled for another kernel?

Very possible if I had something to do with this compiling. But since it is official kernel and firmware included in official Debian Live Cd and available for download ready for use from Debian repository - the answer is no.

Otherwise i shall wait for your distro to mature before settling on it.

I think it will be best. It may take some time till it mature as Puppy did...

Have you thought about joining woof-ce development on github?

My view of Puppy linux future development is much different from what happens there. I prefer to explore the option to make Debian Puppy lookalike.

Toni

[mcewanw]

I will see if I can make older 2.6.x kernel to work in DebianDog as separate module. But it will work only with gz compressed main module since xz is not supported in 2.6.x

Toni

That's nice of you Toni. Be interesting to see how it performed. I was considering trying something like that with the kernel from GuyDog, since then I could take the mesa drivers out of there too.

Code: Select all

GuyDog:
uname -a
Linux puppypc7880 2.6.39 #1 SMP PREEMPT Fri Aug 5 11:19:11 GMT-2 2011 i686 GNU/Linux

However, being unfamiliar with the process I'd probably never get round to it because it would take me too long. I presume these kernel modules comprise the separate vmlinuz along with a squashed fs containing the compatible modules and firmware basically?

The package manager in GuyDog accesses squeeze packages, though I imagine Iguleder compiled the kernel himself. Still I imagine you are thinking of trying a kernel from squeeze distribution, which I know you are familiar with since you started off with a Light Debian Core Squeeze. Of course a 2.6.x version might perform better on your older machine too.

Myself and my two year old son are clearly back from our two hour kayak trip now. It is Autumn here now and the sea (and moreso the river estuary) was like refreshingly cold tap water, but the sun was still reasonably nice and warm at around 19 deg C, with no wind and just relaxing rolling waves. No kayak tomorrow though, we'll be cruising around on a bicycle instead.

[saintless]

Uploaded new ffmpeg2sfs with information button added instead separate readme.txt file. (Thank's, Fred!)
http://murga-linux.com/puppy/viewtopic. ... 385#773385

Fred,
can you suggest some better way or command for resizing save file which can make it also smaller? Check the attached archive. I use resize2fs but it breaks something in the save file structure if it is in use while resizing. fsck finds many errors after that. Especially if I choose to shrink it while it is in use. It will be nice to make it smaller but may be it is not safe enough at least with resize2fs.

Toni

[saintless]

Hi, William.

Unfortunately I still struggle to make Puppy kernel with Puppy initrd.gz file to work with DebianDog main module. I got it to boot but it errors starting X and drops me back to command prompt. Still trying because this can give us new type of save file options.

Yes, I will make separate module from Squeeze. I will check out what available kernels are included in Squeeze Live Cd.

Toni

[fredx181]

can you suggest some better way or command for resizing save file which can make it also smaller?

I'm almost sure that the only reason for the problem is that you resize when savefile is mounted.(It's just not possible AFAIK)
When unmounted it's always ok (just did a few tests).
But anyway I would add a e2fsck line in the script before and after resize command so becomes this:

Code: Select all

e2fsck -y $P/$F
echo y | resize2fs -f $P/$F ${Size}m		# format Image file
e2fsck -y $P/$F

The moment I complained about a "not clear head" was the start of being ill the last couple of days, mostly lying in bed.
So until I'm a little better there won't be much activity from me here.

Fred

[saintless]

Thank you, Fred!
Take care of your health and rest. Nothing important needed anyway. I just try to modify some scripts from you and Terry for different actions we need.

Unmounted save file resizing works fine. Regarding man page resize2fs: http://linux.die.net/man/8/resize2fs

If the filesystem is mounted, it can be used to expand the size of the mounted filesystem, assuming the kernel supports on-line resizing.

But I need to test proper if it works with ext2, ext3 and ext4 the same way. The problem is shrinking mounted save file. resize2fs can't do it safe.
I just want to explore if we can use resize2fs for this or to search for another option.

Toni

[saintless]

Hi, William.

This is just for your testing and I will remove it from the site after you confirm download and boot without problems.
Unsquash the main module and make gz compression.

Code: Select all

unsquashfs -d /live/image/work-folder /live/image/live/01-filesystem.squashfs

Code: Select all

mksquashfs /live/image/work-folder /live/image/live/01-gzip.squashfs

Download and extract the archive in /live (it is 133Mb with 3 kernels included):
http://smokey01.com/saintless/Fredx181/ ... -2.6.x.zip
There is readme text inside.

Code: Select all

Use live-boot-2 code only and live-rw save file if needed:

For kernel-2.6.32-5-486
vmlinuz1a
initrd1a.img

For kernel-2.6.32-5-686
vmlinuz2a
initrd2a.img

For kernel-2.6.32-5-686-bigmem
vmlinuz3a
initrd3a.img

If you do not use live-rw save file on your boot partition it will be mounted read-only. To remount it rw just single click /opt/bin/remount-rw script.
If some of the kernels worth permanent upload I will make separate module with update dpkg option later. This one is only for testing.

Toni

[fredx181]

Hi Toni
I saw in the other thread about problems with the firefox-portable deb.
Sylvander is right: some things are wrong, here's a good one.
Fixed menu-update (runs update-menus in postinstall script)
Fixed ability for default_web-browser when changing in "set-default-apps" (didn't previously work because of symlinked to portable script /opt/bin/firefox , which I changed so that it works now.)

https://drive.google.com/file/d/0ByBgCD ... sp=sharing

Fred

[saintless]

Thanks, Fred.
I will replace it tomorrow morning.
If you can help there with porteus-boot from CD and searching for changes.dat file on top of any hard drive partition it will be nice. I'm not sure what is the right code for this but I will do some testing tomorrow.

Toni

[fredx181]

Hi Toni,

If you can help there with porteus-boot from CD and searching for changes.dat file on top of any hard drive partition it will be nice.

When using changes=/changes.dat it will be found if on root of hard-drive (and I think, if not present on harddrive it searches root of usb drives.)

Maybe better to create unique foldername somewhere with changes.dat inside (it will be found) so then:

Code: Select all

changes=/uniquename/changes.dat

Or give changes.dat itself a unique name:

Code: Select all

changes=/uniquename.dat

or even "somename.dat" in folder "uniquename" :

Code: Select all

changes=/uniquename/somename.dat

This way you can use multiple savefiles.
Hope this helps.


Fred[/code]

[mcewanw]

Hi, William.

This is just for your testing and I will remove it from the site after you confirm download and boot without problems.

I've downloaded it Toni. Won't be able to test it till later, but I'll report back once I do. Thanks!

[sunburnt]

Hi guys; Sorry about the delay, I`ve been busy with little time to myself.
Tested Fred`s new debdog-install and it`s just about the same.
Freezes on my Pentium-D and on Olga`s HP laptop, and must be killed.
I tried it with the USB mounted and unmounted ( I assume it does not matter ).
Last time I tried the /live dir. install, this time I tried the iso install.
I see no way to partition a drive.? Only install and make bootable buttons.
I did not test the make boot button. Install button only copies DebianDog.?

Here`s the xterm output ( widget error is new ):

Code: Select all

root@debian:~# debdog-install
widget_entry_refresh(): <label> not implemented for this widget.
widget_entry_refresh(): <label> not implemented for this widget.

CHECKBOX="true"
FILE_BROWSE_DIRECTORY=""
FILE_BROWSE_FILENAME=""
FILE_DIRECTORY=""
PART="sdb1"
PF="/media/sda3/0_ISOs/DebianDog-Porteus-jwm_icewm-beta.iso"
EXIT="INST"

[saintless]

Hi, Terry.
Just select the drive and use Run gparted button to format it with gparted. We have preview here:
http://ns1.murga-projects.com/puppy/vie ... c0c#773207
I also see this as output in xterm but no problems to boot the flash here with sislinux and grub4dos.

Code: Select all

widget_entry_refresh(): <label> not implemented for this widget.

Toni

[mcewanw]

Code: Select all

Use live-boot-2 code only and live-rw save file if needed:

For kernel-2.6.32-5-486
vmlinuz1a
initrd1a.img

For kernel-2.6.32-5-686
vmlinuz2a
initrd2a.img

For kernel-2.6.32-5-686-bigmem
vmlinuz3a
initrd3a.img

Just a quick report on the above Toni. On my Pentium M machine, 1a and 2a both boot up to the desktop but then everything freezes and I have to manually switch off via the power button. This machine is not PAE capable so not using 3a here anyway.

However, on my Intel Atom netbook, all three booted up fine. But, there was no improvement on the machine to the default kernel 3.2.0-4-48. Whatever, I tried, it was basically just the same, so I'll just stick with 3.2.0-4-48 since there may be other problems with these older kernels that I haven't time to test further.

The only thing I wouldn't mind getting feedback on is for you to try mplayer in debiandog_jwm and compare the cpu load watching the same video clip in debiandog_openbox version. On both my machines, when running openbox version mplayer is consuming around half the cpu compared to running in jwm version. As far as I know it is not because the mplayer itself is different (I tried the gnome-mplayer from Fred in the jwm debiandog, but that didn't change anything). Rather, there seems to be some other stuff (libs?) in the openbox version that improve mplayer performance - I failed to find out what...

Does anyone else find the same result comparing debiandog_jwm mplayer, debiandog_openbox mplayer and official debian mplayer when playing same video?

EDIT: I've retested the above mplayers and I can't duplicate what I thought were my earlier results - now both mplayers produce much the same cpu load. Perhaps I mistakenly used a different video to test them first time round. However, I definitely get better much lower mplayer cpu load (around half) with official debian mplayer download, though I think that is to do with additional libs rather than the mplayer itself.

Note that playback is smooth in all cases on both my machines - just the different mplayer cpu load, which only effects things when I otherwise load up the machine - then the video can become jerky if total cpu load approaches 100% of course.

I've decided to stop chasing this now. I just can't find the difference and am satisfied with the official debian mplayer in the netbook, where the additional size doesn't matter to me anyway

[fredx181]

Hi William,
Finally took the time to do some mplayer testing now.
I just tested different mplayer versions using the command line (mplayer) with same movie everytime (360p) only on openbox version.
First, included mplayer (from default installed gnome-mplayer) uses around 20% cpu.
Then uninstalled (gnome-)mplayer) and installed mplayer from debian-mutimedia, result is the same, around 20% cpu.
Installed mplayer2 , result is the same, around 20% cpu.
Uninstalled everything related to mplayer and installed the gmplayer from DebianDog_Jwm: result: double cpu usage (around 40).
Uninstalled it and tried the other gmplayer you once found (gmplayer_1.1): result: double cpu usage.

So it seems to me that the gmplayer versions use a lot more cpu.

Fred

[fredx181]

Hi Toni,

Edit: Just found this one here:
http://tuxx-home.at/archives/2005/02/16/T13_36_14/

I did a test with this script and doesn't work at all.
But I found that it's because of ":i386" in some of the names in /var/lib/dpkg/info.
So I changed line 66 to filter that out and it works very well now

Attached: restore-dpkg-status.zip

Suppose you lost or have a corrupted /var/lib/dpkg/status it'll be a good rescue and it could now probably be useful for your experiments I think.
To test it just rename status in /var/lib/dpkg to something else.
Run the script, and in /tmp there's "status.new" file.
Rename to "status" and copy to /var/lib/dpkg
Then try for example "apt-get -f install" or install some package and you'll see that dpkg works as good as before.(well, for me it did)
The size compared to original status file is different because it took information from "available" which is a little different but apparently sufficient.

Edit: Could it be a good idea to not rename /var/lib/dpkg/info by remastercow and run the restore-status script from loadmodule (or somehow at boot) to "update" status file?
(maybe you had simular idea and I didn't catch exactly that)

Fred

[saintless]

Thank you, Fred!

The idea to update dpkg database is to do it manually only if the user decide so.
Unfortunately it is far more complicated as I thought because some programs like gnome-mplayer for example recreate some files inside /var/lib/dpkg/info like Synaptic and XFE and this programs are generated as new ones. Updateing dpkg this way will put Synaptic and Xfe for example 2 times in status and dpkg is broken again.
It is not possible or at least not worth to try to cover all problems like this by checking for duplicate status entry.

The script will be very useful for me to create dpkg-update script for modules wih many packages but it can't be full automated safe. Or at least not worth the effort.

Toni

[fredx181]

Edit: "How to create a local database from .deb files":
Moved to HowTo Thread:
http://murga-linux.com/puppy/viewtopic. ... 007#776007

Fred

[fredx181]

Unfortunately it is far more complicated as I thought because
.......

Ah, I see, that's a pity.

Fred