| Summary: | Inconsistent wifi recognition with boot-nonfree (stage1 doesn't wait enough) | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Frank Griffin <ftg> |
| Component: | Installer | Assignee: | Mageia tools maintainers <mageiatools> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | fathom, marja11, thierry.vignaud, tmb |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | CVE: | ||
| Status comment: | |||
| Attachments: |
stage1.log
report.bug ddebug.log syslog syslog stage1.log report.bug ddebug.log |
||
|
Description
Frank Griffin
2016-06-08 16:44:23 CEST
Installer does not really support installing over wireless... There is some support iirc to connect to an open (and maybe wep encrypted) ap, but no-one have done any more on wireless support in installe. And since classical iso dont need network to install, and live isos can access any network it has not really been a priority to fix... CC:
(none) =>
tmb What reason would there have been to create a boot-nonfree if not to make wireless drivers available to the installer ? What other nonfree software would be of any interest to the installer ? This must be specific to the Dell wifi NIC because the behavior is correct on my Asus laptop. (In reply to Frank Griffin from comment #2) > What reason would there have been to create a boot-nonfree if not to make > wireless drivers available to the installer ? What other nonfree software > would be of any interest to the installer ? Several storage controllers need firmware to actually show the disks, some ethernet nics also need firmware to work, ... > This must be specific to the Dell wifi NIC because the behavior is correct > on my Asus laptop. Probably, it is by any chance an atheros card on that dell ? The ability to install over wifi is a knockout function for somewhat advanced users, and if it works in 99% of cases (which it seems to), then it seems a shame to abandon it. Or maybe it works on every distro in which case we ought to have an interest in keeping up. In any case, it falls into the category of NFS, FTP, HTTP, and HD installs which, to my mind, have always been differentiators for the Mandriva/MGA distros. No advanced or corporate user uses ISOs. They either use a pure network install or else mirror one of the MGA mirrors and do a network install from that. The dead/live ISOs may be of interest to beginners, but the rest of us don't care about them. Network is the definitive source. (In reply to Frank Griffin from comment #4) > The ability to install over wifi is a knockout function for somewhat > advanced users, and if it works in 99% of cases (which it seems to), then it > seems a shame to abandon it. Or maybe it works on every distro in which > case we ought to have an interest in keeping up. In any case, it falls into > the category of NFS, FTP, HTTP, and HD installs which, to my mind, have > always been differentiators for the Mandriva/MGA distros. > Yes, I didn't say it would be nice to have, but it still needs someone to do the work of fixing/integrating stuff in stage1 for net installs and stage2 for the rest... > No advanced or corporate user uses ISOs. So they dd one of the ISOs to usb ... > They either use a pure network > install or else mirror one of the MGA mirrors and do a network install from > that. The dead/live ISOs may be of interest to beginners, but the rest of > us don't care about them. Network is the definitive source. Yes, and since they are advanced, they also know how to plug a 5⬠usb network adapter to the system if it does not have a wired connection... And if you are corporate users wants PXE, something that does not work so well on wifi... And corporate users prefer wired over wireless during installs as that is way faster... or they use disk imaging that is also fast... But if you want this... start coding... we are a community driven distro after all... It's not a question of wanting a new feature, it's been there for years and works fine. The problem is in code that has nothing to do with wireless. The installer always recognizes multiple NICs and asks which you want to use. I have a desktop machine with two wired NICs, and I always get prompted for which one to use (and have to try to remember which is which). The problem is in the code that identifies the NICs, and for all I know it can happen with wired NICs as well, i. e. skipping a valid NIC on the first time around. So I think it's a valid bug report. If someone who knows this code looks at it and says no, it's to do with wireless, and it's WONTFIX, then so be it. Ok, reading this bugreport once more shows me I missed some info the first time around, sorry about that... I think it's about hardware initialization time... the first time you boot, the wireless hw is not fully initialized so the installer sees only one interface -> no point in asking... since dhcp fails, it goes back to beginning and then when it looks at interfaces it sees 2 -> time to ask... This usually dont happend with dual Ethernet nics as they usually registers themselves pretty fast on the bus... I guess we need to add a delay in network detection part in stage1 (In reply to Thomas Backlund from comment #7) > > I guess we need to add a delay in network detection part in stage1 So whom should this bug report be assigned to? CC:
(none) =>
marja11, thierry.vignaud @Franck, you can try this patch: https://bugs.mageia.org/attachment.cgi?id=7710&action=diff You'll need to: - build drakx-installer-binaries with it, - install the resulting package, - rebuild drakx-installer-stage2 with new drakx-installer-binaries, - then try the resulting boot.iso Keywords:
(none) =>
NEEDINFO As this is nonfree, doesn't the nonfree drakx-installer-images come into play here somewhere ? yeah, it was drakx-installer-images you need to rebuild. (instead of stage2) indeed (sorry) BTW, for the record, here's the list of drivers needing a firmware: http://gitweb.mageia.org/software/drakx/plain/perl-install/list_firmwares.pm You can see we've various stuff: wifi, wired ethernet, storage, sound, video, ... OK, it's been a few years since I tried this, but I have a /home/xxx/rpm directory set up. I downloaded the SRPM for drakx-installer-binaries, and did
rpm -ivh drakx-installer-binaries
added a probe.diff to rpm/SOURCES and modified the .spec file to include a new patch entry for probe.diff, and did
rpmbuild -ba drakx-installer-binaries.spec
I got a bunch of dependency complaints about ldetect-devel, ldetect-lst-devel sysfsutils-devel, and pkgconfig(libkmod) and pkgconfig(libnewt). I brought the ldetect ones down and repeated the process for ldetect-lst, which worked, but ldetect failed for the libkmod stuff.
I figure I'm going about this wrong. Should I be installing all of these dependencies on the host system using urpmi to follow the chains ? Because drakx-installer-binaries is already installed, and so must be the dependencies. Or do I have to iteratively bring all this stuff down to rpm/SRPMS one by one ? Is there a urpmi equivalent for rpmbuild ?
BuildRequires != Requires the SRPMS has specific BuildRequires (often devel stuff) that are different from runtime requires (often just the libs stuff). So yes you must must run "urpmi drakx-installer-binarie.spec" Just wait for drakx-installer-rescue-1.53-9.mga6 landing on the mirrors.. I've added the udevadm settle testfix to d-i-b (In reply to Thomas Backlund from comment #17) > Just wait for drakx-installer-rescue-1.53-9.mga6 landing on the mirrors.. > I've added the udevadm settle testfix to d-i-b Will do, thanks. (In reply to Thierry Vignaud from comment #16) > BuildRequires != Requires > the SRPMS has specific BuildRequires (often devel stuff) that are different > from runtime requires (often just the libs stuff). > So yes you must must run "urpmi drakx-installer-binarie.spec" One more question: I tried urpmi drakx-installer-binaries.spec as non-root, and it gets a permission error trying to write to /var/lib/rpm. So that needs to be root, but the packagers page on the wiki ( https://wiki.mageia.org/en/Packagers_RPM_tutorial#From_a_source_package ) warns against doing rpmbuild as root. Are there special options needed to run urpmi in the ./rpm environment ? BTW, thanks for the tip. I never knew urpmi worked against a spec file. I just retested with the new boot-nonfree.iso, and I get the same behavior. I'll attach the ddebug.log, report.bug, stage1.log, and syslog. The sequence was boot with no wired NIC cabled, got no choice, boot dropped right into a wired install, DHCP timed out, went back to the start of install, chose HTTP again, and got a choice of wired or wireless. In order to get the diagnostic files, I had to allow the second try to get to stage2. The interesting thing in stage1.log is that I can see it finding the wireless NIC on the first try, even to noting that the driver is iwlwifi. But then it uses the wired NIC anyway. I can also see references to the udevadm_settle(). Created attachment 7973 [details]
stage1.log
Created attachment 7974 [details]
report.bug
Created attachment 7975 [details]
ddebug.log
Created attachment 7976 [details]
syslog
What about today's boot.iso? Summary:
Inconsistent wifi recognition with boot-nonfree =>
Inconsistent wifi recognition with boot-nonfree (stage1 doesn't wait enought) Same result. I'll attach the new files.
Thierry Vignaud
2016-06-17 17:55:07 CEST
Summary:
Inconsistent wifi recognition with boot-nonfree (stage1 doesn't wait enought) =>
Inconsistent wifi recognition with boot-nonfree (stage1 doesn't wait enough) removing NEEDINFO, since all requested information was supplied. Still don't know whom to assign to, since both Thierry and Thomas seemed to be working on solving this. Keywords:
NEEDINFO =>
(none) s/seemed to be/were/ ;-)
Samuel Verschelde
2016-09-09 08:56:06 CEST
Assignee:
bugsquad =>
mageiatools Both of my active laptops only have wifi, and I'm not seeing this. So I'll have to dig up an older one to see if this was ever fixed. Closing, as I haven't seen this since. Status:
NEW =>
RESOLVED |