(old)Puppy Linux Discussion Forum

All versions of -R are running without a hitch on my Core 2 Duo Fujitsu S6520 laptop.

I just fired up one of the Pentium M 725 ipw2200 laptops (Fujitsu S62xx series) to test a new version of PWF since it is the queen of dropouts. While it was up I worked on updating the OS on it.

The last version of LxPupSc I had run on it was 16.04.1. It booted and ran cleanly as did the newest LxPupXenial. I sucessfully checked the new PWF using OS from X-slacko 3.1n up through these and then proceded to the -Rs.

None of the LxPupSc-R versions I have will boot on it. Exactly the same Grub4Dos forcePAE setup used on the non -R versions and on LxPupXenial and the older X- pups. The versions I have tried are as follows:

16.06.3 Fails with Invalid or unsupported executable format at very beginning of boot process.

16.06.303 Fails exactly as above

16.07.1 Starts to boot, fails with "mounting /dev/loop4 on pup_z failed: Invalid argument"

All files are pulled from the same md5sum checked isos used to boot sucessfully on the Core 2 Duo.

The boot partition has been checked and LxPupXenial, X-slacko 4.1, X-slacko 3.1n, X-Tahr 1b3 all continue to boot ok from this partition. Behavior is exactly the same whether pristine or savefile update booting. Checked a couple of times on each -R version.

Later today, I'll fold the f_drv back into the z_drv for 16.07.1 and try booting with a conventional init. Pretty sure that the init script is the only variable here.

The fdrv was causing trouble (or still is). Finding bugs is a dificult task when it comes to the initrd init script

marv... can you take a pic to the screen when that error occurs? Just want to see if it triggers a "critical error" message i added a few days ago..

we also need more people keeping an eye on the changes in the commits to spot bugs as soon as they're introduced/fixed, so we can speed up devolopment

jlst.. I'll try to get a pic.

I did fold the f-drv back into the z_drv and use a non-R init script in initrd.gz. It booted fine.

Edit to add:

It also boots correctly using your 'rationalized' initrd.gz but with the f_drv folded back into the z-drv (no f_drv).

Interesting that the f_drv error doesn't occur at all on the considerably faster Core 2 Duo but does on the Pentium M 725 with identical setups and files. A timing thing??

Mick,
16.07.1 iso downloaded from this forum link was installed on usb,
same as before with 16.06.3 which all worked ok.

Now, I think there's a bug since the last release.

At shut-down, the 512Mb savefile selected isn't actually created.
It goes through all the motions as normal, but after clicking that the
listed parameters are correct, the shut down process then occurs
BEFORE the savefile is created, so changes aren't saved.
I ran this through twice to confirm, but same happened again.
Has anyone else found this?

Regards.

Rodney Byne wrote:Mick,
Now, I think there's a bug since the last release.
Regards.

I did introduce a bug that has to with the shutdown dialog, it basically causes pupdialog to misbehave when there is a timer, already fixed in git... but i'm not sure if it's the same bug... let's wait until peebee builds a new iso.

Marv wrote:jlst.. I'll try to get a pic.

It also boots correctly using your 'rationalized' initrd.gz but with the f_drv folded back into the z-drv (no f_drv).

Interesting that the f_drv error doesn't occur at all on the considerably faster Core 2 Duo but does on the Pentium M 725 with identical setups and files. A timing thing??

Probably, i'll look into this..

@Marv

• Your Core2Duo is a desktop while your PentiumM is a laptop. Is that correct?

@Gyro/@Jlst

• Are @Shinobar's init PAE steps accounted for?

.

@gcmartin,
All the Pentium M and the Core 2 Duo machines I have are laptops, Fujitsu S62xxs and Fujitsu S65xxs respectively. My desktops are fanless Intel Bay Trail based motherboards. Everything runs either on CF cards in adapters or SSDs and all are puppy OS.

Hi,
I think it was peebee earlier, suggested re-naming distro
LxPupSc in view of the enhanced/improved nature of
slackware amalgamated with Lx.

How about Slacko-Lx?

Regards.

I did a manual frugal install to a usb-3.0 SSD, pc is a hp desktop.

On first boot it got to the desktop but the highest resolution was
1280x1024.
I compared /lib/firmware/radeon with the same in Slacko64-632 and there
was much more firmware in the Slacko64 radeon firmware folder.
I copied the Slacko64 folder to the LxPupsc folder and rebooted.

video-info-glx 1.5.3 Mon 4 Jul 2016 on LxPup-Sc 16.07.1 Linux 4.6.3-lxpup-32-pae i686
0.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Redwood PRO [Radeon HD 5550/5570/5630/6510/6610/7570]

X Server: Xorg Driver: radeon
X.Org version: 1.18.3
dimensions: 1920x1080 pixels (507x285 millimeters)
depth of root window: 24 planes

direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD REDWOOD (DRM 2.43.0, LLVM 3.8.0)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.2.2

AMD Phenom(tm) II X6 1045T Processor
Core 0: @800 1: @800 2: @800 3: @2700 4: @2000 5: @800 MHz

So the proper firmware for my graphics card was missing.

EDIT: I installed applications with PPM + compiled + pets.

UPDATED 10-jul-2016

Interim delta 16.07.1 to 16.07.2:

BUILD_FROM_WOOF='rationalise;7b1495e;2016-07-08 00:22:19 +0000'

1f075948099b8523901f64bf4b6e363a LxPupSc-16.07.2.iso

@Billtoo - the firmware should be identical to previous versions - just packaged differently in the fdrv.....??

peebee wrote:
@Billtoo - the firmware should be identical to previous versions - just packaged differently in the fdrv.....??

I don't think I've run LxPupSc on this pc before, it didn't get the graphics right so I guess it didn't see the radeon firmware for my card if it was available in fdrv.

Shouldn't it find/use the proper firmware on first boot?

Billtoo wrote:

peebee wrote:
@Billtoo - the firmware should be identical to previous versions - just packaged differently in the fdrv.....??

I don't think I've run LxPupSc on this pc before, it didn't get the graphics right so I guess it didn't see the radeon firmware for my card if it was available in fdrv.

Shouldn't it find/use the proper firmware on first boot?

Under 16.07.1 I was having real problems with the f_drv load, particularly on my Pentium M boxes. Maybe the firmware there wasn't loaded. There were also problems with shutdown/save file creation and use. Both issues seem to have been resolved (both on the Pentium M and the Core 2 Duo) in 16.07.2 at least in my early tests. Give it a try.

Marv wrote:
Under 16.07.1 I was having real problems with the f_drv load, particularly on my Pentium M boxes. Maybe the firmware there wasn't loaded. There were also problems with shutdown/save file creation and use. Both issues seem to have been resolved (both on the Pentium M and the Core 2 Duo) in 16.07.2 at least in my early tests. Give it a try.

Hi,

I just did a manual frugal install and rebooted creating the save file:

video-info-glx 1.5.3 Mon 4 Jul 2016 on LxPup-Sc 16.07.2 Linux 4.6.3-lxpup-32-pae i686
0.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Redwood PRO [Radeon HD 5550/5570/5630/6510/6610/7570]

X Server: Xorg Driver: vesa
X.Org version: 1.18.3
dimensions: 1280x1024 pixels (524x292 millimeters)
depth of root window: 24 planes

direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.8, 128 bits)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.2.2

AMD Phenom(tm) II X6 1045T Processor
Core 0: @2700 1: @800 2: @800 3: @800 4: @800 5: @2000 MHz

No change from 16.07.1
If I drop to the prompt and run xorgwizard the only option is vesa.

The screenshot shows the radeon folder in /lib/firmware there is no firmware for my card showing.

Billtoo wrote: If I drop to the prompt and run xorgwizard the only option is vesa.

The screenshot shows the radeon folder in /lib/firmware there is no firmware for my card showing.

The firmware issue can be resolved by including more radeon firmware... from slacko64

xorgwizard-cli is no more, at least the old xorgwizard-cli, the new one is for exceptional cases.

I'm editing quicksetup, meanwhile, do this:

Menu -> Setup -> Xorg Video Wizard -> Change Screen Resolution (xorg.conf) -> 1920x1080 -> ok (prompt to restart X)

But... lxpup does not seem to have Xorg Video Wizard under Setup...

so you can run in terminal: xorgwizard -> Change Screen Resolution (xorg.conf) -> 1920x1080 -> ok (prompt to restart X)

But... i see that it does not restart X.. i'm fixing this.

So Billtoo, let's wait until peebee builds a new iso with the all the fixes for your situation... probably tomorrow.

jlst wrote:But... lxpup does not seem to have Xorg Video Wizard under Setup...

I had hidden it due to the problems with the old version - I'll reinstate it for the next delta.
Thanks
peebee

I want to keep LxPup in the name...

so I'm thinking either

LxPup-S+

or LxPup-Ng (for new or next generation)

Updated my install using the latest (July 5) delta. Anything in particular I should look at? 16.07.2 is running well on both my iwlwifi Core 2 Duo and my ipw2200 Pentium laptop. Light continues to serve well as the fallback browser from my Opera 12.16 for any embedded photo or youtube material.

Manual frugal install to a usb-3.0 hard drive, pc is a macmini.

video-info-glx 1.5.3 Wed 6 Jul 2016 on LxPup-Sc 16.07.2 Linux 4.6.3-lxpup-32-pae i686
2.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)

X Server: Xorg Driver: intel
X.Org version: 1.18.3
dimensions: 1920x1080 pixels (507x285 millimeters)
depth of root window: 24 planes

direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile x86/MMX/SSE2
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.2.2

Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
Core 0: @1200 1: @1200 2: @1300 3: @1200 MHz

No problems so far.

EDIT: I added some applications.

Interim delta 16.07.1 to 16.07.2 updated - see above.

The biggest changes that need testing are those for xorgwizard (I believe)...