Dpup Wheezy. Woof-CE built debian wheezy 7.2 packages used

A home for all kinds of Puppy related projects
Message
Author
User avatar
pemasu
Posts: 5474
Joined: Wed 08 Jul 2009, 12:26
Location: Finland

#581 Post by pemasu »

About firmware dependent kernel module loading.
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 1
Previous version had this kind section:

Code: 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
}
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.

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#582 Post by Karl Godt »

For firmware loading read here :
http://kernelnewbies.org/Linux_3.7
Teach the kernel to load firmware files directly from the filesystem instead of using udev
http://git.kernel.org/cgit/linux/kernel ... 863e409d0e
+static const char *fw_path[] = {
+ "/lib/firmware/updates/" UTS_RELEASE,
+ "/lib/firmware/updates",
+ "/lib/firmware/" UTS_RELEASE,
+ "/lib/firmware"
+};
If Wheezy is using Kernel-3.5 than functioning udev is needed with probably
http://downloads.linuxfromscratch.org/u ... ig-6.rules
# Load firmware for devices that need it
ACTION=="add", SUBSYSTEM=="firmware", RUN+="/lib/udev/firmware_helper"
And of course firmware needs to be in /lib/firmware[/*/]

There is a third branch at github :
https://github.com/puppylinux-woof-CE/w ... e/firmware

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#583 Post by mavrothal »

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...
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] ==

User avatar
pemasu
Posts: 5474
Joined: Wed 08 Jul 2009, 12:26
Location: Finland

#584 Post by pemasu »

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.

User avatar
pemasu
Posts: 5474
Joined: Wed 08 Jul 2009, 12:26
Location: Finland

#585 Post by pemasu »

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.

User avatar
pemasu
Posts: 5474
Joined: Wed 08 Jul 2009, 12:26
Location: Finland

#586 Post by pemasu »

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.

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#587 Post by mavrothal »

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.
Please see if the pet resolves the issue.
If it does (it should) you may want to respin 3.5.2.11 soon :wink:

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] ==

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#588 Post by mavrothal »

pemasu 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.
I can not argue with that :oops:
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] ==

User avatar
pemasu
Posts: 5474
Joined: Wed 08 Jul 2009, 12:26
Location: Finland

#589 Post by pemasu »

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....

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#590 Post by mavrothal »

pemasu wrote: Puppy style mechanism is...laborious...arduous...troublesome...even painful to maintain.

Updating the /lib/firmware will be easier.
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.
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. :shock:
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] ==

gcmartin

#591 Post by gcmartin »

@Pemasu, et.al.

This is a good find. Now that this is known by several/many of the WOOF/WOOF-CE distro builders, what is the chance that this can be document and presented so that it is followed by those who would build PUPs.

Question
  • Is there a formal process to strive to consistency in system builds?
  • And, can/does the formal process guide exception handling when older/newer firmware needs?

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#592 Post by Karl Godt »

pemasu wrote:Puppy style mechanism is...laborious...arduous...troublesome...even painful to maintain.
Hmmm ... I think it is more a LICENSE file issue ..

If the LICENSE-driver file is in it's own "tarball", then this issue would be easier to maintain - theoretically .
Theoretically, since it is no tarball anymore and no-one looks into the expanded tarball ( if the LICENSE file is missing ) .

Terry H
Posts: 708
Joined: Sun 29 Mar 2009, 16:48
Location: The Heart of Muskoka, ON Canada

#593 Post by Terry H »

Satori wrote:...
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.
Same here on new frugal install.

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

#594 Post by peebee »

mavrothal wrote: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.
On my laptop----

- without the fix pet b43 firmware cannot be found / loaded

- with the fix pet the b43 firmware was loaded and established a connection

and Frisbee was installed by pet and worked as expected.

Cheers
peebee
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

User avatar
pemasu
Posts: 5474
Joined: Wed 08 Jul 2009, 12:26
Location: Finland

#595 Post by pemasu »

Dpup Wheezy 3.5.2.11 is out !

Firmware loading failure bug fix release. Read latest couple of pages if you are interested.
Also new .svg icons and handling of them has been updated. Zigbert`s new design.

Otherwise same as previous announcement.

Download link: http://www.smokey01.com/pemasu/DpupWhee ... eezy35211/

User avatar
mikeslr
Posts: 3890
Joined: Mon 16 Jun 2008, 21:20
Location: 500 seconds from Sol

Firmware pet worked in wheezy 3.5.2.10

#596 Post by mikeslr »

Thanks pemasu and especially mavrothal. The firmware pet worked. I'm posting from wheezy (previous version now). But as pemasu has built a new pup, I'll wipe this version and start from scratch. Hopefully, it will also have solved a new problem I've just experienced
Hopeful of a solution, but before the pet was published, I created a SaveFile. Seeing its publication I booted into wheezy 3.5.2.10. Mid-boot, it stopped with instructions to run xorgwizard. That done I reached desktop, installed the pet and --uncertain if just re-starting X would suffice-- rebooted. Again, booting stalled before desktop was reached.

I'll d/l & unpack wheezy 3.5.2.11 and report back.

Edit: Now posting from wheezy 3.5.2.11. I was able to get online without a hitch. However, even though I created a SaveFile and rebooted, booting stopped at line something like "blah, blah, blah apps in /root/xinitrc" then instructions to run xorgwizard. But just typing xwin got to desktop with wireless immediately working.

p.s. downloading ISO took a long time. But that could be that my wife was also online and two floors closer to the router.

mikesLr

User avatar
koulaxizis
Posts: 452
Joined: Sun 17 Jul 2011, 18:43
Location: Greece
Contact:

#597 Post by koulaxizis »

pemasu wrote:Dpup Wheezy 3.5.2.11 is out !

Firmware loading failure bug fix release. Read latest couple of pages if you are interested.
Also new .svg icons and handling of them has been updated. Zigbert`s new design.

Otherwise same as previous announcement.

Download link: http://www.smokey01.com/pemasu/DpupWhee ... eezy35211/
Downloading now! Thanks!

I only hope not to have the same weird problem! :?
[b]Christos Koulaxizis[/b]
[i]Woof woof from Greece![/i]

[color=darkred][url=https://sourceforge.net/projects/puppystuff/][ Puppy Stuff Repository ][/url][/color]

User avatar
dejan555
Posts: 2798
Joined: Sun 30 Nov 2008, 11:57
Location: Montenegro
Contact:

#598 Post by dejan555 »

Hey pemasu, glad that someone still maintains dpup branch, I booted latest woof-CE built iso on fujitsu siemens laptop (celeron 1.86Ghz, 446Mb ram + 512 swap) 1280x768 automatically set , frugal install straight from iso, booted fast, seems to work OK so far, like the first visual impression.
puppy.b0x.me stuff mirrored [url=https://drive.google.com/open?id=0B_Mb589v0iCXNnhSZWRwd3R2UWs]HERE[/url] or [url=http://archive.org/details/Puppy_Linux_puppy.b0x.me_mirror]HERE[/url]

Satori
Posts: 47
Joined: Tue 15 Jan 2013, 01:18

#599 Post by Satori »

Hiyas...

Installed a fresh 3.5.2.11 onto a flash drive and created a fresh savefile, the wifi module
for my intel was now found and was able to connect to the 'net.

However the "dbus" and 'Description' device fields on the wifi connection pages were blanked out.
Does not affect the actual connection tho.

Updating an existing 3.5.2.10, which was updated from a working 3.5.2.8, caused the
'iwl4965' module to be lost and wifi's auto-find failed to find any appropriate driver.

Will now try to find the iwl4965 module files on a working 3.5.2.8 system and try to install
onto a 3.5.2.11 savefile... unless you can tell me where they're usually located.

User avatar
pemasu
Posts: 5474
Joined: Wed 08 Jul 2009, 12:26
Location: Finland

#600 Post by pemasu »

Satori. Easiest solution.
Copy below shown firmware to the savefile. I think that updating firmwareless 3.5.2.10 causes problem so...safest bet is to put firmware where Puppy`s firmware translocation system is not needed...ie /lib/firmware.
There is nothing wrong with kernel module...I believe...it is the firmware what the device needs.

You find the firmware from fresh 3.5.2.11. If the update loses it...that is the main problem. And you need replace it to the /lib/firmware.

modinfo iwl4965
filename: /lib/modules/3.5.2-dpup/kernel/drivers/net/wireless/iwlegacy/iwl4965.ko
firmware: iwlwifi-4965-2.ucode

Location to the firmware in 3.5.2.11:
/lib/firmware/iwlegacy/iwlwifi-4965-2.ucode

Post Reply