2.13 Beta bugs
Ok, I 've had a chance to test 2.13beta a little more and have found the following unreported bugs (running with pfix=RAM):
1. Installing Puppy to 'USB Flash drive' using Puppy Univ. Installer. Using 'sda1: vfat, size 122.4 MiB'. I chose 'sys-nopart.mbr' like usual. Then I get to the menu where I chose 'Syslinux', also like usual, click 'OK' and the next thing that happens is the CD drawer opens (with the 2.13beta CD)! Nothing is written to the flash drive. I've tried this with two different drives that have worked before.
2. Menu -> Control Panel -> Top doesn't work - nothing happens. Executing 'top' in a terminal works fine.
3. Menu -> Internet -> Axel opens menu to insert URL. Add URL then click 'OK' - Axel disappears. Check with KP - no such process. Axel works fine from CLI.
4. Clicking in ROX on a .log file doesn't have a run action. Used to open the file in the default editor.
Paul
1. Installing Puppy to 'USB Flash drive' using Puppy Univ. Installer. Using 'sda1: vfat, size 122.4 MiB'. I chose 'sys-nopart.mbr' like usual. Then I get to the menu where I chose 'Syslinux', also like usual, click 'OK' and the next thing that happens is the CD drawer opens (with the 2.13beta CD)! Nothing is written to the flash drive. I've tried this with two different drives that have worked before.
2. Menu -> Control Panel -> Top doesn't work - nothing happens. Executing 'top' in a terminal works fine.
3. Menu -> Internet -> Axel opens menu to insert URL. Add URL then click 'OK' - Axel disappears. Check with KP - no such process. Axel works fine from CLI.
4. Clicking in ROX on a .log file doesn't have a run action. Used to open the file in the default editor.
Paul
Methinks Raspberry Pi were ideal for runnin' Puppy Linux
Thanks Kal. Yes, that works.Kal wrote: <Program label="Top view running processes" icon="mini-run.xpm">mrxvt -e top</Program>
I discovered that rxvt (which is now a wrapper for mrxvt) balks at the '-n' switch in the line
The line works when I remove it.rxvt -font 7x14 -bg "#c0c0c0" -fg black -T Top -n Top -e top
Methinks Raspberry Pi were ideal for runnin' Puppy Linux
More feedback on the problem with axel. Running the line from .jwmrc in mrxvt, this is what I get:
Paul
Also an inconsistency between rxvt and mrxvt it seems.# puppydownload http://distro.ibiblio.org/pub/linux/dis ... .54.tar.gz
http://distro.ibiblio.org/pub/linux/dis ... .54.tar.gz
/root/: directory
mrxvt: bad option "Axel"
mrxvt: bad option "download"
mrxvt: bad option "accelerator"
mrxvt: Use -h, -help or --help to get help
#
Paul
Methinks Raspberry Pi were ideal for runnin' Puppy Linux
More feedback on the Puppy Univ. Installer bug:
Seems like another rxvt/mrxvt problem. See 'puppyinstaller' line 137:
Paul
Seems like another rxvt/mrxvt problem. See 'puppyinstaller' line 137:
Just running part of that line in mrxvt shows:rxvt -bg "pink" -title "Puppy Universal Installer" -geometry 80x25 -e /tmp/fixusb.sh
Conclusion so far: if Barry is going to use Urxvt instead of Mrxvt, please make sure the switches are compatible with Rxvt or many scripts will be broken# rxvt -bg "pink" -title "Puppy Universal Installer" -geometry 80x25
mrxvt: bad option "Universal"
mrxvt: bad option "Installer"
mrxvt: Use -h, -help or --help to get help
#
Paul
Methinks Raspberry Pi were ideal for runnin' Puppy Linux
See three posts upsml wrote:Has anyone tested the puppy universal installer? I have tried with 2.12 and 2.13 and it seems broken. Sometimes it ejects the puppy CD, sometimes just before creating the USB bootable disc, the application just closes.
Methinks Raspberry Pi were ideal for runnin' Puppy Linux
In Muppy, I replaced rxvt with a wrapper to run xterm.
It should take care of the issue Pakt mentions:
/usr/bin/rxvt
You must put "your" rxvt-binary in the last comand.
Mark
It should take care of the issue Pakt mentions:
/usr/bin/rxvt
Code: Select all
#!/usr/bin/puppybasic
i=3
args=""
while command(i) !=""
a=command(i)
if instr(a," ") then
a="\"" & a & "\""
end if
args &= a & " "
i+=1
wend
args=trim(args)
'print args
args = replace(args, "--geometry" , "-geometry" )
'print args
shell("exec /usr/bin/rxvt-xterm/rxvt " & args)
Mark
- Lobster
- Official Crustacean
- Posts: 15522
- Joined: Wed 04 May 2005, 06:06
- Location: Paradox Realm
- Contact:
A lot of people like MUT. As long as it is there on the menu, they are accommodated. IMHO we have to use as default what works and is known to work. In the case of the Rox update, it makes sense to change to Pmount as default desktop icon. I never use pmount because MUT is the default and has worked for me (up to now).BarryK wrote:Hmm, I wonder if we should change the "drives" icon on the desktop to use Pmount, as MUT is not really being maintained.
In Pmount, a ROX window open on a partition that is to be unmounted is first closed before the unmount.
-
- Posts: 53
- Joined: Mon 20 Nov 2006, 08:26
- Contact:
freezing ROX in /proc and icon& background dissapear
about ROX 2.5 bug: freeze on /proc, with thumbnails on, after some research it appears to me it is not an ROX bug! in /proc directory only "kmsg" file cannot be open (no cat,more...) and cannot be copy part of it with "dd if=/proc/kmsg... so it is obvious it cannot be accessed (opened) in a normal way. There was a discussion in forum how is recognized the file type in windows (after the name of file extension ) and in linux (after rhe first bytes in file ,an sort of magic number, use of 'file' command ) and the old ROX used the windows style after the file extension name .
It seems that new ROX 2.5 is upgrade to recognize the file type in linux manner by opening and reading the beginning of file , and because '/proc/kmsg' cannot be opened it is waiting (like dd if=/proc/kmsg..)in an endless loop which freeze ROX....So until now evrything is ok with ROX (not with /proc/kmsg), there is another little bug in it (no related with kmsg): if you try to 'kill' ANY rox windows (from right klick on menubar) it will kill also the background ROX the pinboard with descktop background image and descktop icons too...
Somebody should verify my theory...who knew ROX how works internally....
"cat /proc/kmsg" and "dd if=/proc/kmsg..." are stucked but "file /proc/kmsg" reports "/proc/kmsg: empty" interesting!
about MUT/Pmount both are ok, am used with MUT you can manually unmount SWAP too...
It seems that new ROX 2.5 is upgrade to recognize the file type in linux manner by opening and reading the beginning of file , and because '/proc/kmsg' cannot be opened it is waiting (like dd if=/proc/kmsg..)in an endless loop which freeze ROX....So until now evrything is ok with ROX (not with /proc/kmsg), there is another little bug in it (no related with kmsg): if you try to 'kill' ANY rox windows (from right klick on menubar) it will kill also the background ROX the pinboard with descktop background image and descktop icons too...
Somebody should verify my theory...who knew ROX how works internally....
"cat /proc/kmsg" and "dd if=/proc/kmsg..." are stucked but "file /proc/kmsg" reports "/proc/kmsg: empty" interesting!
about MUT/Pmount both are ok, am used with MUT you can manually unmount SWAP too...
I've been using pmount lately instead of MUT and I agree, it's the 'open with ROX' button I miss.
I also find myself having to think twice whether 'red' or 'green' means 'mount' or 'unmount' (I realize that when a drive is mounted, details show up to the left).
However, MUT's use of 'mount' and 'unmount' can't be much clearer.
Paul
EDIT: I'm no graphics artist, but how about modifying the icons something like this
I also find myself having to think twice whether 'red' or 'green' means 'mount' or 'unmount' (I realize that when a drive is mounted, details show up to the left).
However, MUT's use of 'mount' and 'unmount' can't be much clearer.
Paul
EDIT: I'm no graphics artist, but how about modifying the icons something like this
- Attachments
-
- pmount_icons.jpg
- (15.18 KiB) Downloaded 1064 times
Last edited by pakt on Thu 28 Dec 2006, 10:29, edited 1 time in total.
Methinks Raspberry Pi were ideal for runnin' Puppy Linux
- debernardis
- Posts: 180
- Joined: Sat 12 Nov 2005, 08:01
- Contact:
bump
/me is the only one with lock screen not functioning on 2.13 beta?
Re: bump
Yes, there is a problem with 'lock' in 2.13beta, but it will only show up if you don't already have /root/.xlockrcdebernardis wrote: /me is the only one with lock screen not functioning on 2.13 beta?
If /root/.xlockrc is missing, the usual (for 2.13beta) problem of mrxvt vs. rxvt problem surfaces.
This is what happens in the lock script if I execute part of the offending line in mrxvt
It's a good thing Barry is putting the rxvt binary back in# rxvt -bg orange -g 36x1 -title "Create key (password)"
mrxvt: bad option "key"
mrxvt: bad option "(password)"
mrxvt: Use -h, -help or --help to get help
#
Paul
Methinks Raspberry Pi were ideal for runnin' Puppy Linux
Crash booting
I have a P4 3GHz hyper threaded system. It has the onboard shared memory graphics adapter and I also have an ATI Catalyst on the PCI bus. If I boot with the ATI selected as the primary graphics adapter 2.13 crashes. If I switch back and set the embedded controller as default it boots, but I get the problem iof X not running and can't even get XVesa to run.