SL 5.4 E17 Spin x86: WiFi (Wicd) problem [Solved]

[Fitzcarraldo]

Nice! I too will be using alonsoty's wallpaper for my SL 5.4 E17 installation, as the default grey Desktop installed by the SL 5.4 E17 LiveCD is almost the same colour.

//Off topic:

Another few hours wasted, this time fighting the installer. I know this is off-topic, but the installer needs some major love.

On my first attempt I selected the text installer from the LiveCD boot menu (the graphical installer will not run because the Gateway Solo 9300 only has 288 Mb RAM). After I answered all the prompts, the installer crashed (I won't bother detailing the error messages here).

I then rebooted, this time to the LiveCD Desktop and ran /usr/bin/liveinst -T as root user in a Terminal window. The installer crashed at the same place with the same messages.

I then used the partition manager on a PCLinuxOS E17 2010.11 edition LiveCD to delete the partitions on the HDD (a swap partition of 512 Mb and the rest of the 10 Gb HDD as an ext4 root partition), then recreated and formatted them as before.

I ran the installer again -- it crashed again.

I tried several times, alternating between doing it on a VT (TTY1) with and without X running on TTY7, and in a Terminal window on the LiveCD Desktop. Still the same problem. In some of the attempts when running the installer in a Terminal window, the installer wrote willy-nilly all over the window, making it almost impossible to tell what was going on.

Finally -- and this may or may not be a coincidence -- I connected to my network and then reran the installer in a Terminal window. This time the installer ran to completion (although it hung at the end). I booted the laptop and... ended up with a Grub2 prompt. Argghh!

I then booted the LiveCD, re-ran the installer in a Terminal window and selected the option to reinstall Grub. I rebooted and, finally, ended up at the E17 Desktop of SL installed on the HDD. What a palaver.

As per my previous post I then launched nm-applet, lowered the MTU to 1464 from the command line, and connected to my network successfully. I was then able to update the Entropy DB (I had to use the --force option) and upgrade all packages.

I notice when the laptop boots that it is loading a volume group named "vg_meshedgedx". Now "meshedgedx" is the hostname of my main laptop, on which I burnt the LiveCD. Why does the LiveCD installer then use that name for a volume group on a different PC?

I then discovered that root log-in didn't work! I'm sure I entered the correct password during installation (after all, one is prompted to enter it twice). Anyway, I used sudo passwd to fix that.

This is a big contrast to my experience installing PCLinuxOS E17 edition last night, which worked first time and without any hassle.

Sorry to moan, but I had to get that off my chest.

Anyway...

EDIT (Sat Nov 27 12:40:56 GMT 2010): The installer also does not set up /etc/hosts file correctly. Below is the /etc/hosts file it created on the Gateway 9300 installation. Notice the IPv4 and IPv6 localhost aliases (and the last line too). "MeshEdgeDX" is the laptop that the LiveCD was burned on, not the laptop that SL 5.4 E17 is installed on, so why has that domain name been used for the Gateway 9300 laptop? Also the last line is a repeat of the eleventh line defining the localhost aliases, but is different. Also, the twelfth line (IPv6 localhost aliases) appears to be incomplete as it does not include the hostname.

Code: Select all

# /etc/hosts: Local Host Database
#
# This file describes a number of aliases-to-address mappings for the for
# local hosts that share this file.
#
# In the presence of the domain name service or NIS, this file may not be
# consulted at all; see /etc/host.conf for the resolution order.
#

# IPv4 and IPv6 localhost aliases
127.0.0.1       localhost sabayon MeshEdgeDX.home
::1      localhost
#
# Imaginary network.
#10.0.0.2               myname
#10.0.0.3               myfriend
#
# According to RFC 1918, you can use the following IP networks for private
# nets which will never be connected to the Internet:
#
#       10.0.0.0        -   10.255.255.255
#       172.16.0.0      -   172.31.255.255
#       192.168.0.0     -   192.168.255.255
#
# In case you want to be able to connect directly to the Internet (i.e. not
# behind a NAT, ADSL router, etc...), you need real official assigned
# numbers.  Do not try to invent your own network numbers but instead get one
# from your network provider (if any) or from your regional registry (ARIN,
# APNIC, LACNIC, RIPE NCC, or AfriNIC.)
#
127.0.0.1      MeshEdgeDX.home sabayon

Off-topic//

At last I have an installed SL 5.4 E17 Experimental Spin, with nm-applet working as the networking GUI and NetworkManager working as the networking backend. Performance is not bad for an old Gateway Solo 9300 laptop (Pentium III 700 MHz, 288 Mb RAM, 10 GB HDD), although not quite as snappy as I was hoping, but at least faster than what was installed on the laptop when I began yesterday (PCLinuxOS 2009 KDE, which worked perfectly, but was very slow for Web browsing, which is mostly what I use this old laptop for).

Now, on to Exalt...

This is what I did post-install:

Code: Select all

# nano /etc/conf.d/local # Added ifconfig wlan0 mtu 1464 (which does work, because I tried it with nm-applet).
# equo update --force # It wouldn't work without --force
# equo conf update
# equo upgrade
# equo conf update
# equo install exalt # Which installs connman too
# equo conf update

Created the initscript /etc/init.d/exaltd:

Code: Select all

#!/sbin/runscript
# Copyright 1999-2006 Gentoo Foundation
# Distributed under the terms of the GNU General Public License, v2 or later


depend() {
    need dbus hald
}


start() {
    ebegin "Starting Exalt daemon"
        start-stop-daemon --start --exec /usr/sbin/exalt-daemon \
        --pidfile /var/run/exaltd.pid
        eend $?
}

stop() {
    ebegin "Stopping Exalt daemon"
        start-stop-daemon --stop --exec /usr/sbin/exalt-daemon  \
        --pidfile /var/run/exaltd.pid
        eend $?
}

restart() {
    svc_stop
        svc_start
}

Code: Select all

# chmod +x /etc/init.d/exaltd

Set up the initscripts in the runlevels:

Code: Select all

# rc-update del NetworkManager default
# rc-update add exaltd default
# rc-update add connman default

Followed micia's steps in his earlier post:
'Main > Settings > Modules' and select 'Connection Manager' in the 'System' section.
Right-click on Shelf 5 (the right hand Shelf) and select 'Shelf bottom_right' > 'Contents'. Select 'Connection Manager' and click on 'Add Gadget'.

A ConnMan icon appeared on Shelf 5, and shows my network ESSID but refuses to connect. When I enter the WPA passkey in the ConnMan pop-up window, ConnMan keeps popping up the same window asking me again for the WPA passkey. I've tried entering it without and with quotation marks, but the behaviour is the same. Any suggestions?

[micia]

That was the same bad behavior that I experienced with exaltd, it seems that it compromises Exailt's ability to connect, even if it is in the README of the exalt trunk, I solved it removing that from the runlevels:

Code: Select all

rc-update del exaltd default


As I posted above.
(I think you can safely remove the service file in the /etc/init.d directory too... At least I did it)
leaving just connman in the runlevels.
reboot and it should now work.

Now the steps should simply be:

Code: Select all

equo install exalt
rc-update del NetworkManager default
rc-update add connman default


Add exalt to the shelf, reboot.

[Fitzcarraldo]

I solved it removing that from the runlevels:

Code: Select all

rc-update del exaltd default


As I posted above.

Whoops, I missed that in your earlier post.

leaving just connman in the runlevels.
reboot and it should now work.

Now the steps should simply be:

Code: Select all

equo install exalt
rc-update del NetworkManager default
rc-update add connman default

Add exalt to the shelf, reboot.

Wow, straight onto the network when I rebooted; not even a prompt. Nice.

So, actually, in the end does Exalt have anything at all to do with it? Is the GUI front-end ConnMan as well?. Unless it's pulling in other things, presumably there is no need to install the exalt package at all, just the connman package, or is the GUI front-end still provided by Exalt? If it is, that's a bit of a mess!

Many thanks, micia and joost. After my lack of success with the buggy Wicd yesterday, you have saved me breaking my head for a second day running.

[joost]

I think the documentation in the exalt trunk is out dated or something.
To me it looks like exalt is nothing more then a connman front end. No init scripts needed.

The installer part I can not help you with.

[joost]

Turns out that the whole exalt thing isn't needed at all.
The GUI for connman is compiled as a module with the enlightenment package.

So I will remove exalt from Entropy overlay because it is not working and it has no function afaik.

[joost]

Not sure if I should open a new topic, Fitz feel free to split off this post if you think it should be.

Knowing that connman + E17 actually works very well with a minimal deptree... I booted up the E17 daily build and tested what would happen if I removed nm-applet and its deptree:

http://www.sabayon.org/pastie/5117

Wow, that looks nice.
I think I will go spend some time working on that E17 again.

[Fitzcarraldo]

Well, well. So my suspicion about Exalt was correct. The network GUI we installed looks totally different to the Exalt GUI in those images posted by the Exalt developer over on E17-Stuff.org, which is what got me wondering.

nm-applet pulls in a lot, doesn't it? Mind you, stuff like samba and some of those sys-libs and dev-libs would still be needed I assume. Actually, I bet there is a lot of GNOME stuff installed by the SL 5.4 E17 LiveCD that doesn't need to be.

I've been tidying up this E17 installation, and it's quite usable now. The installer did not set up the locale and keyboard correctly, so I've just done that (Gentoo Localization Guide, SL Wiki clock guide etc.). I've also added my quick-and-dirty 'sleep 10s && /etc/init.d/ntp-client start' to /etc/conf.d/local in order to perform a clock sync on start-up (NetworkManager is not in use so NetworkManagerDispatcher can't be used, and I didn't want the overhead of the NTP daemon running all the time on this old Gateway laptop).

One thing I must do is insert my Belkin CardBus Ethernet card and check that wired networking works with ConnMan daemon + GUI. I may as well go and find the card now and try it. I'll report back shortly.

[joost]

The "symbolic" first steps are taken.

http://gitweb.sabayon.org/?p=molecules. ... 7e5fab15fa
http://gitweb.sabayon.org/?p=molecules. ... 3a604df812

I'm also moving the new E17 snapshot and new beta2 EFL into main repository now.

What still is todo now is change some things in skel so that:

- dbus module is loaded
- connection manager module is loaded
- add the connman icon/widget on the bottom-right shelf

[Fitzcarraldo]

You're moving fast.

I inserted the Belkin Ethernet CardBus card in the second slot (leaving the Linksys WiFi CardBus card in the first slot) and powered up the laptop. ConnMan on Shelf 5 displayed a 'Wired' icon but there was no connection to the wired or wireless network. The LNK/ACT LED on the Ethernet card's cable socket was on, so it wasn't a physical connection problem. I then selected 'Connection Manager' > 'Controls' > 'Network Switches', unticked 'WiFi' and ticked 'Wired', but no connection was established. I pulled out the WiFi CardBus card but still could not get a working connection to the wired network. I then restarted the ConnMan daemon, but this also didn't help. Then I rebooted, but still nothing happened. I unplugged and plugged-in again the Ethernet cable, but still nothing. I did this several times, then, suddenly, the wired connection began working. I inserted the WiFi CardBus card again, and now I can use the ConnMan GUI to switch back and forth between Wired and WiFi connections when both cards are plugged in.

I'm not sure why neither wired nor wireless connections would work at first, but ConnMan seems solid now with both, and switching back and forth works. My Ethernet connection needs an MTU of 1500 on this installation; my WiFi connection needs an MTU of 1464 on this installation.

Anyway, looks like ConnMan is a viable substitute for NetworkManager/nm-applet for both wired and wireless networking.

[joost]

//update:
I was making good progress and addressed all the connman issues.

and wow! it worked sweet on the live desktop. So far so good I thought, until I tried the installer.
Turns out it depends on NetworkManager functionality. I knew this but I also knew that connman was started with --compat for compatibility with Network Manager ( see /etc/conf.d/connman )

So the only way I was able to install was to stop connman and start NetworkManager. That ofcourse is silly.
Personally I don't like how our installer depends on NetworkManager, it makes it near impossible to be flexible and design your own spins.

Maybe Fabio can figure out some workaround. Thus far I can see it only uses it to grab the hostname, and duh, that isdefaulted to "sabayon" in the installer anyway (and changeable)