This did not work for me. I tried replacing the preseed in /usr/bin, made sure it was executable, etc. I even tried changing the preseed.cfg to some other configurations. It wasn’t live on the system itself, I mounted the card on another laptop. That shouldn’t make a difference though. By the way, I’m using the Proposed Alpha 3 build and used the Windows installer app (with the option switched to Wifi).
Can someone tell us what the wlan_keytype options are, and can the wlan_key be ASCII or should it be HEX?
Are you saying you were trying to execute the preseed script from the SD card while mounted in another linux box ? If so that is not going to work.
If you tried running it on OSMC (remember you can choose exit from Kodi then press ESC to log in locally) then after running it check the journal for errors like this:
‘sudo journalctl | grep preseed’
The preseed file is supposed to be generated by the installer so as such is not documented. However here is an example Wifi with DHCP preseed file:
What type of encryption is ‘1’? WEP? WPA Personal? WPA2 Personal? There are so many different ones, and I’d like to try changing between them without having to completely re-flash the SD card each time, which is why I was asking what the different settings for wlan_keytype are.
I finally connected the Raspberry Pi to a keyboard and monitor. The “sudo journalctl” command output had no mention of “preseed”. Doing an “ifconfig -a” only shows eth0 and lo0. Yet when I disconnect my wifi adapter, dmesg shows
Then when I plug it back in, I see
[quote]usb 1-1.2: new high speed USB device number 7 using dwc_otg
usb 1-1.2: New USB device found, idVendor=0bda, idProduct=0179
usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1.2: Product: 802.11n NIC
usb 1-1.2: Manufacturer: Realtek
usb 1-1.2: SerialNumber: XXXXXXXXXXX[/quote]
and all the while (with adapter in or out) only eth0 and lo0 in “ifconfig -a”. This adapter must not be supported.
I tried a different adapter, this time it actually lists a wlan0 interface and I see “Adding interface wlan0 [ wifi ]” in the journalctl, but still no mention of preseed anywhere. Hmm, maybe this is something…
[quote]osmc kernel: rtlwifi: wireless switch is on
osmc net.agent[252]: ERROR: /sbin/ifup not found. You need to install the ifupdown package.
osmc net.agent[264]: net.agent add event for wlan0 not handled.[/quote]
Also, for whatever reason, wpa_supplicant is running with /run/wpa_supplicant argument, but there is no such ctrl file in /run. I’ll keep messing.
What I ultimately ended up doing for now was using my wrt160n with DD-WRT 3rd party firmware and hooked up to my pi by an Ethernet cable. My problem now is, I just updated the entire system and now my ethernet doesn’t even work. In ifconfig its only showing the loop back interface and when I do lsmod, not many modules are running.
is it possible in the meantime, that u installed osmc @ raspberry b wired and later u switch on wlan by the config in osmc ? …or have i wait until saturday for the final release
Same Problem! Ill install the network configuration with a Static IP … Nothing happens… Also inside the my OSMC Menu, the Ethernetport does not disable when im saying that …
I just tried installing OSMC via the Windows installer. I also filled out all 12-digits of IP address (192.168.001.230) and couldn’t get networking to work. “ifconfig -a” showed my RPi2 had an active IPv6 address, but no IPv4.
After editing the preseed file to remove all leading zeros (e.g. 192.168.1.230 instead of 192.168.001.230) and re-running the config script it all came good. Not sure if preseed can’t parse the leading zeros or I just did the requisite number of reboots…
It’s not standard practice to put leading zeros on IP addresses - just enter them as normal and you should be fine.
Preseed only runs once on first boot, so additional reboots won’t do anything for the issue.
BTW you are aware of the networking GUI in OSMC settings right ? The posts that you’re replying to in this thread date back to before we had added a networking GUI.
The network preseed option is largely obsolete now that there is a fully functioning networking GUI.
The only time it might be useful is if you had no keyboard or remote control, and your only means for remote control was a smartphone app and you wanted to set a static IP so the app could connect on first boot. Otherwise just configure your static IP after first boot.
I agree that leading zeros aren’t required in dotted decimal - except in the database I use for IP allocations at work or many 16x2 LCD configuration panels like network printers, security alarms, intelligent PDU’s etc. Obviously I’ve done enough of these to believe that when input field leaves three character positions for each octet and places the cursor in the 100’s position then I should add leading zeros.
After booting I did try to reconfigure with the Network GUI but it was unusable for address configuration, nor could I enable DHCP. All it could display was “Status: No wired connection” (although my switch was learning the MAC address and IPv6 had come up, so the port was definitely connected).
This fault can be replicated by editing /boot/preseed.cfg to add leading zeros to IP addresses, “/usr/local/preseed” and then “init 6” to reboot (or “reboot” or “shutdown -r now” depending on your background).
I’m not sure what the recommended method is to access a command line without networking… I used Power->Exit and hit <CTRL><ALT>T while the OSMC splash screen was still up. Otherwise I’d need to be re-writing the SD card again.
You can enter leading zeros into the IP address boxes on Windows too - it doesn’t mean that you should, or that it’s necessary.
The IP input boxes in the installer are simply fixed width 3 character text fields and are treated as such when forming the text string that is written to the preseed file.
The way connman works, is it will not create a “service” for an Ethernet interface that isn’t up at the link level. If the GUI says “Status: No wired connection” that means that there was no link level connection - eg no heartbeat or link layer auto-configuration had occurred yet over the physical link.
However if you are currently configured to DHCP (the default) and there is no DHCP server on the network it will try for a couple of minutes to get a DHCP assignment, and during that time it will also say no wired network. However after a couple of minutes if you go back into networking you will see a self assigned 169 address and you can then change it to a static configuration.
It’s just a quirk of the way connman handles network configuration unfortunately - not much we can do about it at the GUI level.
The ftr (first time run) service only runs once, provided it runs to completion without the system being rebooted before it’s finished, so what you suggest would not work. Please see the systemctl disable at the end of this script that prevents it from running again:
There are two ways to access a local console without network, three if you count the emergency recovery console, they are well documented here:
I’m not sure where you got CTRL-ALT-T from - I’ve used Linux since the 90’s and I’ve never come across that…
Thanks for the info and sorry about the response delays… completely different timezone :-)
I think I’ll re-summarize my points:
Because of it’s presentation, the OSMC Windows Installer may tempt some users to enter leading zeros into IPv4 octets.
Leading zeros (e.g. “192.168.001.230”) should not matter - but unfortunately they do in this implementation.
If the IP address contains leading zeros, python networking library may not parse the address. E.g. “192.168.001.230” results in the following Ethernet configuration after /usr/bin/preseed runs:
Removing the leading zeros in /boot/preseed.cfg and then re-running /usr/bin/preseed results in the expected IPv4 address being setup (no reboot required):
Once preseed’s Python code has lost the IPv4 address there is no way to recover through the configuration GUI. It will not timeout of “No wired connection”, it will not accept changes into DHCP mode and it will not display the IPv6 address. Command line intervention is required to recover from this IPv6 state.