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

[fredx181]

Hi Toni,

If you are ready we can upload Open/box version with post what fixes are included there. I don't think it is needed to update both versions at the same time since they need different fixes.

Yes, but since there are also similar things I'll wait till you say you are ready, it's nicer to to announce both uprgrades.

Btw, what's that about "fix blkid path for user" for remastercow?, I missed that, I think.

gdmap will be nice as right-click option if possible.

Fred

[saintless]

OK, Fred.
I will write here when I'm ready.

In older RemasterCow in puppy user I could type sda1 instead of choice from menu as in the last version. Now I can't select or type manually drive sda1 since blkid is needed and it is inside /sbin

I'm not sure how to make gdmap right click option but I will try.

Toni

[dancytron]

I was just able to get gdmap to work as a right click by using the command line

Code: Select all

gdmap --folder=%f

in the "Edit Actions" dialog in Thunar.

Dan

[fredx181]

Hi Toni,
Not very important, but I like to understand; I think with below you mean it's not editable anymore (yes,which is good) as it was previously:

In older RemasterCow in puppy user I could type sda1 instead of choice from menu as in the last version.

But next you wrote I still don't get it:

since blkid is needed and it is inside /sbin

Btw, was it for root different then?

The command for gdmap to view directory is:

Code: Select all

gdmap -f <path/to/directory>

Fred

[fredx181]

I was just able to get gdmap to work as a right click by using the command line

Code: Select all

gdmap --folder=%f

in the "Edit Actions" dialog in Thunar.

Dan

Yes, It's nice, these custom actions, one of the reasons Thunar is my favorite file-manager
Btw, lots of nice things to find when you google for "Thunar custom actions"

Fred

[saintless]

Hi , Fred.
sbin is not in path for user puppy and typing root to start remastercow does not include sbin in path from user puppy account. I can not select drive sda because blkid is not found and I can not type sda1 anymore as I could in previous remastercow. For root all is fine.

Toni

[fredx181]

Hi Toni,
Thanks, I understand more now.
Except if you fixed it or not. (from what you say, it looks like not)
Right now it's working good for you when using remastercow from puppy?
I'm a little obsessed about things working properly for multi-user because of the mistakes I made.
I just checked remastercow with user puppy and all fine here.(maybe I have different configuration for PATH on openbox version)

Fred

[mcewanw]

Hi mcewanw and everyone,

A small, but important item is missing here:

Proprietary, binary-only firmware (aka microcode) was removed from the Debian kernel's radeon DRM driver in linux-2.6 2.6.29-1, to resolve Debian bug 494009. The firmware can be provided by installing the firmware-linux-nonfree package.

Already tried that a while back anikin, but, thanks, I'll try it again in case I made some error back then - I certainly don't have that installed at the moment.

Code: Select all

apt-get install xserver-xorg-video-ati
apt-get install libgl1-mesa-dri
apt-get install firmware-linux-nonfree

Actually, I think xserver-xorg-video-ati was already installed but I did need both libgl1-mesa-dri and firmware-linux-nonfree I think. I'll have to try all this again just to be sure.

[saintless]

Hi, Fred.

Except if you fixed it or not. (from what you say, it looks like not)

It will not work from jwm/icewm iso on the site from puppy account.
Otherwise it is fixed. The fix is not for RemasterCow but for user account puppy. The easiest way is to symlink /sbin/blkid to /opt/bin
The proper way to fix it is to make su-to-root to add /sbin in PATH when it is executed from user account (still searching for such fix).

I just checked remastercow with user puppy and all fine here.(maybe I have different configuration for PATH on openbox version)

Yes, I think OpenBox version uses /etc/environment to set PATH. I also had PATH in /etc/environment but I changed this in JWM/IceWM version because XDM display manager sets the PATH separate from the system for user and root account.
The problem using /etc/environment is user account has the same PATH as root account and can execute all programs inside secure bin (/sbin, /usr/sbin). Later William found how to set PATH from XDM configuration file for user account and I removed the PATH from /etc/environment
In JWM/IceWM version PATH setup is in /etc/profile and XDM configuration file for puppy account.

Toni

[fredx181]

Hi Toni,

Yes, I think OpenBox version uses /etc/environment to set PATH. I also had PATH in /etc/environment but I changed this in JWM/IceWM version because XDM display manager sets the PATH separate from the system for user and root account.

Ok, I see now, indeed openbox version uses /etc/environment to set PATH.
You can change line 20 in remastercow:
From:

Code: Select all

devs="$(blkid.............

to:

Code: Select all

devs="$(/sbin/blkid.............

For some other scripts(apt2sfs,remasterdog...) it's the same problem I guess.

The dropdown box for choosing a drive shouldn't be editable anymore with these scripts.

Fred

[saintless]

Hi, Fred.

You can change line 20 in remastercow:

Or I can set the PATH in /etc/environment which also works but the user account should not have access to secure bin without sudo or su-to-root.

I think the problem is more complicated and needs proper fix. In the existing DebianDog Jwm/Icewm sudo gives more permissions than su-to-root (user password gives more permissions than root password). I like to find proper fix for this issue.

Code: Select all

# After commenting gsu (ktsuss) line in RemasterCow:

# Executing direct remastercow in terminal from puppy (/sbin/blkid not found):
puppy@debian:~$ remastercow 
/opt/bin/remastercow: line 20: blkid: command not found
puppy@debian:~$ 

# su-to-root remastercow from puppy account (/opt/bin not found):
puppy@debian:~$ su-to-root -c remastercow
About to execute remastercow.
This command needs root privileges to be executed.
Using su...
Enter root password at prompt.
Password: 
bash: remastercow: command not found
Incorrect password or command failed. Try again? (y/N)
puppy@debian:~$ 

# Full path su-to-root /opt/bin/remastercow (all works fine):
puppy@debian:~$ su-to-root -c /opt/bin/remastercow
About to execute /opt/bin/remastercow.
This command needs root privileges to be executed.
Using su...
Enter root password at prompt.
Password: 
sda1 sda2 sda4
puppy@debian:~$ 

# ktsus remastercow (/sbin/blkid not found):
puppy@debian:~$ ktsuss remastercow
/opt/bin/remastercow: line 20: blkid: command not found
puppy@debian:~$ 

# sudo remastercow works best but it needs user password instead root password:
puppy@debian:~$ sudo remastercow
[sudo] password for puppy: 
sda1 sda2 sda4
puppy@debian:~$

# In the existing DebianDog sudo and typing user password gives more permissions than su-to-root and typing root password.

Toni

[fredx181]

Hi Toni,

I think the problem is more complicated and needs proper fix. In the existing DebianDog Jwm/Icewm sudo gives more permissions than su-to-root (user password gives more permissions than root password). I like to find proper fix for this issue.

Code:
# After commenting gsu (ktsuss) line in RemasterCow:

# Executing direct remastercow in terminal from puppy (/sbin/blkid not found):
puppy@debian:~$ remastercow
/opt/bin/remastercow: line 20: blkid: command not found
puppy@debian:~$
.......
.......

I think here's solution:
I compiled latest ktsuss after making a minor change in the source code.
Just changed "-p" to "-" which means it does 'su - root' now instead of 'su -p root', it should find right PATH now.
Here's deb I made from it, attached (remove dummy .tar extension)

Fred

[saintless]

Thank you, Fred!
New ktsuss package works.

Toni

[fredx181]

Hi Toni,
I'd like to experiment with the restore-dpkg-status script.
And specially for restoring status including packages from loaded module.
As you wrote:

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.

How exactly can I reproduce this situation where dpkg gets broken?

From what I did sofar it's working without problems.
Btw, what I noticed is that apparently dpkg removes the files "available-new" and "status-new" created by new remastercow.
That is: when installing something of course.
When I renamed first to e.g. "availablenew" it's not removed.

I run this script with a module loaded at boot made by the new remastercow:
(available-new must still exist otherwise it fails)

Code: Select all

#!/bin/sh
mv /var/lib/dpkg/info-new/* /var/lib/dpkg/info
mv /var/lib/dpkg/available-new /var/lib/dpkg/available

restore-dpkg-status.sh
mv /var/lib/dpkg/status /var/lib/dpkg/statusorig
mv /tmp/status.new /var/lib/dpkg/status # new status file created corresponding with the new loaded module.

Fred

[saintless]

Hi, Fred.

Btw, what I noticed is that apparently dpkg removes the files "available-new" and "status-new" created by new remastercow.

This is strange. I will test it later. It will be better in this case to use statusnew and availablenew in RemasterCow.

You have different approach which is not what I mean.
You keep all dpkg information inside status-new and available-new in separate module created with remstercow. Then you replace old available with available-new and move info-new files in info folder. Then you run restore-dpkg-status and it works, but...

1. You will rewrite /var/lib/dpkg/status file every time changing the content with the one created from restore-dpkg-status script. It is not tested proper yet and you replace the original created from the system status file with new one created from restore-dpkg-script. But maybe it is OK and no further problems will appear later.

2. You have to use available-new from the separate module to make restore-dpkg-status script to generate proper status file. But it is very possible you will try to do this on remastered version or using save file DebianDog after installing other packages. Then replacing available with available-new from the module will leave later installed packages out of /var/lib/dpkg/available and even if restore-dpkg-status script does not fail, it will not include later installed packages in new created status file.

What I mean is to include in this separate created module only the packages included in this separate module. status-new and available-new will have only the packages included in this module. Then we append the information from status-new and available-new in status and available. This is better approach but still not perfectly safe because later installed packages can duplicate packages included in this separate module. Then appending the information from status-new and available-new will add two entries for the same package in status and available and this will break dpkg.

To test this just open status and available files and add section with any package information two times and run apt-get update.

I'm not sure if I can make it clear enough but any questions you have I will try to answer.

Toni

[fredx181]

Hi Toni,
Thanks very much for your detailed reply.
This has to "sink" deeper in my head to really understand, yes, I do see now it's more complicated than I thought
I'll chew on this.

Fred

[saintless]

Hi, William.

Just in case you need again to remove all gmplayer files from Jwm/IceWm version install this package:
http://smokey01.com/saintless/Fredx181/ ... 6_i386.deb
It will overwrite all gmplayer files and symlinks and will remove all after:

Code: Select all

apt-get purge gmplayer-portable

Toni

[saintless]

I'll chew on this.

I really doubt that, Fred and I'm sure you can make this work but as I wrote it does not worth the effort.
Most probably I'm the only one who will use dpkg-update from separate module and I can do it easy manually anyway. For anyone interested there is information in HowTo thread.

Toni

[saintless]

Hi All,
Here's modified rcconf using Xdialog.
Default is Xdialog but can still also be run from terminal to use dialog or whiptail.
For example:

Code: Select all

rcconf --dialog

Fred

Thank you, Fred!
Included. I think tomorrow if all is working as I hope I can make new iso for upload.

BTW rcconf ( I will rename it to rcconf-xdlg) needs sudo for user account if you also include it in OpenBox version. I will make separate startup script to execute xterm -e sudo for user account and just rcconf for root.

Toni

[fredx181]

Hi Toni,

fredx181 wrote:
I'll chew on this.

I really doubt that, Fred Smile and I'm sure you can make this work but as I wrote it does not worth the effort.

Your words are making me see it as a challenge instead of giving up
Anyway I'd like more flexibilty in loading and creating modules for use just for myself.
And I think I'm on track of something.
I had trouble to understand your approach because I was fixated on creating a new status file from /var/lib/dpkg/info files and available file.
But now I see now that it's better to just concentrate on the status file itself( not recreate it completely)
.
Just to share the progression I made (well, I hope it is) here's "restdpkg" script attached.

It will work only with modules created by remastercow (btw, changed "available-new" to "availablenew" and "status-new" to "statusnew" in remastercow)
I tested only with porteus-boot and the script won't work for now with live-boot.
With porteus-boot the modules are mounted in /mnt/live/memory/images (with live-boot it could be similar with the 'showmounts' boot option)
The script searches (in all modules mounted in /mnt/live/memory/images) for 'availablenew' and 'statusnew'.
Then it merges them together with the main status file (/var/lib/dpkg/status) to a temp file
It's a bigger file then with lots of duplicates so let's remove the duplicate package entries (nice 'awk' line I found on the web does that very well) and then the new 'main' status file is created.
(see more info inside script)

Ok, I stop now ,it's just very experimental of course, needs a lot more thought about how and when to use.

Edit:

BTW rcconf ( I will rename it to rcconf-xdlg) needs sudo for user account if you also include it in OpenBox version.

Any reason for "sudo"? I think I just make .desktop file with "Exec=gsu rcconf.xdlg" line.

Fred