Hello,
I know that is maybe off-topic. I boot from live-cd and want directly remaster it, and as far as I know remaster script allows you to customize only /root and /etc. But is it possible remaster puppy with new kernel modules added to /lib/modules? I could not find if it possible on this forum so far.
Regards, Evgeniy.

UPD: Seems remaster script do right job - it has put modules in new sfs itself.

Hello,
I know that is maybe off-topic. I boot from live-cd and want directly remaster it, and as far as I know remaster script allows you to customize only /root and /etc. But is it possible remaster puppy with new kernel modules added to /lib/modules? I could not find if it possible on this forum so far.
Regards, Evgeniy.

as you found any changes are carried over except in certain areas...eg /var /tmp /dev...even changing kernels can be done via a remaster

I previously reported solved the problem of getting b43 to load.
I am using Lighthouse 4.1.2 RC2 that uses Xorg7.4 and the SMP kernel 2.6.28.5 from Newyearspup02.
I have successfully connected twice to wireless but most of the time the kernel reports an error with the firmware files.
The B43 module is the only one that successfully loads and identifies the wifi interface wlan0. To make b43 load correctly it needs the correct version of the firmware.
I copied the B43 firmware lib folder from puppy 4.1.1 into /lib/firmware from as suggested by tempestuous. The first boot was successful. Subsequent boots however complain about the firmware: 'ERROR: Firmware file "b43/b0g0initvals5.fw" not found'. But the file is there! I have changed nothing.
Each boot I check the log and I occasionally b43 is loaded successfully. Last time it happened I copied the entries from bootkernel.log so I could compare.
Log when b43 loads correctly:

Yes, I remember that there were similar problems when the bcm43xx driver was first officially used in Puppy around version 2.13.
The solution should be to unload/reload the driver late in the boot sequence.

EDIT: Oops no, don't do this from rc.local, that may mess up network configuration.

I suggest unloading/reloading the b43 driver just before the network configuration script is run. So open /etc/rc.d/rc.sysinit and around line 317 you will see this line -

Ah, I think that's an error message produced by the "standard" version of udev, via the firmware.sh script.
But Puppy uses a customised version of udev (pupevent) where firmware.sh has been replaced by pup_event_backend_firmware.

You should raise this with the developers of Lighthouse 4.1.2 RC2. I suspect they may have inadvertently added some udev components when they added KDE.

Some troubleshooting you could do:
- Check whether firmware.sh exists

Code:

cd /
find -name firmware.sh

If it exists, there will almost certainly be a conflict with pup_event_backend_firmware.

- Have a look in /etc/udev/rules.d
and check what rule is calling firmware.sh, because this is wrong.
There should be a udev rule called 50-udev-puppy-basic.rules which calls /sbin/pup_event_backend_firmware

@Tempestuous
I will pass on your observations to TazOC.
I find that most times on boot there is no wi-fi connection, but if I unload and load the b43 module several times and use Pwireless after each attempt, eventually the scan works and shows available nodes that I can connect to. If I can make it work somehow I'll take it.

With computing I expect things to be repeatable, so the variable nature of this bug has me a bit stumped.

TazOC is still ironing out the bugs in Lighthouse 4rc2, but I like it because the new SMP kernel boots properly on my hp tx1000, whereas the kernels for 4.1.1 and 4.1.2 do not boot very well and cause problems. Plus 4rc2 has a compiz-fusion .sfs file available that works great.
I use his Lighthouse301g (based on Puppy 3.01) as my day-to-day puppy - It's rock solid.

If it exists, there will almost certainly be a conflict with pup_event_backend_firmware.

- Have a look in /etc/udev/rules.d
and check what rule is calling firmware.sh, because this is wrong.

TazOC suggested

Quote:

Try deleting '/etc/udev/rules.d/50-udev-default.rules'. and rebooting. This does call firmware.sh.

... and as soon as I did this and rebooted, all was well and my wi-fi connected automatically.
Thanks for your insight and (hopefully) final resolution of this b43 problem.
B._________________Laptop: Acer Aspire 5810TZ

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum