Hmm... does my build have pdiag.....
# pdiag
ls: cannot access /etc/frisbee/: No such file or directory
/usr/sbin/pdiag: line 110: 23766 Terminated gtkdialog-splash -placement center -bg orange -text "$MSG2"
# ls /root | grep pdiag*
pdiag-20131208.tar.gz
And posting that tar ball helps to diagnose the wireless problems.
Dpup Wheezy. Woof-CE built debian wheezy 7.2 packages used
Dpup Wheezy 3.5.2.10 is out !
It is my second Woof-CE build. This update consists of bug fixes found since first Woof-CE.
UExtract and PackIt are now woof compliant and so...the Rox Right Click file type couplings are working. They are great tools and I think they challenge Xarchive soon...no...they challenge it already !
Thank you SFR of your great work !
I didnt include them to the Pinboard because that is personal choice.
- Woof-CE related ( a couple ) bugs have been fixed.
- Multiple menu application locations fixed.
- PPM download choices reduced. Double download bug possibility still persists. It is PPM bug. While updating PPM, skip Packages-debian-wheezy_updates-multimedia. It causes update process to fail. Meaning that bug also persists.
Mostly this build is sanity check to create Woof-CE Dpup Wheezy.
As side effect...you can test - use - blame - give feedback of - it.
Cheers.
Download link: http://smokey01.com/pemasu/DpupWheezy/DpupWheezy35210/
It is my second Woof-CE build. This update consists of bug fixes found since first Woof-CE.
UExtract and PackIt are now woof compliant and so...the Rox Right Click file type couplings are working. They are great tools and I think they challenge Xarchive soon...no...they challenge it already !
Thank you SFR of your great work !
I didnt include them to the Pinboard because that is personal choice.
- Woof-CE related ( a couple ) bugs have been fixed.
- Multiple menu application locations fixed.
- PPM download choices reduced. Double download bug possibility still persists. It is PPM bug. While updating PPM, skip Packages-debian-wheezy_updates-multimedia. It causes update process to fail. Meaning that bug also persists.
Mostly this build is sanity check to create Woof-CE Dpup Wheezy.
As side effect...you can test - use - blame - give feedback of - it.
Cheers.
Download link: http://smokey01.com/pemasu/DpupWheezy/DpupWheezy35210/
pdiag report from Dpup Wheezy 3.5.2.10
Hi pemasu,
D/l'd, unpacked and booted into Dpup Wheezy 3.5.2.10. Same situation as I reported regarding 3.5.2.9. pdiag being present. I ran it and it generated the reports in the attached file.
FWIW, wifi functioned in all of your rarings, your upups, the latest slacko and those which preceeded it, and in all Exprimos. I've only had wifi problems with Archpup, AlphaOne, all Wheezys, and one slacko build by jejy69.
mikesLr
D/l'd, unpacked and booted into Dpup Wheezy 3.5.2.10. Same situation as I reported regarding 3.5.2.9. pdiag being present. I ran it and it generated the reports in the attached file.
FWIW, wifi functioned in all of your rarings, your upups, the latest slacko and those which preceeded it, and in all Exprimos. I've only had wifi problems with Archpup, AlphaOne, all Wheezys, and one slacko build by jejy69.
mikesLr
- Attachments
-
- pdiag-20131208a.tar.gz
- pdiag report
- (119.39 KiB) Downloaded 388 times
-
koulaxizis
- Posts: 452
- Joined: Sun 17 Jul 2011, 18:43
- Location: Greece
- Contact:
Frugal install on netbook Acer aspire onepemasu wrote:Dpup Wheezy 3.5.2.10 is out !
First boot + settings: OK!
Add Greek keyboard: OK!
Connect through PGPRS: OK!
Update package manager*: OK!
*without the multimedia repository
But when i tried to create a save file, i got this:
I have Slacko 5.5 XL, Slacko 5.6.3 & your previous wheezy release installed in the same drive, this shouldn't happen!
[b]Christos Koulaxizis[/b]
[i]Woof woof from Greece![/i]
[color=darkred][url=https://sourceforge.net/projects/puppystuff/][ Puppy Stuff Repository ][/url][/color]
[i]Woof woof from Greece![/i]
[color=darkred][url=https://sourceforge.net/projects/puppystuff/][ Puppy Stuff Repository ][/url][/color]
Quick manual frugal install on the old Athlon XP box. Looks good.
Still need to use nouveau.noaccel=1 kernel parameter.
# report-video
VIDEO REPORT: Dpup Wheezy, version 3.5.2.10
Chip description:
VGA compatible controller: NVIDIA Corporation NV18 [GeForce4 MX 440 AGP 8x] (rev c1)
Requested by /etc/X11/xorg.conf:
Resolution (widthxheight, in pixels): 1440x900
Depth (bits, or planes): 24
Modules requested to be loaded: dbe
Probing Xorg startup log file (/var/log/Xorg.0.log):
Driver loaded (and currently in use): nouveau
Loaded modules: dbe dri dri2 exa extmod fb fbdevhw glx kbd mouse record shadowfb
Actual rendering on monitor:
Resolution: 1440x900 pixels (380x238 millimeters)
Depth: 24 planes
...the above also recorded in /tmp/report-video
-Computer-
Processor : AMD Athlon(tm) XP 2400+
Memory : 1033MB (185MB used)
Operating System : Unknown distribution
User Name : root (root)
Date/Time : Sun 08 Dec 2013 11:28:49 PM CST
-Display-
Resolution : 1440x900 pixels
OpenGL Renderer : Unknown
X11 Vendor : The X.Org Foundation
-Multimedia-
Audio Adapter : VIA8233 - VIA 8235
EDIT:
Almost forgot...... needed to use SNS to get on the internet and saving to an ext 3 partition. No NTFS or fat on this box.
Still need to use nouveau.noaccel=1 kernel parameter.
# report-video
VIDEO REPORT: Dpup Wheezy, version 3.5.2.10
Chip description:
VGA compatible controller: NVIDIA Corporation NV18 [GeForce4 MX 440 AGP 8x] (rev c1)
Requested by /etc/X11/xorg.conf:
Resolution (widthxheight, in pixels): 1440x900
Depth (bits, or planes): 24
Modules requested to be loaded: dbe
Probing Xorg startup log file (/var/log/Xorg.0.log):
Driver loaded (and currently in use): nouveau
Loaded modules: dbe dri dri2 exa extmod fb fbdevhw glx kbd mouse record shadowfb
Actual rendering on monitor:
Resolution: 1440x900 pixels (380x238 millimeters)
Depth: 24 planes
...the above also recorded in /tmp/report-video
-Computer-
Processor : AMD Athlon(tm) XP 2400+
Memory : 1033MB (185MB used)
Operating System : Unknown distribution
User Name : root (root)
Date/Time : Sun 08 Dec 2013 11:28:49 PM CST
-Display-
Resolution : 1440x900 pixels
OpenGL Renderer : Unknown
X11 Vendor : The X.Org Foundation
-Multimedia-
Audio Adapter : VIA8233 - VIA 8235
EDIT:
Almost forgot...... needed to use SNS to get on the internet and saving to an ext 3 partition. No NTFS or fat on this box.
Last edited by James C on Mon 09 Dec 2013, 05:25, edited 1 time in total.
Tried it on a VM, and looks good here.
No save issues on an ext2 partition that had other puppies.
Had to use xorgwizard to get the desired screen resolution I guess because it defaults to modsetting instead of vesa ? (Slacko 5.6.3 offered this option the quicksetup)
Also updated 3.5.2.9 to 3.5.2.10 in another (type of) VM with no issues.
No save issues on an ext2 partition that had other puppies.
Had to use xorgwizard to get the desired screen resolution I guess because it defaults to modsetting instead of vesa ? (Slacko 5.6.3 offered this option the quicksetup)
Also updated 3.5.2.9 to 3.5.2.10 in another (type of) VM with no issues.
Last edited by mavrothal on Mon 09 Dec 2013, 05:41, edited 2 times in total.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
Quickly booted 3.5.2.10 live pfix=ram on another old box and successfully saved to a Windows 7 NTFS partition.
Had to use SNS for internet connection again but was primarily testing saving on NTFS.
Had to use SNS for internet connection again but was primarily testing saving on NTFS.
- Attachments
-
- NTFS save.jpg
- (35.46 KiB) Downloaded 2795 times
BootFlash Install Puppy To USB: sdc1
Dpup Wheezy, version 3.5.2.10
Created save file.
Working as intended.
Dpup Wheezy, version 3.5.2.10
Created save file.
Working as intended.
[url=http://www.smokey01.com/pemasu/DpupWheezy/DpupWheezy35211][b]Puppy Wheezy 3.5.2.11[/b][/url]
[url=http://www.youtube.com/watch?v=He82NBjJqf8]"who let the dogs out"[/url]
[url=http://www.wellminded.com/puppy/pupsearch.htm]Search Puppy Linux for Answers[/url]
[url=http://www.youtube.com/watch?v=He82NBjJqf8]"who let the dogs out"[/url]
[url=http://www.wellminded.com/puppy/pupsearch.htm]Search Puppy Linux for Answers[/url]
Installed 3.5.2.10 onto a fresh usb drive and created a new save file, found the the wireless
module 'iwl4965', which is my intel wifi card, was not found and was not on the list of
available modules that could be loaded for wifi connections. This module was automaticly
picked up and used on the 3.5.2.7 version.
Installed 3.5.2.10 onto an exisiting 3.5.2.8, that was previously updated from a 3.5.2.7...
found that Chrome no longer runs and fails with missing lib references (libnss3*.so and
other libs that Firefox uses in it's own directory),
Examining the differences between 3.5.2.10 and 3.5.2.8, I found that '.8' had symbolic links
for the libs in '/usr/lib' and in '/initrd/usr/lib'.
Found the 3.5.2.10 had the same links in '/initrd/usr/lib', but were missing in '/usr/lib', and
reinstalling Chrome made no differences. Hense the lib ref failures.
Doing a dependency check on the Chrome package showed missing library refs, all of
which are located in the Firefox directory. Creating symblic links of all libs in the Firefox
directory within the /usr/lib', solved Chrome's startup problem.
module 'iwl4965', which is my intel wifi card, was not found and was not on the list of
available modules that could be loaded for wifi connections. This module was automaticly
picked up and used on the 3.5.2.7 version.
Installed 3.5.2.10 onto an exisiting 3.5.2.8, that was previously updated from a 3.5.2.7...
found that Chrome no longer runs and fails with missing lib references (libnss3*.so and
other libs that Firefox uses in it's own directory),
Examining the differences between 3.5.2.10 and 3.5.2.8, I found that '.8' had symbolic links
for the libs in '/usr/lib' and in '/initrd/usr/lib'.
Found the 3.5.2.10 had the same links in '/initrd/usr/lib', but were missing in '/usr/lib', and
reinstalling Chrome made no differences. Hense the lib ref failures.
Doing a dependency check on the Chrome package showed missing library refs, all of
which are located in the Firefox directory. Creating symblic links of all libs in the Firefox
directory within the /usr/lib', solved Chrome's startup problem.
About firmware dependent kernel module loading.
Woof-CE version I used had this kind of section in /sbin/pup_event_backend_modprobe:
Previous version had this kind section:
Firmware loading mechanism has been changed. I do not know atm...how it is handled now. I suppose that the kernel handles it...but I do not know how the /lib/modules/all-firmware resided firmwares are transferred to the /lib/firmware.
So...I suggest that people who know that they need firmware for their wireless...copy manually the firmwares to the /lib/firmware. I suppose that is not intended mechanism...but also it looks like that is how it works in Dpup Wheezy 3.5.2.10.
It also explains the failure in firmware dependent kernel module drivers for wireless devices.
I think I have to download latest master brach and check how things is in it now....
I used whole my weekend with latest build and fixing pinstall.sh scripts with coders. I take a rest now. Firmware problem seems solved.
Woof-CE version I used had this kind of section in /sbin/pup_event_backend_modprobe:
Code: Select all
#####BAD HACKS SECTION#####
if [ "$MODULE" = "mwave" ];then
#only install firmware tarball, do not load module (firmware script does it).
firmware_tarball_func
exit 1Code: Select all
firmware_tarball_func() {
fPATTERN='[:,]'"${MODULE}"'\.ko|[:,]'"${MODULEx}"'\.ko'
FIRMPKG="`cat /etc/modules/firmware.dep.${KERNVER} | grep -v '^#' | grep ':' | grep -E "$fPATTERN" | cut -f 1 -d ':' | head -n 1`"
if [ "$FIRMPKG" != "" ];then
iPATTERN='^'"${FIRMPKG}"'$'
if [ "`grep "$iPATTERN" /etc/modules/firmware.dep.inst.${KERNVER}`" = "" ];then
FLAGFIRM='no'
if [ -d /lib/modules/all-firmware/${FIRMPKG} ];then #111106 support firmware directories.
cp -a -f --remove-destination /lib/modules/all-firmware/${FIRMPKG}/* /
FLAGFIRM='yes'
else
if [ -f /lib/modules/all-firmware/${FIRMPKG}.tar.gz ];then
tar -z -x --strip=1 --directory=/ -f /lib/modules/all-firmware/${FIRMPKG}.tar.gz > /dev/null 2>&1
FLAGFIRM='yes'
fi
fi
if [ "$FLAGFIRM" = "yes" ];then
#execute any post-install script...
if [ -f /pinstall.${FIRMPKG}.sh ];then
BRKCNT=0
while [ 1 ];do #serialise execution of pinstall scripts...
PINSTALLCNT=`find / -maxdepth 1 -type f -name 'pinstall.*.sh' | wc -l`
[ $PINSTALLCNT -eq 1 ] && break
usleep ${SLEEPU}0 #110509
BRKCNT=$(($BRKCNT + 1))
[ $BRKCNT -gt 5 ] && break
done
cd /
/pinstall.${FIRMPKG}.sh >/dev/null 2>&1
rm -f /pinstall.${FIRMPKG}.sh >/dev/null 2>&1
fi
echo "$FIRMPKG" >> /etc/modules/firmware.dep.inst.${KERNVER} #101202 120823 moved.
fi
fi
fi
}So...I suggest that people who know that they need firmware for their wireless...copy manually the firmwares to the /lib/firmware. I suppose that is not intended mechanism...but also it looks like that is how it works in Dpup Wheezy 3.5.2.10.
It also explains the failure in firmware dependent kernel module drivers for wireless devices.
I think I have to download latest master brach and check how things is in it now....
I used whole my weekend with latest build and fixing pinstall.sh scripts with coders. I take a rest now. Firmware problem seems solved.
For firmware loading read here :
http://kernelnewbies.org/Linux_3.7
http://downloads.linuxfromscratch.org/u ... ig-6.rules
There is a third branch at github :
https://github.com/puppylinux-woof-CE/w ... e/firmware
http://kernelnewbies.org/Linux_3.7
http://git.kernel.org/cgit/linux/kernel ... 863e409d0eTeach the kernel to load firmware files directly from the filesystem instead of using udev
If Wheezy is using Kernel-3.5 than functioning udev is needed with probably+static const char *fw_path[] = {
+ "/lib/firmware/updates/" UTS_RELEASE,
+ "/lib/firmware/updates",
+ "/lib/firmware/" UTS_RELEASE,
+ "/lib/firmware"
+};
http://downloads.linuxfromscratch.org/u ... ig-6.rules
And of course firmware needs to be in /lib/firmware[/*/]# Load firmware for devices that need it
ACTION=="add", SUBSYSTEM=="firmware", RUN+="/lib/udev/firmware_helper"
There is a third branch at github :
https://github.com/puppylinux-woof-CE/w ... e/firmware
The firmware_tarball_func has been removed because the firmware in /lib/modules/all-firmware is not compressed anymore and the revan discussion here
Should be revisited since the same function also does the moving from all-firmware to firmware.
Thx for brining this up. Should be fixed in a couple of hours.
Till then please install the attached pet and see if this fixes it.
The mentioned firmware branch in woof-CE git tries to get rid of the all-firmware altogether but there are many firmware pets in the repos that need to be fixed first...
Should be revisited since the same function also does the moving from all-firmware to firmware.
Thx for brining this up. Should be fixed in a couple of hours.
Till then please install the attached pet and see if this fixes it.
The mentioned firmware branch in woof-CE git tries to get rid of the all-firmware altogether but there are many firmware pets in the repos that need to be fixed first...
- Attachments
-
- pup_event_fix.pet
- pup_event fix for wheeze 3.5.2.10
- (4.7 KiB) Downloaded 375 times
Last edited by mavrothal on Mon 09 Dec 2013, 17:16, edited 1 time in total.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
Karl Godt. I know how firmwares have been loaded in Puppy. I just dont know how they are supposed to be loaded atm.
Yeah. Newer kernels does not need much help. I suppose. I havent tested how it goes. I do have 3.12.3 kernel for Dpup Wheezy, but I dont have firmware dependent wireless to test. In my development laptop I dont seem to have any firmware dependent device, lol.
Yeah. Newer kernels does not need much help. I suppose. I havent tested how it goes. I do have 3.12.3 kernel for Dpup Wheezy, but I dont have firmware dependent wireless to test. In my development laptop I dont seem to have any firmware dependent device, lol.
Haa. I have dvb tuner sticks. I downloaded needed firmware for it. Placed it to the /lib/modules/all-firmware/dvb-usb-firmware.
I added the kernel module name to the /etc/modules/firmware.dep.
Then I rebooted. Firmware loading error.
[ 27.472309] dvb-usb: found a 'E3C EC168 DVB-T USB2.0 reference design' in cold state, will try to load a firmware
[ 27.496848] dvb-usb: did not find the firmware file. (dvb-usb-ec168.fw) Please see linux/Documentation/dvb/ for more details on firmware-problems. (-2)
[ 27.496858] dvb_usb_ec168: probe of 3-3:1.1 failed with error -2
Then...I swapped /sbin/pup_event_backend_modprobe from my older Dpup Wheezy.
Reboot:
[ 49.480923] dvb-usb: found a 'E3C EC168 DVB-T USB2.0 reference design' in cold state, will try to load a firmware
[ 49.504291] dvb-usb: downloading firmware from file 'dvb-usb-ec168.fw'
[ 49.594492] dvb-usb: found a 'E3C EC168 DVB-T USB2.0 reference design' in warm state.
[ 49.594542] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
[ 49.594656] DVB: registering new adapter (E3C EC168 DVB-T USB2.0 reference design)
[ 49.630691] DVB: registering adapter 0 frontend 0 (E3C EC100 DVB-T)...
[ 49.645365] MXL5005S: Attached at address 0xc6
[ 49.645368] dvb-usb: E3C EC168 DVB-T USB2.0 reference design successfully initialized and connected.
[ 49.645384] usbcore: registered new interface driver dvb_usb_ec168
The firmware loading just needed swapping that stripped system script to previous one.
I presume the idea is to move all firmwares to the /lib/firmware. And leave only those ones, which are more or less scripts - folders other stuff for some modems and they will be handled differently, and I suspect someone is gonna write whole new system to handle those left ones.
I like the idea. I just would have liked to know this before I used my time for this latest Dpup Wheezy. Well....as they say....I am wiser man now. I am illuminated...almost. Well....let my energy light take care of that. I switch it on...
Edit. Ooops. I noticed just now that Mavrothal confirmed my suspicion. Thank you of confirmation. Well...I did the practical test anyway. Lol.
I added the kernel module name to the /etc/modules/firmware.dep.
Then I rebooted. Firmware loading error.
[ 27.472309] dvb-usb: found a 'E3C EC168 DVB-T USB2.0 reference design' in cold state, will try to load a firmware
[ 27.496848] dvb-usb: did not find the firmware file. (dvb-usb-ec168.fw) Please see linux/Documentation/dvb/ for more details on firmware-problems. (-2)
[ 27.496858] dvb_usb_ec168: probe of 3-3:1.1 failed with error -2
Then...I swapped /sbin/pup_event_backend_modprobe from my older Dpup Wheezy.
Reboot:
[ 49.480923] dvb-usb: found a 'E3C EC168 DVB-T USB2.0 reference design' in cold state, will try to load a firmware
[ 49.504291] dvb-usb: downloading firmware from file 'dvb-usb-ec168.fw'
[ 49.594492] dvb-usb: found a 'E3C EC168 DVB-T USB2.0 reference design' in warm state.
[ 49.594542] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
[ 49.594656] DVB: registering new adapter (E3C EC168 DVB-T USB2.0 reference design)
[ 49.630691] DVB: registering adapter 0 frontend 0 (E3C EC100 DVB-T)...
[ 49.645365] MXL5005S: Attached at address 0xc6
[ 49.645368] dvb-usb: E3C EC168 DVB-T USB2.0 reference design successfully initialized and connected.
[ 49.645384] usbcore: registered new interface driver dvb_usb_ec168
The firmware loading just needed swapping that stripped system script to previous one.
I presume the idea is to move all firmwares to the /lib/firmware. And leave only those ones, which are more or less scripts - folders other stuff for some modems and they will be handled differently, and I suspect someone is gonna write whole new system to handle those left ones.
I like the idea. I just would have liked to know this before I used my time for this latest Dpup Wheezy. Well....as they say....I am wiser man now. I am illuminated...almost. Well....let my energy light take care of that. I switch it on...
Edit. Ooops. I noticed just now that Mavrothal confirmed my suspicion. Thank you of confirmation. Well...I did the practical test anyway. Lol.
Mavrothal. I like the idea. I have even had manually created Dpup Exprimo which had a lot firmwares translocated to the /lib/firmware. It was at that b43 firmware loading error time. Before Barry Kauler fixed the problem in some system script.
Is is good intention. Just dont put semi-working stuff to the master branch before someone has tested the testing branch or firmware branch version first.
Otherwise...well....read previous ten posts...you get the idea.
Is is good intention. Just dont put semi-working stuff to the master branch before someone has tested the testing branch or firmware branch version first.
Otherwise...well....read previous ten posts...you get the idea.
Please see if the pet resolves the issue.pemasu wrote: Edit. Ooops. I noticed just now that Mavrothal confirmed my suspicion. Thank you of confirmation. Well...I did the practical test anyway. Lol.
If it does (it should) you may want to respin 3.5.2.11 soon
If you rather woof it is also fixed there, but the latest zigbert's additions are currently in the "testing" branch only.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
I can not argue with thatpemasu wrote: Is is good intention. Just dont put semi-working stuff to the master branch before someone has tested the testing branch or firmware branch version first.
All I can say is that as with your laptop I did not have an issue. But then again my wireless firmware was already in /lib/firmware ...
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
Good thing would be: Placing the firmwares to the standard location would be soon learned and utilized. Hey...I have whole bunch of dvb-tuner firmwares in archive. Just install this pet...extract this tar.gz to the /lib/firmware...and no need to think more.
Puppy style mechanism is...laborious...arduous...troublesome...even painful to maintain.
Updating the /lib/firmware will be easier. There can even be ready made different sets of firmwares. For example b43 needs different sets before - after 3.X and so on.
The problem. Downloading firmwares from the .git. They have all firmwares included, and the kernel you have under work, does not use or need all of them. Brcmfmac is good example. There are newer ones and older ones, and you dont need all of them for spesific kernel.
Just brainstorming. Ignore if you dont like firmwares. Cake tastes better.
But having Tempestuous included it is better that I dont say more...I will soon show my ignorance of the universe....
Puppy style mechanism is...laborious...arduous...troublesome...even painful to maintain.
Updating the /lib/firmware will be easier. There can even be ready made different sets of firmwares. For example b43 needs different sets before - after 3.X and so on.
The problem. Downloading firmwares from the .git. They have all firmwares included, and the kernel you have under work, does not use or need all of them. Brcmfmac is good example. There are newer ones and older ones, and you dont need all of them for spesific kernel.
Just brainstorming. Ignore if you dont like firmwares. Cake tastes better.
But having Tempestuous included it is better that I dont say more...I will soon show my ignorance of the universe....
The only valid reason I see for the old firmware installation mechanism to still be in place, is the need for some analog modems that also still need an init.d entry to start at stratup and a desktop entry to manage them.pemasu wrote: Puppy style mechanism is...laborious...arduous...troublesome...even painful to maintain.
Updating the /lib/firmware will be easier.
Ideally every firmware pet could do it on its own if you could download just what you need and install it in your system. But for this you need the network access that the pet will provide.
So if you include them in the build you need a mechanism to install only what you need in the specific system. Otherwise you end up starting up all the (useless) modem firmware and have a dozen of entries in your network menu.
For all other firmware the kernel and udev manage just fine.
So currently in the "firmware" branch I just move everything to /lib/firmware but the scripts for the modems, and try to hunt down firmware pets to remake them to use /lib/firmware.
If you have a list of firmware pets included in the build(s) will make my life easier as they are all over the place.
BTW, could you (or anybody else) verify that the pet I put up, fixes the problem?
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==