Updating the kernel - typical problems

A home for all kinds of Puppy related projects
Message
Author
jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#21 Post by jamesbond »

This is one line in one of the udev rules is how Fatdog loads the firmware (provided they are located in /lib/firmware):

Code: Select all

SUBSYSTEM=="firmware", ACTION=="add", RUN+="firmware --firmware=$env{FIRMWARE} --devpath=$env{DEVPATH}"
The program "firmware" comes from udev itself.

Even this is no longer necessary from kernel 3.7 onwards, which has its own firmware loader, but I keep it there for compatibility reasons.

Module loading similarly is handled directly with this:

Code: Select all

ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe -bv $env{MODALIAS}"
Then the entire pup_event_backend_* stuff can go.

Module blacklisting, preference etc is done using modprobe's standard blacklist. Fatdog doesn't have a nice gui for this, but I'm sure if/when it's needed one can be written easily. So far I haven't seen many cases (the most common one is to blacklist nouveau, radeon) so there isn't need for GUI yet.

Also, don't depmod when the system boots up, it's slow. Do the depmod when the distro is built, and when one installs a new pet package containing new modules. This is one the reason why Fatdog keeps the modules outside the main sfs - so that we can easily upgrade kernel & its modules without having to mess with the rest of the base system (just replace vmlinuz & its kernel-modules.sfs).
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

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

#22 Post by mavrothal »

Funny jamesbond, we were discussing these with Mick (udev rules and kernel/firmware/aufs-utils in zdrv).
I guess FD cross-pollination :D

One issue is that puppy traditionally does not include the udev-extras where frirmware is coming from but I guess this can change (Slacko has a full udev)
I'm just not sure how udev is going to handle off-tree firmware.
Is it working in FD?
== [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
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#23 Post by mikeb »

Thanks jamesbond ... that helps clear up the last bits .
I got a bit lost trying to decipher slaxes udev rules.

Agreed on the depmod... I have seen attempts to detect if there is a need for a depmod but they seem a little hit and miss and end up taking time up anyway. The files produced are text and compress right down in squashfs anyway.
New drivers should run a depmod anyway...the build scripts normally do this if compiled.

mike

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#24 Post by jamesbond »

mavrothal wrote:Funny jamesbond, we were discussing these with Mick (udev rules and kernel/firmware/aufs-utils in zdrv).
I guess FD cross-pollination :D
:D
One issue is that puppy traditionally does not include the udev-extras where frirmware is coming from but I guess this can change (Slacko has a full udev)
You don't need the full udev if you don't want to - you can use busybox mdev for that. Or you can just take udev's "firmware" program. Or you can even write a script to do that for you :wink:

Code: Select all

Udev rule: SUBSYSTEM=="firmware", ACTION=="add", RUN+="/sbin/firmware.sh $env{FIRMWARE} $env{DEVPATH}"

Script /sbin/firmware.sh:
#!/bin/dash
echo 1 > /sys/$2/loading
cat /lib/firmware/$1 > /sys/$2/data
echo 0 > /sys/$2/loading
If you use this script then of course you can look-up the firmware elsewhere (it doesn't have to be at /lib/firmware). Note: script is untested. It also doesn't handle error cases (when firmware requested doesn't exist). For more details read here: https://www.kernel.org/doc/Documentatio ... ass/README.
I'm just not sure how udev is going to handle off-tree firmware. Is it working in FD?
I'm not sure what you mean by "off-tree" firmware. Is it the firmware you put in /usr/modules/all-firmware? If yes, answer is no, you'll need to write your own firmware loader.
If you mean "off-tree firmware" as firmware that comes with 3rd party modules, then yes, as long as they are placed in /lib/firmware, udev's firmware will load it.

mikeb, I agree udev rules could have been been more intuitive.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

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

#25 Post by mavrothal »

jamesbond wrote:I'm not sure what you mean by "off-tree" firmware.
I guess I mean firmware that is not coming from the linux-firmware.git

I also looked a bit more in all-firmware.
An issue is the support for different modems where besides the install script hat usually modprobes, there is also an entry in /etc/init.d for starting the modem at boot-up and mayby some other configuration changes. Some times that is all there is there. No actual firmware binary.
How this could be handled?
Just move the init.d and install script from all-firmware in say /usr/share/modems-setup and call them from there as needed?

Regarding scripts, I try to avoid them since they usually mean more maintenance :wink:
== [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] ==

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#26 Post by jamesbond »

mavrothal wrote:
jamesbond wrote:I'm not sure what you mean by "off-tree" firmware.
I guess I mean firmware that is not coming from the linux-firmware.git
Then it's not a problem. All firmware in linux-firwmare were more or less from third party, once they clear licensing issues then it gets included in linux-firmware.
I also looked a bit more in all-firmware.
An issue is the support for different modems where besided the install script hat usually modprobes, there is also an entry in /etc/init.d fro starting th modem at boot-up.
This is a happy problem that Fatdog doesn't have (because it doesn't have any analog modem drivers, ouch! :cry: ).
How this could be handled?
Just move the init.d and install script from all-firmware in say /usr/share/modems-setup and call them from there as needed?
That being said, I did spend sometime looking at slmodemd a long while ago (I did try to add analog modem drivers to Fatdog, but some of them are 32-bit binary blobs ... so I gave up).

If I'm not wrong, slmodemd is a userspace helper for some softmodems. It still require kernel modules and the associated firmware. Now, we need to know *who* loads the firmware - it can be loaded by a kernel module, or by the userspace helper. In either case, it makes sense to unpack and put the modem firmware under /lib/firmware just like anybody else's. If the firmware is loaded by kernel module, then we're done. If it is loaded by a userspace program, then we'll need to "patch" it so that it loads from /lib/firmware.

As for the location of the init-script, what I do in Fatdog is this: I put all of the in /etc/init.d. Scripts that you want to run at boot-up, make them executable (chmod +x), otherwise make them not-executable. You can put all the modem init scripts there, mark as non-executable. Then when you need to use it, chmod +x it and presto it will work at next boot (if you don't want to boot, just run the script immediately). No need to separate storage for "non-active" init scripts. Of course, this depends on having a good GUI for managing initscrtips in /etc/init.d (to turn it on/off, and to run it on-demand). Fortunately, Fatdog has one. Unfortunately, it is written in gtk-server and not in gtkdialog ... so not easily ported to Puppy.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

#27 Post by rerwin »

Karl Godt wrote:Just looked into /lib/modules/all-firmware/pgprs :

All files can be moved into the / filesystem :
/etc/ppp/peers/gprs* ( 3 files ) ,
/usr/bin/pgprs* ( 2 files )
and
/usr/share/applications/pgprs*.desktop ( 2 files )
as if they were already installed .

I thought that pgprs* would be linked to some modem /etc/init.d/Driver_start_stop_script like /etc/init.d/Option , which mainly creates the /dev/modem link , but that is not the case.
As a follow-on to frisbee, I looked into pgprs as a candidate for inclusion in frisbee. So I am familiar with the innards of pgprs and have considered the kind changes you suggest. (Right now, the project is 'paused' while I work on lucid pup 5.2.8.6.) Actually, I think I have a more "standard" way to implement pgprs. I am willing to take on the task of moving most of pgprs out of the all-firmware directory, possibly integrating it with the way I do it in frisbee. My main concern about its implementation is that it would always appear in the menu structure, even though most people may not need it. Even so, that is probably better than having the initial use of pgprs trigger a rebuild of the menu structure, as it does currently.

Note that Barry has moved some of the firmware "tarballs" to individual pet packages with "firmware" in their names. I probably should put pgprs into its own package, although "firmware" would not be appropriate in its name.
Richard

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

#28 Post by mavrothal »

Hmm...
Maybe just move firmwrae binaries out of all-firmware to firmware and rename the remaining in all firmware to modem-firmware-support and let pup_event keep handling these cases?
We certainly do not want all the desktop entries by default, and I think a GUI for init.d items is a call for problems triggered by the simple wrong/misunderstood/mistaken click.
== [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
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#29 Post by Karl Godt »

rerwin wrote:
Karl Godt wrote:Just looked into /lib/modules/all-firmware/pgprs :

All files can be moved into the / filesystem :
/etc/ppp/peers/gprs* ( 3 files ) ,
/usr/bin/pgprs* ( 2 files )
and
/usr/share/applications/pgprs*.desktop ( 2 files )
as if they were already installed .

I thought that pgprs* would be linked to some modem /etc/init.d/Driver_start_stop_script like /etc/init.d/Option , which mainly creates the /dev/modem link , but that is not the case.
As a follow-on to frisbee, I looked into pgprs as a candidate for inclusion in frisbee. So I am familiar with the innards of pgprs and have considered the kind changes you suggest. (Right now, the project is 'paused' while I work on lucid pup 5.2.8.6.) Actually, I think I have a more "standard" way to implement pgprs. I am willing to take on the task of moving most of pgprs out of the all-firmware directory, possibly integrating it with the way I do it in frisbee. My main concern about its implementation is that it would always appear in the menu structure, even though most people may not need it. Even so, that is probably better than having the initial use of pgprs trigger a rebuild of the menu structure, as it does currently.

Note that Barry has moved some of the firmware "tarballs" to individual pet packages with "firmware" in their names. I probably should put pgprs into its own package, although "firmware" would not be appropriate in its name.
Richard
Honestly, Richard, do what ever you want .
I was using pupdial first, but the code is not my taste .
I was using pupdial because all I knew was some wvdial code lines back then .
Today I can't understand anyone using pupdial and not pgprs-connect .
Menu problems : Big laugher !

Code: Select all

echo "## DO NOT EDIT !
## THIS FILE IS AUTOGENERATED by $0
## Edit this template in $0 instead. Thanks.
" >> /etc/wvdial.conf
:lol:

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

#30 Post by Karl Godt »

Just for general info : Today I encountered my first firmware kernel driver problem :
dmesg wrote:[ 9131.104368] phy0 -> rt2x00lib_request_firmware: Error - Failed to request Firmware.
Upgrading the kernel from 2.6.37 to 3.4 ..

ifconfig hangs for one minute at
ifconfig wlan0 0.0.0.0

both busybox and http://sourceforge.net/projects/net-tools/files/ 1.60

delaying boot for one minute .
:lol:

Just to say that now I have a hook to fiddle with driver firmware .
May take weeks to figure out things ..

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#31 Post by mikeb »

Actually, I think I have a more "standard" way to implement pgprs. I am willing to take on the task of moving most of pgprs out of the all-firmware directory, possibly integrating it with the way I do it in frisbee. My main concern about its implementation is that it would always appear in the menu structure, even though most people may not need it. Even so, that is probably better than having the initial use of pgprs trigger a rebuild of the menu structure, as it does currently.
did this too and its simple and just mean 2 more entries in an already busy but rarely visited network menu so really an unnoticed addition.

mike

Post Reply