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

[bobc]

Hi, Bobc

I select the iso file off sdc1, and then highlight sda7 and click install. it says its formatting it, and then gets the error..

I had the same problem once posted here:
http://ip-208-109-22-214.ip.secureserve ... 312#772052
Can you check if you are booting latest DebianDog iso from here;
http://smokey01.com/saintless/DebianDog/
I can't reproduce it now but maybe because I can't test the same hardware and the same partition setup you have.
Can you test this:
Run DebianDog full installer again and try to install it in the same partition (sda7). When you get the error close and start the installer and try again the same.
If you get the same error close the installer. Try to mount sda7 manually by clicking the desktop drive icon and start the installer again. If it does not work I will try to make the same partition setup as you.

Toni

I think its a problem with the file type variable on the mount having ext4 then 2 newlines then vfat. I will reboot and run from a terminal to confirm

[bobc]

I think its a problem with the file type variable on the mount having ext4 then 2 newlines then vfat. I will reboot and run from a terminal to confirm

Well, this time it didn't happen, so that means it has something left hanging from a previous install attempt where I didn't select things correctly.

Just for fun I will reboot and see if I can figure out how I goofed it so you can see a way to clear to prevent someone else from tripping it again another day. I had tried a number of times.

PS: I tried and now it won't do it. the only thing vfat is the boot usb. Initially, I didn't understand that I needed a 2nd flashdrive with the iso file, and I was originally trying to install it from the boot usb, and my guess is that i didn't reboot it, and maybe even inserted the ntfs flashdrive with the iso while the program was running with the select screen up.

I will try one more time...

[saintless]

Hi, Fred.

I think we can remove some lines because we get warning messages but I need your confirmation it will be safe:

Code: Select all

debdog-full-install
widget_entry_refresh(): <label> not implemented for this widget.

Removing line 93 fixes this:

Code: Select all

	<label>Select a .iso file</label>

Code: Select all

debdog-install
pwd=/live
widget_entry_refresh(): <label> not implemented for this widget.
widget_entry_refresh(): <label> not implemented for this widget.

Removing line 98:

Code: Select all

	<label>Select a .iso file</label>

and line 114 fixes this:

Code: Select all

        <label>Select a Directory containing DebianDog Files</label

About the problem Bobc had I think it could be because of the command:

Code: Select all

		mount -t "$FS" "/dev/$PART" "$MNT"

I will try to reproduce partition mount failed message later.

Toni

[saintless]

PS: I tried and now it won't do it. the only thing vfat is the boot usb. Initially, I didn't understand that I needed a 2nd flashdrive with the iso file, and I was originally trying to install it from the boot usb, and my guess is that i didn't reboot it, and maybe even inserted the ntfs flashdrive with the iso while the program was running with the select screen up.

I will try one more time...

Thanks, Bobc.
I will try to get this error too. Maybe it is because NTFS and Vfat partitions present and I have only ext and vfat at the moment.

Toni

[bobc]

PS: I tried and now it won't do it. the only thing vfat is the boot usb. Initially, I didn't understand that I needed a 2nd flashdrive with the iso file, and I was originally trying to install it from the boot usb, and my guess is that i didn't reboot it, and maybe even inserted the ntfs flashdrive with the iso while the program was running with the select screen up.

I will try one more time...

Thanks, Bobc.
I will try to get this error too. Maybe it is because NTFS and Vfat partitions present and I have only ext and vfat at the moment.

Toni

I tried again, but still couldn't duplicate it. I tried a few times again.

I've had many problems with corrupt vfat flashdrives lately, and that is why I formatted the one as ntfs.

LOL, it only doesn't work when you aren't looking for it!

Anyway, thanks for helping. I wish I could make it do it again, but failed. I need to sleep. Thanks again...

[fredx181]

Hi bobc, Toni,

Partition Mount Failed
The reason for this can be: You selected a 'Raw' drive e.g. 'sdb'
Please try again and select a numbered partition e.g. 'sdb1'

Thanks for reporting!

At first I couldn't reproduce it also but later I could.
It's a mistake I made in the script.

Indeed as Toni mentioned, it's in this line:

Code: Select all

mount -t "$FS" "/dev/$PART" "$MNT"

To reproduce:
Choose a partition to install to with another filesystem than ext4 e.g. vfat
What happens then is that the variable "$FS" will be 'vfat' as so it was registered at the start by the installer.
But in the meantime the partition is formatted already to ext4.
Then the mount command gives error as it refuses to mount an ext4 partition with the "-t vfat" option.
So changing the line to this should solve it:

Code: Select all

mount -t ext4 "/dev/$PART" "$MNT"

I found some more issues btw, I made it to hastily based on debdog-install (frugal) and not thoroughly tested.
(Btw, full install is not recommended, a lot of nice features won't work e.g. loading modules)
I'll come up with a new script later, (also needs more error checking)

Edit: New debdog-full-install attached, changes:
- fixed the filesystem type for mount command: mount -t ext4 "/dev/$PART" "$MNT", see above.
- Error checking: In case a user choose a save or boot partition, message will show that it cannot be used (see picture)
- In case of multiple partitions, setting the boot flag will be default for first partition and also menu.lst and grldr will be on first partition (it will do that only if first partition exists (there may be very rare case there's no 'sda1' or 'sdb1') if not, then it will be on the 'install' partition)
I thought this would be better as grub4dos searches for menu.lst at first on the 1st partition.
- In case of canceling the bootloader-install (grub4dos), the boot flag will not be set either (was (wrongly) already done in that case with old debdog-full-install)

Fred

[saintless]

Thanks, Fred.
Added in next version changes post.

Toni

[bobc]

Most installs don't require the iso file to install, and can install from the boot flashdrive.

Maybe when you rewrite it you could get it to do that? I initially was trying to get it to use the boot flashdrive which was vfat.

But at least you got it fixed so it doesn't just give an odd error and not install.

Thanks much... It looks nice a nice OS and I like the looks of your JWM interface.

[fredx181]

Subject description: could it be made to install from the boot flashdrive instead of needing 2 flashdrives?
Most installs don't require the iso file to install, and can install from the boot flashdrive.

I'm not sure what you mean, selecting a folder from flashdrive instead of .iso maybe?
Anyway, sorry, something like that will need a lot of rewriting, I'm not planning that at this moment.

Toni,
See my Edit in previous post for new debdog-full-install.
Please test if you have time, and tell me if you disagree with something.

Fred

[bobc]

I'm sorry, I don't know the script language yet even well enough to read and understand things like the squash files. I'm just learning, so don't know what is easy vs what is difficult.

Actually, the iso is so small that if the person installing was instructed that if they plan to do a hard driven install, they should copy the iso file to the flashdrive after they burn it so they will have it available to be able to select it..

[fredx181]

I'm sorry, I don't know the script language yet even well enough to read and understand things like the squash files.

No need to say sorry
And thanks again for testing!

Fred

[saintless]

Hi, Fred.

I agree with the posted changes and all are good improvements for me.
I will need some time to test it on a machine with several different formatted partitions.

Toni

[fredx181]

Hi Toni,

I've been experimenting with replacement for the gsu line on top of terminal-only scripts.

It's much more complicated but this turned out the best IMO:
For flashplayerchoice for example:

Code: Select all

TITLE=flashplayerchoice

   if [ -z `which gsu` ]; then
   if [ "`whoami`" != "root" ]; then
   tty -s; if [ $? -ne 0 ]; then exec gksu xterm -T "$TITLE" -si -sb -fg white -bg SkyBlue4 -geometry 75x20 -e "$0" "$@"; exit; else exec sudo "$0" "$@"; exit; fi
   else
   tty -s; if [ $? -ne 0 ]; then exec xterm -T "$TITLE" -si -sb -fg white -bg SkyBlue4 -geometry 75x20 -e "$0" "$@"; exit; fi
   fi
   else
   if [ "`whoami`" != "root" ]; then
   tty -s; if [ $? -ne 0 ]; then exec gsu xterm -T "$TITLE" -si -sb -fg white -bg SkyBlue4 -geometry 75x20 -e "$0" "$@"; exit; else exec sudo "$0" "$@"; exit; fi
   else
   tty -s; if [ $? -ne 0 ]; then exec xterm -T "$TITLE" -si -sb -fg white -bg SkyBlue4 -geometry 75x20 -e "$0" "$@"; exit; fi
   fi
   fi 

From what I tested this works for root and normal user and includes gksu option also.
What I proposed a while back didn't work (had to do a hard shutdown because around 100 xterm windows appeared )
Also this way the .desktop file can be unchanged and the script in /opt/bin works fine when just clicking on it.
And when running in terminal as user it just asks for password as it does normally from terminal.

But maybe you have more simple solution in mind?

Edit: Not sure about things like compatibility but this works as well:

Code: Select all

[ "`whoami`" != "root" ] && exec gsu-xterm ${0} "$@"

Btw, I can't remember, do we have to add gksu option in all scripts that needs admin rights? Or maybe only in the scripts that are part of a .deb package.
I mean such as in frisbee:

Code: Select all

if [ -z `which gsu` ]; then
[ "`whoami`" != "root" ] && exec gksu ${0} "$@"
else
[ "`whoami`" != "root" ] && exec gsu ${0} "$@"
fi

Edit: and can you tell me which terminal-only-scripts we have? I may forget a few.

Fred

[saintless]

Hi, Fred.

I've been experimenting with replacement for the gsu line on top of terminal-only scripts.

It's much more complicated but this turned out the best IMO:
For flashplayerchoice for example:

Code: Select all

TITLE=flashplayerchoice

   if [ -z `which gsu` ]; then
   if [ "`whoami`" != "root" ]; then
   tty -s; if [ $? -ne 0 ]; then exec gksu xterm -T "$TITLE" -si -sb -fg white -bg SkyBlue4 -geometry 75x20 -e "$0" "$@"; exit; else exec sudo "$0" "$@"; exit; fi
   else
   tty -s; if [ $? -ne 0 ]; then exec xterm -T "$TITLE" -si -sb -fg white -bg SkyBlue4 -geometry 75x20 -e "$0" "$@"; exit; fi
   fi
   else
   if [ "`whoami`" != "root" ]; then
   tty -s; if [ $? -ne 0 ]; then exec gsu xterm -T "$TITLE" -si -sb -fg white -bg SkyBlue4 -geometry 75x20 -e "$0" "$@"; exit; else exec sudo "$0" "$@"; exit; fi
   else
   tty -s; if [ $? -ne 0 ]; then exec xterm -T "$TITLE" -si -sb -fg white -bg SkyBlue4 -geometry 75x20 -e "$0" "$@"; exit; fi
   fi
   fi 

From what I tested this works for root and normal user and includes gksu option also.

It seems very complicated in my opinion.

What I proposed a while back didn't work (had to do a hard shutdown because around 100 xterm windows appeared )

Can you give me an example? I don't have such problem in Jwm version changing xterm scripts to work with new gsu-notimeout.

But maybe you have more simple solution in mind?

Yes, using gsu-xterm as default gsu is much more safe and acceptable choice for me. Adding all this lines in each xterm depending script just because gsu-yad looks better... Why do we need all this troubles changing something already working fine?

Btw, I can't remember, do we have to add gksu option in all scripts that needs admin rights? Or maybe only in the scripts that are part of a .deb package.
I mean such as in frisbee:

For included already scripts only the scripts that are part of deb packge.
For new made scripts (debs or not) it is better to use this as standard from now:

Code: Select all

if [ -z `which gsu` ]; then
[ "`whoami`" != "root" ] && exec gksu ${0} "$@"
else
[ "`whoami`" != "root" ] && exec gsu ${0} "$@"
fi

and can you tell me which terminal-only-scripts we have? I may forget a few.

Attached archive with the scripts and menu files I made so far regarding changing gsu-xterm with gsu-notimeout. move-in-crypt has desktop file using "xterm -e" and makes terminal popup two times for user account. this is because the menu does not accept Terminal=true option which should work in Openbox version.
snap-make is included because it has gsu line moved up. It was appearing two times from user account.

Edit: The deb packages in temp repo have gsu-gksu line and we must reinstall them anyway because the dependencies are changed. Scripts that are not in the temp repo do not need adding gksu line.

Edit2: Fred, what ever solution works for openBox version is fine as long the xterm scrits work for user and root. I'm working on Squeeze and Wheezy version together and I do not like to change and start testing again the xterm scripts setup.

Toni

[fredx181]

Hi Toni,

It seems very complicated in my opinion.

Quote:
What I proposed a while back didn't work (had to do a hard shutdown because around 100 xterm windows appeared Smile )

Can you give me an example? I don't have such problem in Jwm version changing xterm scripts to work with new gsu-notimeout.

Quote:
But maybe you have more simple solution in mind?

Yes, using gsu-xterm as default gsu is much more safe and acceptable choice for me. Adding all this lines in each xterm depending script just because gsu-yad looks better... Why do we need all this troubles changing something already working fine?

It was not my intention to make it more complicated than needed, I just did a stupid thing when experimenting
At the top of flashplayerchoice I tried this:

Code: Select all

 if [ "`whoami`" != "root" ]; then
exec gsu xterm -e ${0} "$@"
   else
exec xterm -e ${0} "$@"
   fi

Thinking wrong that it was needed to add the 'else....' for in case the script is run as root.
So that created the endless display of new xterm windows. (don't try this at home )
That lead me in the wrong direction to further exploring for a working solution.
I see now that it works fine the simple way.

Code: Select all

 [ "`whoami`" != "root" ] && exec gsu xterm -e ${0} "$@"

Thanks for the archive! It's OK for me like that.
What's the difference for ffmpeg2sfs?, btw.

From your above comment it seems as you like better to include gsu-xterm in new release instead of gsu-yad.
Or is it only about the terminal-scripts?
Don't like the idea that somehow you feel like being forced to use yad-gsu.
We can also decide to have different gsu in Jwm or Openbox version. Should be Ok as long as it works the same way.
Edit: On further thought, maybe better not, it will give compatibility problems and so on.......

Fred

[saintless]

Hi, Fred.

Thanks for the archive! It's OK for me like that.
What's the difference for ffmpeg2sfs?, btw.

Thanks, then lets keep it this way since it works for you too.
ffmpeg - sorry, added by mistake in the archive. It is just the latest version from you. No gsu changes in ffpmeg2sfs.

From your above comment it seems as you like better to include gsu-xterm in new release instead of gsu-yad.
Or is it only about the terminal-scripts?
Don't like the idea that somehow you feel like being forced to use yad-gsu.

It is not like forcing me, Fred. The reason is we get much complications just from using by default gsu-yad. I know with sure we have someone using DD-Wheezy, someone using DD-Jessie, someone using DD-Sid version. Maybe more reading the post from Andres using DD on several computers.

Then you have the idea about DD packages repository. Great idea, but we should make the packages as good as possible and universal as possible preventing dpkg conflicts. This repository will be added in sources list in next DD version.
Now what happens if one of these 3 DD users with older version adds this repository and start installing packages? First auto-installed dependency will be gsu. If gsu-xterm is auto-replaced with yad-gsu atleast flashplayerchoice, change-frisbee2sns and move-in-crypt will not start from user account. Maybe we will find more scripts later.
We can prevent this by using:

Fix.1. Use /opt/bin/gsu (based on xterm with this code):

Code: Select all

if [ "`whoami`" != "root" ]; then 
xterm -T "RemasterCow" -si -sb -fg white -bg SkyBlue4 -geometry 65x14 -e sudo "$@" 
else 
"$@" 
fi 

Done. We have compatibility with ald DD versions and all scripts in OpenBox and Jwm version will work without any changes.

Fix 2. Or we can use gsu-yad (because it looks nicer). OK, but not yet.
Problem 1. Some scripts based on xterm do not work with yad-gsu.
Solution 1. Changing the gsu line in the script and inside the desktop file (depending how the script will work). Done.
Problem 2. gsu-yad does not ask for password running second time the same program (as gsu-xterm does it).
Solution 2. Make gsu-timeot and gsu-notimeout scripts. Done.
Problem 3. New gsu.deb will not work in older DD version for xterm-scripts.
Solution 3. Include in the deb all 3 gsu and make it search for DD new version and change gsu-xterm by default for old DD versions. Done.

All is fine and we have nicer looking gsu for new DD and the safe gsu-xterm choice for older DD and standard Debian.

Fix 1. is stupid simple and safe and 100 working for all DD versions + standard Debian.

Fix 2. is much more complicated and all this work just to have nice looking gsu-yad. But now we have it solved and we get the best for new version keeping compatibility with old version.

Then you suggets to fix Problem 1. different way by adding 18 lines of code on top of each xterm-depending script.
This means I will need to start again testing the new solution for Wheezy and Squeeze for possible problems after it is alreday fixed by changing the gsu line in some and desktop file content in others.
It seems too much work for no good reason to me, Fred. If I have to start testing again this xterm-scripts and gsu-yad problem I can't resist to look at Fix 1. and ask why we need all this complications at first place instead using gsu-xterm.

In next DD version lets use as we plan Fix 2. (new gsu deb with gsu-notimeot as default in new DD).

I see nothing wrong if you use different solution for xterm-scripts if you prefer this new code added in OpenBox. It is only in the scripts for new DD version.
The new gsu.deb package is the compatibility solution for old DD versions.
But the default /opt/bin/gsu is best to be the same for both versions in my opinion.

Toni

[saintless]

Hi, Fred.

Two more scripts depending on xterm found. I think they are not included in OpenBox version and the change is needed only for Jwm.
/opt/bin/automount-start and automount-stop

One problem with obshutdown found. Similar to yad--splash and gtkdialog-splash problem. I get sometimes /tmp/obshutdown.lock in use message as puppy user and logout menu does not work untill I do:

Code: Select all

sudo rm -f /tmp/obshutdown*

I think it is because the /tmp file is owned by root or still in use by root. I will test it more to confirm. Edit: added screenshot. It is not root permissions problem because the attached screenshot is from root account. I can easy reproduce it with click on Logout and then Ctrl+Alt+Backspace to exit X. But I think /tmp/obshutdown.lock stays active also in other situations for some reason preventing root or user to use Logout menu. It could be the 'killall jwm icewm" or "pkill X" line in .obshutdown.rc in Jwm version that makes obshutdown not to remove the temp file. I don't know if it could be prevented somehow but we can add script in /opt/bin to remove /tmp/obshutdown.lock when needed by manually running the script.

Edit: One more problem:
/opt/bin/portablesfs does not work from user account in both versions when executing name-portable script. Seems like /opt/lib path is not found but I'm not sure this is the only problem yet. Works fine from root account. Messages from terminal as user:

Code: Select all

puppy@debian:~$ /mnt/home/FTP-Last/DebianDog/Extra-modules/abiword-portable
SUCCESS: Module '023-abiword-2.8.2-docx.squashfs' activated
ACTION: updating mimeinfo cache
abiword: error while loading shared libraries: libxslt.so.1: cannot open shared object file: No such file or directory
SUCCESS: Module '023-abiword-2.8.2-docx.squashfs' deactivated
ACTION: updating mimeinfo cache

============================

puppy@dog:/$ /live/image/FTP-Last/DebianDog/Extra-modules/abiword-portable
mount: warning: /mnt/live/memory/images/023-abiword-2.8.2-docx.squashfs seems to be mounted read-only.
SUCCESS: Module '023-abiword-2.8.2-docx.squashfs' activated
ACTION: updating mimeinfo cache
abiword: error while loading shared libraries: libxslt.so.1: cannot open shared object file: No such file or directory
SUCCESS: Module '023-abiword-2.8.2-docx.squashfs' deactivated
ACTION: updating mimeinfo cache

Edit 2: debdog-full installer seems to work well for me. I will try to test it more in the next days.

Edit 3: Fred, alternative gsu_1.0.0_i386.deb made from gksu may need adding ldconfig in postinst script because of /usr/local/lib files. It may not work in standard Debian without ldconfig I think. Also installed on older DD version I think it will break xterm depending scripts because does not include and set by default gsu-xterm for older DD. Do you like to keep it as it is?

Edit 4: /opt/bin/mnt-all needs adding "$@" in gsu line or umount (mnt-all -u) does not work from user account:

Code: Select all

[ "`whoami`" != "root" ] && exec gsu ${0} "$@"

Toni

[fredx181]

Hi Toni,

.....
.....
It seems too much work for no good reason to me, Fred. If I have to start testing again this xterm-scripts and gsu-yad problem I can't resist to look at Fix 1. and ask why we need all this complications at first place instead using gsu-xterm.

I didn't realize you made fixes already with simple solution and, again, the proposal of the 18 lines was just because of a mistake (couldn't find simple working solution)

In next DD version lets use as we plan Fix 2. (new gsu deb with gsu-notimeot as default in new DD).

Ok, hopefully there aren't any issues anymore, if there are we can always go back to fix 1.

Edit 3: Fred, alternative gsu_1.0.0_i386.deb made from gksu may need adding ldconfig in postinst script because of /usr/local/lib files. It may not work in standard Debian without ldconfig I think. Also installed on older DD version I think it will break xterm depending scripts because does not include and set by default gsu-xterm for older DD. Do you like to keep it as it is?

No, do you mind adding what is required?

One problem with obshutdown found. Similar to yad--splash and gtkdialog-splash problem. I get sometimes /tmp/obshutdown.lock in use message as puppy user and logout menu does not work untill I do:
Code:
sudo rm -f /tmp/obshutdown*

I don't think it's permissions problem (well at least not only)
The only way I could reproduce on Jwm version:
- Click from menu on logout, obshutdown dialog displays, don't do anything with it.
- Click on JWM menu button, then for me everything freezes, only way out is Ctrl+Alt+Backspace

Then when logged back in again there's the /tmp/obshutdown.lock exist message.
If this is the same for you maybe it's best to use other way for shutdown instead of obshutdown.
On openbox version there's no problem, btw

Edit: One more problem:
/opt/bin/portablesfs does not work from user account in both versions when executing name-portable script. Seems like /opt/lib path is not found but I'm not sure this is the only problem yet. Works fine from root account. Messages from terminal as user:

I will look at it , btw in case of abiword: libxslt.so.1 I don't see in /opt/lib or /usr/local/lib

Fred

[saintless]

Hi, Fred.

No, do you mind adding what is required?

OK, I will make it like the other gsu deb.

I don't think it's permissions problem (well at least not only)
The only way I could reproduce on Jwm version:
- Click from menu on logout, obshutdown dialog displays, don't do anything with it.
- Click on JWM menu button, then for me everything freezes, only way out is Ctrl+Alt+Backspace

Then when logged back in again there's the /tmp/obshutdown.lock exist message.
If this is the same for you maybe it's best to use other way for shutdown instead of obshutdown.

Yes, just tested and it does the same in Jwm version. I will find some replacement or fix for it.

I will look at it , btw in case of abiword: libxslt.so.1 I don't see in /opt/lib or /usr/local/lib

libxslt.so.1.1.26 and libxslt.so.1 are in /opt/lib in the abiword module:
http://smokey01.com/saintless/DebianDog ... x.squashfs
From user account using sfs-load same module abiword starts the program.
From user account the script from portablesfs can't find the libs in /opt/lib
From root account all works - load-sfs and starting the script made with potablesfs.
It is the same with the other 2 abiword modules and gnumeric here:
http://smokey01.com/saintless/DebianDog/Extra-modules/
All can't find the included in /opt/lib libs from user account using modulename-portable script.

Toni

[fredx181]

Hi Toni,

It is the same with the other 2 abiword modules and gnumeric here:
http://smokey01.com/saintless/DebianDog/Extra-modules/
All can't find the included in /opt/lib libs from user account using modulename-portable script.

Yes, same on OpenBox version.
It seems that it has to do with the fact that a script is not in PATH
You can test by running any script from outside PATH as user (using sudo) with this line inside:

Code: Select all

echo librarypath=$LD_LIBRARY_PATH
librarypath=

It's empty.

Can't figure out why yet, I'll search for it tomorrow.

Fred