-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
wlan0 issues with wpa_cli [rpi3b+] #204
Comments
so the combination of firmware and old kernel is the prob? if you skipped compiling your own kernel, it's possible the links for the precompiled ones are not up to date. Enabling nexmon makes the script using another, possible outdated, kernel source too. |
It’s actually difficult all in all. How can we make sure the precompiled kernel fits to the Debian stretch or buster release from ftp.debian.org
Same way, how to make sure the downloaded firmware fits.
This topic is kind of solved as “taking the correct files” does the job.
However, for me it opens the question of consistency kernel, packages, firmware (WiFi + boot).
Best
Sven
… Am 24.10.2019 um 21:19 schrieb burnbabyburn ***@***.***>:
so the combination of firmware and old kernel is the prob? if you skipped compiling your own kernel, it's possible the links for the precompiled ones are not up to date.
Enabling nexmon makes the script using another, possible outdated, kernel source too.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
I am wondering about the design target of the rpi23-gen-image project : (1) Should rpi23-gen-image create an image which always succeed and be dummy proof? or (2) Is the rpi23-gen-image a guideline of scripts that can be used to determine a valid image - but its in user hands to make things fit together (Kernel + DEB packages + firmware) My personal opinion is actually (2), which is easier to fulfill. Where (1) needs qualified and tested branches / tags. (But this is just my stupid opinion.) |
(BTW. we can rename the topic as it ended up in a more general discussion) |
hi there! sorry I don't have much time left for this project. thanks burn for the patches etc. In my opinion rpi23-gen-image should always create the "complete" and working output image. I think there are plenty options to extend and or append "all" the non std deps, pkgs, late includes, custom includes etc. with the regular command line parameters of the script. Hm the idea is to create a advanced non standard rpi23 image (the idea "back then" was to create a minimal rpi image cause there was no -minimal- variant of the offical rpi image "back then"). The script may not be dummy proof. I don't know if its debian specific. but it is just sad and boring in my opinion how often the regular, minimal boot os installation gets broken by new patches or features. AND the way these changes are sometimes communicated (hey just let the user find out...) but this is only my opinion based on the experience with this project so far. sure the goal was to create a rock solid minimal build script (if you use it without any custom options) that should create a minimal working output image now and in the future. ps. i think the self encrypted full hd encryption of the size optimized generated output image, and its onboot expand is quite unique (for any bootstrapping script you will find ... well i think), not sure if its still working fine or used mutch :) |
I think its possible to achive a rock-solid image that builds out of the box. BUT: it needs well selected sources for the downloads (kernel, deb-packages, firmware, wifi-firmware) and it needs to be maintained, at least for the standard package. BTW: this project is awesome cool! Its exactly what I need - just a small image with essential packages. Dont get me wrong, I just wanted to understand what the target is, then we can fine tune. No problem. |
This! There will be errors as i think its too much work to test all combinations possible atm . Especially if we now add wifi_fw to the calculation. So my way to contribute is by fixing the reported errors and do build an image from time to time. I have more fun adding stuff that i want in my fork and pull back some of the changes that imho fit to the projects scope. Even getting a clean and proper pull done can take some hours.
That's also my understanding of the projects scope. |
Thats perfect explaination. Thank you for all your thoughts on that topic. |
(I close that issue as it was remote repo firmware releated) |
BTW: I solved this topic by forking the original firmware repo and rolling back to the last "known" working version. That means for stretch you can find a tested firmware repo here: https://github.com/rpi23-img/firmware-nonfree |
I just thought about re-open. Why? Because I think I could create a branch or tag on that repo and finally modify the default-templates of stretch to point here. So basically this will be a reminder for myself to fix it :) |
I am using wpa_cli to manage the wlan0.
However this way seems to be broken since a couple of days.
I figured out that there was a new firmware for wifi 2 days ago. Switching back to old firmware makes wpa_cli to properly work.
Not sure how to continue.
(1) maybe this is a wpa_cli issue - not fitting to newer firmware
(2) maybe this is a firmware issue
I filled and issue here : RPi-Distro/firmware-nonfree#6
The text was updated successfully, but these errors were encountered: