Pup214R v1.00 - Puppy Linux 2.14 Revisited, is now available

[Dougal]

Do we actually need both:

Menu > setup > setup wizards > etc

and

Menu > setup> wizard wizard > etc

since the end result is essentially the same?

I don't understand what you mean... Do you mean having the wizards sub-menu and the WizardWizard?

[ttuuxxx]

Hi i just tried it and i think its excellent, Great job guys, Only problem so far that i've had is when i did a screenshot using mtpaint, I had like 20+mtpaint windows open automtically, i had ezpup3.0 running at the time and that was it, also when you use ezpup 2.17r4 or 3.0 the menus are broken, you only have 2 items in the start menu. And yes i did the fixmenus thing and got some missing folders, other then that i really do like this puppy sorry about the image quality but i used mtpaint to get that and tried to make it smaller with it and it became pretty crappy ttuuxxx

[gerry]

Hi Dougal... yes.

Gerry

[rerwin]

Dougal,
Thanks for clarifying the significance of the "modes:" and "timing:" statements:

The "timing" lines list the modes supported by the screen and in the case of laptops it usually will be only the one, native, mode.
The part of ddcprobe output related to your adapter is the first part of ddcprobe output (that's why when you get only half the output and "edidfail" it means that it couldn't get to your screen).
What I did is make sure that Xmodes (which is normally created by Xvesa -listmodes) has got the 800x600 and 1024x768 modes, thus the user will be offered them, being told "ok with card, maybe NOT ok with screen".

So my Tecra gets described correctly by your fix. However, without a 800x600 timing line, cherriepuppy's 800x600 Portege with the same adapter will not be given the 800x600 option. To condense his posts re my 1024x768 fix:

works on toshiba portege 7010ct except it says that 1024x768 resolution is available but the screen only goes up to 800x600.

ddcprobe shows following:
# ddcprobe
vbe: VESA 2.0 detected.
oem: MagicGraph 256 AV 44K PRELIMINARY
. . .
edid:
edid: 1 0
id: 5081
eisa: TOS5081
serial: 00000000
manufacture: 20 1995
input: analog signal.
screensize: 23 17
gamma: 1.000000
dpms: RGB, no active off, no suspend, no standby
timing: 720x400@70 Hz (VGA 640x400, IBM)
timing: 640x480@75 Hz (VESA)
#

The absense of a "timing: 800x..." line would prevent the wizard from offering the actual native resolution of that Portege. I expect that laptops considered for Puppy would support at least 800x600. So, the logic to add this line could be conditioned upon there being no higher-resolution "timing:" line.

My problem with what I call the "fill in the gaps" approach is that it must get it right for all affected adapters and screens, an open-ended maintenance issue. The solution I settled on simply takes the default used in the absense of (sufficient) screen information; that is the case here, although with 1024x768 screens, accepting the "8514A" 1024x768 line supplies the correct option. (With the "default" approach, we would not be discussing details of the FITG fix for 10-year-old laptops, conserving energy for the greater-impact stuff.)

BTW, dalderton's Toshiba TE 2000 produces:

oem: Trident CYBER 8820
. . .
timing: 720*400@70Hz (VGA 640*400, IBM)
timing: 640*480@70Hz (VESA)
timing: 800*600@72Hz (VESA)
timing:1024*768@87Hz Interlaced (8514a)
ctiming: 1280*1024@60
ctiming: 1600*1200@60
dtiming: 1024*768@74

telling me that it supports resolutions lower than native. But, for Puppy, I see no need to supply the lower resolutions if ddcprobe omits them.
Richard

[ttuuxxx]

so basically if its really nice, we can't jazzz it up a bit???

[ttuuxxx]

The icons on the desktop was a setting for rox in options, Strange option and really never would I ever find a use for such a option. So that one wasn't 2.14r fault at all, I also found that if you used ultimate icewm the computer would slow down a lot, and that package was made for the 2 series, so then i had 128icewm package laying around and tried that one, And finally yes it work perfectly, other then renaming the start menu buttons but thats ok. excellent work and yes ezpup wasn't made for the 2 series. The xarchiver sometimes gets errors when extracting so i installed xarchive-0.2.8-6.pet and then it worked flawlessly.
ttuuxxx

[ttuuxxx]

ok i have disabled "hotplug" and it has stopped that desktop icon thing. So its either the package fault or hotplug, But just take into account the package has always worked perfect on 3.0 & 3.01.Haven't tried it on other puppy versions sorry:)

[Dougal]

i had ezpup3.0 running at the time and that was it, also when you use ezpup 2.17r4 or 3.0 the menus are broken,

Any problems caused by ezpup should be directed to the ezpup developers.
Besides that, it is likely that packages intended for later versions of Puppy might not work properly.

[Dougal]

Hi Dougal... yes.

Gerry

Well, Barry has both the WizardWizard and all the wizards in the same menu... I just put the separate wizards into a submenu to make it more neat, but if I decide to remove either of the two, some people will obviously think I should have removed the other one... I never use the WizardWizard, but there are others that probably do.

[Dougal]

when i opened any program, It would give a open tab in the taskbar as usual but here's the thing it would put a desktop icon as long as it was open, once i closed the program the icon would disappear.

Those are iconified windows. You can enable/disable using them in the rox settings.

[Dougal]

Rerwin, I'll look into it.

[wjaguar]

sorry about the image quality but i used mtpaint to get that and tried to make it smaller with it and it became pretty crappy ttuuxxx

You shouldn't have converted the screenshot to GIF - for an image like this, PNG would have been both considerably smaller and of much better quality. Converting an RGB image to indexed is lossy in general, and mtPaint's default dithering mode is the fastest one, not the best quality one.

[willhunt]

just lov'n it

[ttuuxxx]

just lov'n it

That looks excellent!!, how did you change the rox buttons, I looked all over for the forward, up, etc rox buttons. Thanks

[willhunt]

Gnome file browser not rox from the gnome.sfs file here
on the forum all the sfs from the VIZ series seem to work
fine in 2.14R

[prehistoric]

@Dougal

First, an apology for not testing and reporting the results of your pet to fix the grub menu.lst problem on frugal installs. My test machine was disassembled until yesterday. You were correct in your assumption, the problem showed up in a case where grub had not previously been installed. I reformatted the disk and tested in the same configuration that failed before.

The files are all copied to /boot/puppy214R, (I normally put the puppy directory up in / where it is more visible,) but menu.lst won't boot because of several errors. (The error code is from memory. I don't guarantee the errors are letter for letter what I found.)

Code: Select all

title Puppy Linux 214R, frugal (on hda1)
rootnoverify (hd0,0)
kernel /boot/grub/vmlinuz root=/dev/hda1 root=/dev/ram0 PMEDIA=idehd 
initrd /tmp/boot/boot/puppy214R/initrd.gz

Note the two roots on the kernel line and the strange location of initrd.gz. Boot failed by not finding vmlinuz.

This was manually edited to a working configuration.

Code: Select all

title Puppy Linux 214R, frugal (on hda1)
rootnoverify (hd0,0)
kernel /boot/puppy214R/vmlinuz root=/dev/ram0 PMEDIA=idehd psubdir=/boot/puppy214R
initrd /boot/puppy214R/initrd.gz

My own preference is to make psubdir=/puppy214R. This stays the same, regardless of whether or not any other Linux is installed on that partition, and is easy to find. If the partition is used as /home by another system, a boot directory is confusing.

Again, my apologies for not testing sooner. Your fast response to the problem simply got overlooked. If I was younger I would be in that code messing around. You're probably lucky I am not.

prehistoric

[Dougal]

The files are all copied to /boot/puppy214R, (I normally put the puppy directory up in / where it is more visible,)

Are you sure all of them are in the subdir? The installer is supposed to only put the kernel and initrd in there -- the sfs files should go at the top level of the partition you chose to install Puppy to.

My own preference is to make psubdir=/puppy214R. This stays the same, regardless of whether or not any other Linux is installed on that partition, and is easy to find. If the partition is used as /home by another system, a boot directory is confusing.

The idea of the boot directory is that it's on the boot partition and that's where all boot-related files go -- so if you have a few versions installed, all the kernels and initrd's go in there.

[ttuuxxx]

One thing I noticed when using puppy2.14r and .sfs files is that you can't just click on them to mount and view them, unlike the puppy 3.0 series, you click and look inside, In puppy 3.0+ they mount with a single click and disable the same way, very handy when your build your own custom version. Or just want a file etc.
thanks for your time ttuuxxx

[Dougal]

One thing I noticed when using puppy2.14r and .sfs files is that you can't just click on them to mount and view them, unlike the puppy 3.0 series, you click and look inside, In puppy 3.0+ they mount with a single click and disable the same way, very handy when your build your own custom version.

That's intensional, as I don't believe laymen should have sfs files auto-mounted (I just press Ctrl+! and then type "mount -o loop file.sfs /mnt/data").

[prehistoric]

@Dougal

The idea of putting everything in one Puppy folder is my own, it helps keep down confusion about which system uses which files, particularly if you have multiple versions of Puppy. I need to go back and check on exactly what the frugal install did by default. This time I'll get exact copies for you.

On my Gentoo system /boot is a separate 130 MB partition, which is only mounted when I want to change kernels or booting. This has plenty of space for booting systems built under Gentoo, but I have enough confusion about which kernel I'm testing under Gentoo, I don't want foreign kernels in there, and I don't want to wipe out Puppy with a change to a Gentoo script under test. (The Gentoo machine is down at the moment. I just brought two machines back up, so having one down is par for the course.)

Damn Small Linux is another example of Linux with frugal installs, which can coexist in partitions with other systems. Several other systems now use squashfs files. (Just checked TinyFlux 1.0, which at least uses a different extension.) Placing these directly at the root of the directory tree has already caused me trouble with Puppy variants. Since we need a Puppy directory for kernels, initrd and sfs files I feel there should be a single directory with all, a personal preference.

Several local people who have tried Puppy have called me with questions. I've learned to find out if they have previously tried several versions. Getting one file from one version and another from a derivative is a recipe for chaos and madness.

Incidentally, I agree with what you told ttuuuxx about mounting sfs files. People who don't have a clue really can get in a mess. Trying to find out what happened afterwards, when they didn't know to begin with, is a lost cause.

Please don't take any reports of bugs as personal criticism. There are good reasons for my reporting a problem with the grub install script rather than trying to fix it myself. I'm not up to speed on Puppy, and at the rate it moves I may never catch up.

Thanks for a useful and interesting puplet. Keep up the good work!

prehistoric