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

[mcewanw]

Thanks Toni. I have since booted both DpupWheezy and GuyDog via the DebianDog kernel method you suggested. In both cases their inbuilt mplayer was just as efficient (and pretty much equal to each other) as booting with their own kernel. So the kernel itself is not the culprit on my DebianDog installs... As I mentioned before, the Dec 2013 Porteus-Wheezy worked fine too. For that test I used apt-get to fetch the official Debian Mplayer and, as far as I recall, the cpu load was similar to that of GuyDog and DpupWheezy. I'll next try that mplayer version in DebianDog itself to see if that improves things on this relatively old machine of mine.

EDIT: One thing bothering my mind is that with DebianDog I always have to put vo=x11 in the mplayer config file in order to get video (though it won't fullscreen properly anyway), which suggests it won't work with xv on this old computer. But as far as I recall (I'll have to double check) the old Porteus-Wheezy, GuyDog and also DpupWheezy don't require me to do that and can all go fullscreen with mplayer. Yet, none of them shows as having mesa installed as far as hardinfo check suggested and none had Direct Render. I wonder if Xorg is different or they have some extra driver that works with xv even though they don't have mesa (I think)?

EDIT2: Ah, just remembered, mplayer also using too high cpu on my netbook, which doesn't need vo=x11 in mplayer config and can play videos fullscreen - that's what is really concerning me and why I want to get to the bottom of this. My old machine isn't so important if it was just a driver issue for that.

I'm still wondering if the main system components, for example Xorg, used in that Dec 2013 Porteus-Wheezy are the same as used in current DebianDog. Knowing that would help eliminate other suspects. Hoping you can provide the info for that one Fred!

It was certainly interesting being able to boot into DpupWheezy and later GuyDog via DebianDog vmlinux1 and initrd1.img and also using live-rw for persistent save file... Seemed to work fine! :-)

Fred: Good to hear about the deb install development with choice of grub4dos, syslinux, and extlinux etc. anikin will be happy I'm sure and perhaps the alternative method(s) will work where grub4dos doesn't.

[saintless]

For testing a new debdog-install:
- added syslinux and extlinux as options for choosing bootloader.
- fixed showing (sometimes) wrong label (showing from previous plugged in usb drive).

Hi, Fred!

This new dobdog-install is great! Thank you!
I tested with syslinux and works fine on my both old hardware using plop boot floppy to get USB boot option. I will test it more today.

You also changed the default boot to live-boot-2 which is fine for me but maybe more people will use porteus-boot and we will change porteus as first boot option for next version.

I'm making instruction with pictures to post it in Utilities thread and I will post a message in DebianDog Beta thread. I hope more people will test this new installer if it works for any hardware.

Toni

[saintless]

It was certainly interesting being able to boot into DpupWheezy and later GuyDog via DebianDog vmlinux1 and initrd1.img and also using live-rw for persistent save file... Seemed to work fine!

Yes, it is amazing how well it works this way.
I hoped I can boot DebianDog with Puppy kernel and initrd.gz file from Dpup-Wheezy but it does not work so easy. It needs /etc/rc.d folder to be added in the main module and some other files. I managed to get it boot at last but X fails and it drops to command prompt with error message not finding display. Unfortunately reading the extracted puppy initrd files does not help me much to understand all I need to fix this. Still trying but I do not have big hopes for this. Even if it boots to X I think many other small issues will appear later.

Toni

[fredx181]

This new dobdog-install is great!

Ah, very nice!
Can you wait a few hours with placing a link to it.
It was just for testing, I'd like to change some minor things like the text on the main window.

William, about Xorg on first Porteus-Wheezy, I didn't do anything special so I don't know why it could be different.
Good luck with your continuing search!

Fred

[saintless]

Sure, Fred.

I will wait for your next version. Then I will make new screenshots and a deb package with all needed files for grub4dos from the previous version. Installing the package will be all needed for using the new installer.

William,
Xorg is the same from the first version of Light-Wheezy till now. Nothing is removed or added (unless some later apt-get install program had some new Xorg dependency auto-installed).

Toni

[anikin]

Hi everyone,

I'm still struggling away trying to get efficient mplayer performance on my old Pentium M laptop. Today I tried DpupWheezy to see what the result would be and to my surprise mplayer ran efficiently (three times less CPU than DebianDog on my system) - almost as good as GuyDog. And this apparently without mesa.
So then I checked with lsmod what modules were being loaded, and lo and behold, like GuyDog, it had agpgart and intel_agp and intel_gtt all available as modules under /lib/modules/kernel/drivers/char/agp

(I think that's where it was anyway - no longer running to check location). And all three of these were being auto-loaded on my machine at boot-time. On DebianDog, on the otherhand, there is no such directory of modulesm, instead they are listed as module.builtins for the kernel - that seems to be the key difference (and yes I do see agpgart when checking dmesg, but still mplayer runs rubbish on this machine unless they are loaded as modules, which I can't do with DebianDog).

Then, I backtracked, since I had a recollection the first Porteus-Wheezy, using Porteus kernel worked better on this machine. And sure enough, great mplayer performance on this machine again, and also agpgart.ko, intel_agp.ko and intel_gtt.ko all available and loaded automatically as modules. So that is what I need... But how do I get these modules for DebianDog or can I use that old Portues kernel/modules/firmware somehow on latest DebianDog - I think that would solve it for me?! Might well also solve similar issue for anyone else with a problem when that /lib/modules/kernel/drivers/char/agp directory doesn't exist on their system but instead all built into the official Debian kernel

I quickly ran dpupWheezy, just to have a look at its xorg log and compare it to DebianDog's log:

AIGLX error: dlopen of /usr/lib/i386-linux-gnu/dri/i915_dri.so failed (/usr/lib/i386-linux-gnu/dri/i915_dri.so: cannot open shared object file: No such file or directory)
AIGLX: reverting to software rendering
AIGLX: Screen 0 is not DRI capable
AIGLX: Loaded and initialized swrast
GLX: Initialized DRISWRAST GL provider for screen 0

DpupWheezy, at least uses software rasterization (DRISWRAST - circumcized mesa), whereas DebianDog has none =>

AIGLX error: dlopen of /usr/lib/i386-linux-gnu/dri/i915_dri.so failed (/usr/lib/i386-linux-gnu/dri/i915_dri.so: cannot open shared object file: No such file or directory)
AIGLX: reverting to software rendering
AIGLX: Screen 0 is not DRI capable
AIGLX error: dlopen of /usr/lib/i386-linux-gnu/dri/swrast_dri.so failed (/usr/lib/i386-linux-gnu/dri/swrast_dri.so: cannot open shared object file: No such file or directory)
GLX: could not load software renderer
GLX: no usable GL providers found for screen 0

Can you install 'libgl1-mesa-dri' to check to see if it makes any difference? THe package isn't small - it's obscenely huge 80+MB! However, you only need 2 files: 'swrast_dri.so' for all cards and 'i915_dri.so' if the chip is Intel, or chose what's right for you from the list:

File list of package libgl1-mesa-dri in wheezy of architecture i386

/etc/drirc
/usr/lib/i386-linux-gnu/dri/i915_dri.so
/usr/lib/i386-linux-gnu/dri/i965_dri.so
/usr/lib/i386-linux-gnu/dri/nouveau_dri.so
/usr/lib/i386-linux-gnu/dri/nouveau_vieux_dri.so
/usr/lib/i386-linux-gnu/dri/r200_dri.so
/usr/lib/i386-linux-gnu/dri/r300_dri.so
/usr/lib/i386-linux-gnu/dri/r600_dri.so
/usr/lib/i386-linux-gnu/dri/radeon_dri.so
/usr/lib/i386-linux-gnu/dri/swrast_dri.so
/usr/lib/i386-linux-gnu/dri/vmwgfx_dri.so
/usr/share/bug/libgl1-mesa-dri/control
/usr/share/bug/libgl1-mesa-dri/script
/usr/share/doc/libgl1-mesa-dri/changelog.Debian.gz
/usr/share/doc/libgl1-mesa-dri/copyright
/usr/share/lintian/overrides/libgl1-mesa-dri

The issue is too important to not bring it to a sensible conclusion.

[fredx181]

Hi Toni
Here's new, probably final version of debdog-install.

https://drive.google.com/file/d/0ByBgCD ... sp=sharing
It needed a major change:
When running gparted it went straight to the bootloader choice, fixed.
For the rest just some changes in information text.
And some changes in the scripts in syslinux directory and in syslinux/extlinux/extlinux.conf

Good idea to make deb package!

EDIT: Forgot to switch the order from live-boot v2 to porteus-boot as first.
If you want you can change maybe in syslinux/syslinux.cfg and syslinux/extlinux/extlinux.conf

Fred

[mcewanw]

Can you install 'libgl1-mesa-dri' to check to see if it makes any difference? THe package isn't small - it's obscenely huge 80+MB! However, you only need 2 files: 'swrast_dri.so' for all cards and 'i915_dri.so' if the chip is Intel, or chose what's right for you from the list:
...
The issue is too important to not bring it to a sensible conclusion.

Hi anikin, thanks for that useful information. I've actually already tried libgl1-mesa-dri (the whole lot), though only on my older machine. Whilst some special mesa driver did appear when I then checked hardinfo report it had little if any effect on my mplayer cpu usage on this old machine. I had it in mind to try all that again on my other machine (an Atom powered netbook) but I haven't done that as yet. Good to know if I can get away with only these two files though.

However, as far as mplayer goes, at least as far as the excessive amount of cpu it uses on both my netbook and my older machine:

Alas, it seems to be the version of mplayer itself. I've swapped the DebianDog default version for the other one we tested Mplayer1.1 but the result was just as bad. However, when I instead used apt-get to install the official mplayer from debian the cpu used by mplayer was somewhere between one half and one third (I carefully removed all traces of the default version, including some symlinks to it I found in /usr/bin and /usr/local/bin, which I don't think with hindsight should be there - I actually deleted these symlinks because they seemed to be causing some strange side effects - correct mplayer not being found even though which mplayer revealed its correct location, and the cpu used by mplayer weirdly seemed to be effected too if I left the symlinks in!). All in all some very mysterious stuff going on with my machines at least (hope it's just mine) but really I'm doubting these two slitaz found mplayers now, which is a pity. The one in DpupWheezy runs well (in DpupWheezy) but it has tons of dependencies. Now I'm going to check Fred's openbox version of debiandog, just as a double check.

Really, I've been going round and round in circles for a few days now trying to get to the bottom of this. I have several clean installs prepared just to avoid any trouble.

[mcewanw]

GLX: Initialized DRISWRAST GL provider for screen 0

DpupWheezy, at least uses software rasterization (DRISWRAST - circumcized mesa), whereas DebianDog has none =>

AIGLX error: dlopen of /usr/lib/i386-linux-gnu/dri/i915_dri.so failed (/usr/lib/i386-linux-gnu/dri/i915_dri.so: cannot open shared object file: No such file or directory)
AIGLX: reverting to software rendering
AIGLX: Screen 0 is not DRI capable
AIGLX error: dlopen of /usr/lib/i386-linux-gnu/dri/swrast_dri.so failed (/usr/lib/i386-linux-gnu/dri/swrast_dri.so: cannot open shared object file: No such file or directory)
GLX: could not load software renderer
GLX: no usable GL providers found for screen 0

Anikin, Just looking at the above leads me to wonder, what is it that is in DpupWheezy that provides DRISWRAST, is that swrast_dri.so? And when you suggest also i915_dri.so for chip Intel, is that to provide hardware-based direct rendering rather than software renderer? I imagine at least software renderer (no matter what graphics chip is used in the system) would be useful in default iso if my understanding of your comments is correct.

I've noticed there might also be this:

http://mentors.debian.net/package/mesa-legacy

libgl1-mesa-dri-legacy, which may or may not be relevant for my older computer.

[mcewanw]

Oddly, I've just tried DebianDog openbox version and mplayer seems to consume only half the CPU as it does on DebianDog jwm, but I could be wrong and hope some of you other guys can test that.

EDIT: That seems to have been another mysterious fluke. On a second run the CPU load for mplayer on this machine is just as high as on jwm version of DebianDog. So far I therefore stand by my feeling that there is something not good about these two mplayers, at least for DebianDog (the svn version and the 1.1 version, both from slitaz originally). But so many weird results I need someone else to check against other distribution's mplayer and against official (big) Debian mplayer. On this old machine of mine top suggests that mplayer is consuming almost 40% cpu running video in small window, which is roughly twice as much as when I tested with official Debian mplayer on clean system. Actually, on the openbox version the result seems to be intermittent (sometimes ok, sometimes not - hope others can test in case just my machines). Also, compare against DpupWheezy running same video if you can.

This is on my old Pentium M 1.6GHz, I GB ram machine, so maybe your results will be different. I do note that no direct rendering or software rendering on this one either. Hopefully we can include swrast_dri.so by default without needing full mesa installed?:

Xorg.0.log extract:

Code: Select all

[    37.829] (EE) AIGLX error: dlopen of /usr/lib/i386-linux-gnu/dri/r300_dri.so failed (/usr/lib/i386-linux-gnu/dri/r300_dri.so: cannot open shared object file: No such file or directory)
[    37.829] (EE) AIGLX: reverting to software rendering
[    37.829] (II) AIGLX: Screen 0 is not DRI capable
[    37.829] (EE) AIGLX error: dlopen of /usr/lib/i386-linux-gnu/dri/swrast_dri.so failed (/usr/lib/i386-linux-gnu/dri/swrast_dri.so: cannot open shared object file: No such file or directory)
[    37.829] (EE) GLX: could not load software renderer
[    37.829] (II) GLX: no usable GL providers found for screen 0

[anikin]

what is it that is in DpupWheezy that provides DRISWRAST, is that swrast_dri.so? And when you suggest also i915_dri.so for chip Intel, is that to provide hardware-based direct rendering rather than software renderer? I imagine at least software renderer (no matter what graphics chip is used in the system) would be useful in default iso if my understanding of your comments is correct

Yes, that's how I understand it.
Mesa = swrast_dri.so (common for all chips)
+
i915_dri.so/i965_dri.so/nouveau_dri.so/nouveau_vieux_dri.so/r200_dri.so/r300_dri.so/r600_dri.so/radeon_dri.so

There must have been a good reason, why pemasu put the common part into his dpup. He's very particular about this stuff.

[saintless]

Hi, Fred.
Added here and in the first post:
http://murga-linux.com/puppy/viewtopic. ... 949#774949

EDIT: Forgot to switch the order from live-boot v2 to porteus-boot as first.

I left live-boot-2 as default. I changed grub4dos the same way in the deb package. The reason to change default boot from live-boot-3 was RemasterCow does not work there and it can not be used from first boot without save file.
But if we leave porteus-boot default and someone decide to make full remaster with RemasterDog (which is possible with 2 Gb RAM) this will include 021-apps-porteus in the main module. Then with live-boot-2/3 it will start porteus make save file changes.dat for every boot and porteus loadmodule.
I think live-boot-v2 is the best default boot for any case.

Toni

[fredx181]

Hi Toni,

But if we leave porteus-boot default and someone decide to make full remaster with RemasterDog (which is possible with 2 Gb RAM) this will include 021-apps-porteus in the main module. Then with live-boot-2/3 it will start porteus make save file changes.dat for every boot and porteus loadmodule.
I think live-boot-v2 is the best default boot for any case.

Yes, I see what you mean.
live-boot v2 is fine by me as default but still the problem persists if a user makes remaster using porteus-boot, right?
I did already with some scripts a check if a typical porteus-boot file exists (in /mnt/live/..) and if not uses /live/cow instead of /mnt/live/memory/changes.
For example new apt2sfs does that.
I'll look at it, maybe it's even possible not needing 021-apps-porteus at all.

Nice pictures for the installer in the utilities thread!

Fred

[saintless]

Hi, Fred.

live-boot v2 is fine by me as default but still the problem persists if a user makes remaster using porteus-boot, right?

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

Most of the programs using /live/cow and /live/image are universal for porteus-boot and live-boot-2. We have symlinks in 021-apps-porteus for /live/cow and /live/image

My opinion is not to change something that works. 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.

Toni

[saintless]

Hi, William.

... (I carefully removed all traces of the default version, including some symlinks to it I found in /usr/bin and /usr/local/bin, which I don't think with hindsight should be there - I actually deleted these symlinks...

I can't find anything mplayer related in /usr/bin. Can you point what links you have there? I guess your problem after apt-get mplayer comes from /opt/bin/mplayer links since /opt/bin is first in PATH

Testing machine IBM Netvista PIII-600Mhz, 128 Mb RAM, 2Gb SWAP. Playing the same video file after first boot fresh install without save file for DebianDog-jwm and DpupWheezy:

DebianDog gmplayer = 44% CPU


DebianDog using xhippo = 34% CPU


Dpup-Wheezy gmplayer = 31% CPU


Xorg log for debianDog:
http://smokey01.com/saintless/Fredx181/ ... Xorg.0.log
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. This video is playing real nice on this machine with DebianDog xhippo and gmplayer. Even Turbopup can't play it so nice.

Toni

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

[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

[fredx181]

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

[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

[saintless]

Hi, Fred.

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