Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 12 Jah­ren publi­ziert. Die Kor­rekt­heit und Ver­füg­bar­keit von Links kön­nen lei­der nicht gewähr­leis­tet werden.

Schon seit einer Wei­le habe ich unter Ubun­tu auf mei­nem EeePC das “proposed”-Repository instal­liert. Doch gera­de nach mei­nem Upgrade zu Onei­ric habe ich eini­ge merk­wür­di­ge Erschei­nungen, als deren Ursa­che ich eben die­ses Repo in Ver­dacht habe. (Außer­dem ist das “proposed”-Repo für ein Pro­duk­tiv­sys­tem – auf dem also im All­tag alles funk­tio­nie­ren soll – wohl eh nicht gut)

Nun woll­te ich ein­fach das “proposed”-Repo deak­ti­vie­ren und mein Sys­tem sozu­sa­gen (wie­der auf den Stan­dard) “deak­tua­li­sie­ren”. Aber irgend­wie funk­tio­niert das nicht so einfach…

Nach eini­gem Suchen habe ich dann einen funk­tio­nie­ren­den Weg bei “Ask Ubun­tu” gefun­den, den ich hier mal (auch für mich zum Mer­ken) ver­lin­ke: “How can I revert back from an upgrade to the Pro­po­sed repo­si­to­ry?”.

Noch ein klei­ner Hin­weis zu obi­gem Vor­ge­hen: Bevor ihr die bei­den Skrip­te durch­lau­fen lasst, deak­ti­viert das “proposed”-Repo nicht. Erst nach­dem ihr euer Sys­tem deak­tua­li­siert habt, könnt ihr bspw. über die Soft­ware-Paket­quel­len-Ver­wal­tung auf dem Rei­ter “Aktua­li­sie­run­gen” den Haken beim Repo weg machen.

Viel Glück! 🙂

Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 13 Jah­ren publi­ziert. Die Kor­rekt­heit und Ver­füg­bar­keit von Links kön­nen lei­der nicht gewähr­leis­tet werden.

Wie ich schon in einem ande­ren Bei­trag schrieb, ist/war mei­ne WLAN-Ver­bin­dung unter Ubun­tu (Maverick) in der letz­ten Zeit sehr wacke­lig. Nach­dem ich nun etwas her­um­ge­spielt und getes­tet habe, kann ich eine Lösung (die bei mir ATM recht zufrie­den­stel­lend funk­tio­niert) präsentieren.

In mei­nem Eee PC 1000 ist der WLAN-Chip “RaLink RT2860” ver­baut. Für die­sen gibt es unter Linux zwei ver­schie­de­ne Ker­nel­mo­du­le (Trei­ber), mit denen er betrie­ben wer­den kann: rt2800pci und rt2860sta. So weit ich das ver­stan­den habe, ist das Modul rt2860sta pro­prie­tä­rer Code direkt von RaLink sel­ber, wel­ches in der jewei­li­gen Linux-Dis­tri­bu­ti­on meist in einer veralteten/älteren Ver­si­on zur Ver­fü­gung steht. Im Gegen­satz dazu stammt das Modul rt2800pci aus einem Pro­jekt, wel­ches sich zum Ziel gemacht hat, freie WLAN-Trei­ber für WLAN-Chips (rt2400, rt2500, rt2570, rt61 and rt73) aus dem Hau­se RaLink zu ent­wi­ckeln. Die­ses Modul kann dem­nach sehr ein­fach in den aktu­el­len Ver­sio­nen der Dis­tri­bu­tio­nen ange­bo­ten werden.

Ubun­tu Maverick bringt stan­dard­mä­ßig bei­de oben genann­ten Modu­le mit. Ärger­li­cher­wei­se gibt es jedoch bei einer Stan­dard­in­stal­la­ti­on eini­ge Pro­ble­me mit dem (frei­en) rt2800pci Modul, so dass (bei ein­ge­schal­te­tem WLAN) auto­ma­tisch das rt2860sta Modul gela­den wird. Die­ses wie­der­um zickt (nicht nur bei mir) aber nun voll rum, so dass die WLAN-Ver­bin­dung bspw. in der FH Pots­dam unbrauch­bar ist.

Wer ähn­li­che Pro­ble­me hat, soll­te fol­gen­de Schrit­te durch­füh­ren, um das freie rt2800pci Modul in einer aktu­el­le­ren & sta­bi­le­ren Ver­si­on zu instal­lie­ren und somit evtl. (wie bei mir) die Pro­ble­me zu lösen.

  1. Instal­la­ti­on des Pake­tes linux-backports-modules-wireless-maverick-generic (dies sind neue­re Ker­nel­mo­du­le, die für den aktu­el­len Ker­nel bereit­ge­stellt wer­den)
    $ sudo aptitude install linux-backports-modules-wireless-maverick-generic
  2. Black­lis­ten des rt2860sta Moduls (heißt, Ubun­tu anwei­sen, dass die­ses Modul nicht gela­den wer­den soll)
    $ echo "blacklist rt2860sta" >> /etc/modprobe.d/blacklist.conf

    (evtl. den Vor­gang mit den bei­den Modu­len rt2800usb und rt2x00usb wiederholen)

  3. WLAN mit­tels [Fn] + [F2] deaktivieren
  4. das (aktu­ell noch gela­de­nen) Ker­nel­mo­dul rt2860sta deaktivieren/entfernen/entladen
    $ sudo rmmod -v rt2860sta
  5. WLAN mit­tels [Fn] + [F2] wie­der aktivieren

Jetzt soll­te Ubun­tu das in Schritt 1. instal­lier­te Modul rt2800pci statt des rt2860sta gela­den haben. Dies kann mit­tels lsmod|grep rt2 veri­fi­ziert wer­den. Dabei soll­te dann fol­gen­de Aus­ga­be erscheinen:

rt2800pci               7892  0 
rt2800lib              30847  1 rt2800pci
rt2x00pci               5464  1 rt2800pci
rt2x00lib              29492  3 rt2800pci,rt2800lib,rt2x00pci
crc_ccitt               1351  1 rt2800lib
mac80211              235093  3 rt2800lib,rt2x00pci,rt2x00lib
cfg80211              142616  2 rt2x00lib,mac80211
eeprom_93cx6            1345  1 rt2800pci
led_class               2633  2 rt2x00lib,eeepc_laptop

Das wars schon… – Viel Glück!

PS:
Bei mir war nach obi­gem Vor­ge­hen das WLAN ges­tern in der FHP so sta­bil, dass ich zw. 10.00 Uhr und 19.00 Uhr auf dem #isci11 per VPN ohne Unter­bre­chung online sein konnte!

Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 13 Jah­ren publi­ziert. Die Kor­rekt­heit und Ver­füg­bar­keit von Links kön­nen lei­der nicht gewähr­leis­tet werden.

Seit gut zwei Jah­ren habe (nicht nur) ich gro­ße Schwie­rig­kei­ten bei der Benut­zung des WLAN/VPN der Fach­hoch­schu­le Pots­dam unter Linux (Kub­un­tu & Ubuntu).

Zuerst lag es dar­an, dass die Instal­la­ti­on des – seit eini­gen Jah­ren nicht mehr offi­zi­ell von Cis­co Sys­tems (weiter-)entwickelten – VPN-Cli­ents recht pro­ble­ma­tisch war. Dies scheint glück­li­cher­wei­se nun seit gerau­mer Zeit (auch für Nicht-Geeks) gelöst zu sein. Wie im Wiki des Stu­Ra FB5 doku­men­tiert, pfle­ge ich z.Z. ein git repo­si­to­ry in das ich (für neue Ker­nel­ver­sio­nen) not­wen­di­ge Ände­run­gen für den (groß­ar­ti­gen!) VPN-Cli­ent von tuxx-home.at ein­pfle­ge. Somit habe ich pers. immer einen lau­fen­den vpn­cli­ent und kann die­sen auch noch ande­ren Usern zur Ver­fü­gung stellen.

Im letz­ten Semes­ter nah­men die Pro­ble­me jedoch (sub­jek­tiv) zu. – Stän­dig brach die VPN-Ver­bin­dung zusam­men und dann kam es teil­wei­se zur Nicht­er­reich­bar­keit des VPN-Ser­vers. Der Clou jedoch bestand dar­in, dass nach drei Recon­nects der VPN-Zugang mit mei­nen Log­in­da­ten für eine gerau­me Zeit (ca. 20 Minu­ten) über­haupt nicht mehr mög­lich war…
Letz­te Woche war ich dann wie­der­mal kurz vor dem Ver­zwei­feln, weil selbst an Posi­tio­nen, die bis­her recht sta­bi­le VPN-Ver­bin­dun­gen zulie­ßen, obi­ge Pro­ble­me auf­tra­ten. Nach etwas Recher­che muss­te ich dann jedoch fest­stel­len, dass wohl gar nicht der VPN-Cli­ent schul­dig ist/war, son­dern der Net­work­Ma­na­ger (unter Ubuntu).

In (fast) minüt­li­chen Abstän­den fand ich fol­gen­de Mel­dung in den System-Logdateien:
Feb 25 16:16:47 axolotl NetworkManager[749]: (wlan0): roamed from BSSID 00:16:9D:56:A3:E0 (FH-Potsdam) to (none) ((none))
Feb 25 16:16:59 axolotl NetworkManager[749]: (wlan0): roamed from BSSID (none) ((none)) to 00:16:9D:44:84:90 (FH-Potsdam)

Somit war also nicht die VPN-Ver­bin­dung durch Pro­ble­me in dem vpn­cli­ent wacke­lig, son­der die VPN-Ver­bin­dung brach stän­dig zusam­men, weil die WLAN-Ver­bin­dung immer wie­der neu (und manch­mal auch mit einem neuen/weiteren Acces­s­Point) her­ge­stellt wurde.

Grün­de:
Für obi­ge Insta­bi­li­tät habe ich einen (offi­zi­el­len Ubun­tu) Feh­ler­be­richt gefun­den → https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/291760. Aller­dings fin­det sich in den 123 Kom­men­ta­ren lei­der kei­ne ein­deu­ti­ge Begrün­dung und auch kei­ne Lösung.

Lösungs­ver­such:

  1. Deak­ti­vie­ren der “Auto con­nect” Funk­ti­on für die WLAN-Ver­bin­dung mit derm Netz­werk “FH-Pots­dam”. – Damit muss man zwar manu­ell dafür sor­gen, dass die WLAN-Ver­bin­dung auf­ge­baut wird, aller­dings kann es auch ver­hin­dern, dass oben beschrie­be­nes Roa­ming (Wech­seln des AP) nicht auto­ma­tisch pas­siert, wenn ein wei­te­rer AP in Reich­wei­te ist.
  2. Instal­la­ti­on der tages­ak­tu­el­len Ver­si­on des Net­work­Ma­na­ger mit­tels des Launch­pad-PPA. – In die­se Ver­si­on flie­ßen bspw. (auch) Ver­än­de­run­gen ein, die durch Feh­ler­be­rich­te (wie oben) erkannt und beho­ben wurden.
  3. Als Alter­na­ti­ve zum Net­work­Ma­na­ger kann auch das Pro­gramm WICD die­nen. – Mit die­sem war es ande­ren Per­so­nen, die ähn­li­che Pro­ble­me hat­ten, mög­lich, eine stabile(re) WLAN-Ver­bin­dung herzustellen.

Ich habe mich für Schritt 1 und 2 ent­schie­den und wer­de die­se Woche mal aus­pro­bie­ren, ob es etwas gehol­fen hat.

Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 13 Jah­ren publi­ziert. Die Kor­rekt­heit und Ver­füg­bar­keit von Links kön­nen lei­der nicht gewähr­leis­tet werden.

Die­se Woche habe ich nun end­lich (mal) das Update auf Kub­un­tu Maverick Meer­kat gewagt… – Und bin eigent­lich ganz zufrieden. 🙂

Hier mal schnell ein paar Sächel­chen, die vllt. hilf­reich sein könnten:

  1. Soll­tet ihr eee-con­trol (unter Lucid) instal­liert haben und Upgraden wol­len, deinstal­liert es vor­her! – Es funk­tio­niert zwar nach dem Upgrad noch, lässt sich aber ohne viel Fum­me­lei nicht wirk­lich ver­nünf­tig deinstallieren.
  2. Pro­biert – nach dem Abar­bei­ten von Punkt 1 – mal Jupi­ter aus. …und glück­li­cher­wei­se gibt es auch ein (schon) ein PPA auf launchpad.net dafür. 🙂
  3. Opti­miert die Lüf­ter­steue­rung mit dem Paket fancontrol (und pwmconfig). Mei­ne Ein­stel­lun­gen (/etc/fancontrol) fin­det ihr im Anschluss. (Einen ganz guten Erklä­rungs­bei­trag zum The­ma fin­det ihr auf blog.dinotools.de.)

Ansons­ten is alles chic bei mir. – Wie siehts bei euch aus?

Hier noch mei­ne /etc/fancontrol:

# Configuration file generated by pwmconfig, changes will be lost
INTERVAL=5
DEVPATH=hwmon0= hwmon2=devices/platform/eeepc
DEVNAME=hwmon0=acpitz hwmon2=eeepc
FCTEMPS=hwmon2/pwm1=hwmon0/temp1_input
FCFANS= hwmon2/pwm1=hwmon2/fan1_input
MINTEMP=hwmon2/pwm1=58
MAXTEMP=hwmon2/pwm1=85
MINSTART=hwmon2/pwm1=50
MINSTOP=hwmon2/pwm1=30
MAXPWM=hwmon2/pwm1=200
MINPWM=hwmon2/pwm1=30

Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 15 Jah­ren publi­ziert. Die Kor­rekt­heit und Ver­füg­bar­keit von Links kön­nen lei­der nicht gewähr­leis­tet werden.

Jetzt wird es mir aber echt schwer gemacht! 😐

Seit Wochen – schon vor Weih­nach­ten 2008 – steht für mich fest, dass ich mei­nen – nun schon etwas in die Jah­re gekom­me­nen – ASUS L2400D gegen ein Net­book erset­zen möchte/werde.
Seit­dem ver­geht eine Woche nach der ande­ren und in mir haben sich fol­gen­de Gedan­ken zu einer Ent­schei­dung gefestigt:

  • ‘preis­wert’ soll er zu erste­hen sein;
  • eine Linux-Kis­te soll es sein;
  • eine Hard­disk kommt nicht in Fra­ge und
  • Blue­tooth und WLAN – draft n – soll er an Board haben.

Die Ent­schei­dung – nach obi­gen Kri­te­ri­en – fiel dann auf einen ASUS eee PC 901 mit einer 20GB SSD.
Aber woher die­ses Tier­chen bekom­men!? – In Deutsch­land wer­den die eees nur mit M$ Win­dows und den klei­ne­ren SSDs verkauft…
Glück­li­cher­wei­se fährt die.A im März nach UK und somit ent­schied ich mich im Janu­ar – bei dem traum­haf­ten Pfund:Euro Wech­sel­kurs von 1:1 – den eee mir von ihr mit­brin­gen zu las­sen. (Wegen des QWERTZ-Tas­ta­tur­lay­outs – für ca. 15 Euros – hat­te ich bei Avi­tos ange­fragt, die mir eine Lie­fer­zeit von zwei bis drei Wochen ankündigten.)

Tja… – Mitt­ler­wei­le hat sich der Wech­sel­kurs wie­der zu mei­nen Unguns­ten ent­wi­ckelt, der anvi­sier­te eee ist in mei­nem erwähl­ten Online-Shop nicht mehr ver­füg­bar und nach ein paar Pro­be-Tipp­ver­su­chen an einem 901er eines Bekann­ten, bin ich mir auch nicht mehr ganz so sicher, ob der Winz­ling mir ‘passt’… *damn*

Na und da kommt mir doch glatt heu­te das Gewinn­spiel “Asus Eee PC 1000H auf Han­dy Flat­rate 24 zu gewin­nen” [via Leben des wolf‑u.li] gera­de recht…
Oder viel­leicht doch nicht!? – Ich mei­ne, ein eee mit ner Fest­plat­te… – und dann noch das wei­ße, auf dem sich Krat­zer bestimmt mit der Zeit schön schwarz verfärben…
Ande­rer­seits: Es heißt doch so schön: “Einem geschenk­ten Gaul schaut man nicht ins Maul.”, oder?

O.K. – ich habe jetzt mit die­sem Arti­kel­chen mit­ge­macht und soll­te For­tu­na gnä­dig sein, kann ich mich am Anfang des nächs­ten Semes­ters zu den eee-Besit­zern zäh­len – für lau…! 🙂