Posts Tagged with system

posted by qubix on May 8, 2013

Apache Logs

General Error and Auditing Logs:
Location : /usr/local/apache/logs/error_log
Info : Όλα τα σφάλματα που "πιάνει" ο httpd daemon μαζί με το στάνταρ output από cgi εφαρμογές πάει εδώ.

Domain Access Logs:
Location : /usr/local/apache/domlogs/domain.tld
Info : γενικό access log για κάθε domain

Apache Access Logs:
Location : /usr/local/apache/logs/access_log
Info : πλήρες access log με όλα τα requests που ικανοποιεί ο server.

MySQL Logs

MySQL General Information and Errors:
Location : /var/lib/mysql/$(hostname).err
Info : τα log αυτά μπορεί να βρίσκονται και στο /var/log/mysql.log e

Exim Logs
Location: /var/log/exim_mainlog
Info: To mainlog έχει τα πάντα, incoming, outgoing etc
    
Location: /var/log/exim_rejectlog
Info: Το rejectlog περιέχει όλες τις συνδέσεις που δεν έγιναν. Αυτή η πληροφορία υπάρχει και στο mainlog

cPanel logs

Όλα τα logs του cpanel βρίσκονται στο /usr/local/cpanel/logs directory.

Location: /usr/local/cpanel/logs/access_log
Info:
This access_log contains all traffic to WHM, cPanel, and webmail over http.

Location: /usr/local/cpanel/logs/error_log
Info: This error_log contains all errors that occur when accessing a cPanel related site over http or https.

FTP logs

Location: /var/log/messages
Info: Άσχετα από τον ποιό FTP server χρησιμοποιείτε, το cpanel λογκάρει τις συνδέσεις, τα uploads, downloads κλπ. Ο ίδιος ο FTP server όμως δεν έχει logfile και όλα καταγράφονται στο system messages logfile μαζί με όολα τα υπόλοιπα συστεμικά μηνύματα τα οποία καταγράφονται εκεί.

posted by qubix on April 2, 2013

Στο προηγούμενο άρθρο έγραψα για τη χρήση του xrandr ώστε να προσθέσω ένα νέο mode για καλύτερη ανάλυση. Αφού το προσθέσω όμως, στην επόμενη επανεκκίνηση θα έχουν εξαφανιστεί όλα...τι κάνουμε λοιπόν? Υπάρχουν 2 εύκολες επιλογές:

1) γράφουμε στο home του χρήστη μας το αρχείο .xprofile στο οποίο βάζουμε τις εντολές του xrandr


xrandr --newmode "1280x1024_75.00"  138.54  1280 1368 1504 1728  1024 1025 1028 1069  -HSync +Vsync
xrandr --newmode "1280x1024_60.00"  108.88  1280 1360 1496 1712  1024 1025 1028 1060 -HSync +Vsync
xrandr --addmode DVI-1 "1280x1024_75.00"
xrandr --addmode DVI-1 "1280x1024_60.00"
xrandr --output DVI-1 --mode "1280x1024_75.00"

Το κακό με μια τέτοια λύση είναι πως οι αλλαγές μας θα τρέξουν σχετικά αργά στο boot proccess και συγκεκριμένα αφότου κάνουμε login οπότε θα δούμε παράθυρα να αλλάζουν μέγεθος ή μπορεί να έχουμε σφάλματα σε applets κλπκλπ

2) Μπορούμε να βάλουμε τις εντολές στον εκάστοτε login manager μας
Για τον GDM μπορούμε να βάλουμε ένα startup script στο /etc/gdm/ ενώ για τον KDM στο /etc/kde4/kdm/Xsetup .Για τον lightdm χρειάζεται να πάμε στο /etc/lightdm/lightdm.conf και να του πούμε πως θέλουμε να τρέξει ένα script το οποίο θα έχει μέσα τις παραπάνω εντολές και το οποίο μπορούμε να το βάλουμε πχ στο /usr/share . Οπότε θα βρούμε τη γραμμή display-setup-script, θα την κάνουμε uncomment και θα προσθέσουμε το path του μαγικού script μας!
Οι παραπάνω επιλογές είναι καλύτερες γιατί τρέχουν το xrandr νωρίτερα στο boot proccess και οι αλλαγές είναι ορατές σε όλους τους χρήστες όχι μόνο σε αυτόν που βάλαμε το .xprofile .
Tέλος, είναι δυνατό να βάλουμε τις ρυθμίσεις μας στο xorg.conf, το οποίο παρότι πλέον είναι άδειο, μπορούμε να το χρησιμοποιήσουμε για τους σκοπούς μας με ασφάλεια. Επίσης θα μπορούσαμε αντί για το /etc/X11/xorg.conf να φτιάξουμε ένα directory (αν δεν υπάρχει ήδη!) /etc/X11/xorg.conf.d/ και εκεί μέσα να βάλουμε τις ρυθμίσεις για την ανάλυση.

Περισσότερα για όλα αυτά στο μπορείτε να βρείτε στο ubuntu wiki και σε πολλά άλλα μέρη στο 'net.

posted by qubix on March 31, 2013

Αφού έστησα ένα pc με ένα debian unstable (siduction) και όλα πήγαν ρολόι, ανακάλυψα πως η ανάλυση του monitor είχε κολλήσει στα 1024x768 ενώ το monitor το ίδιο μπορεί να φτάσει τα 1280x1024.
Αρχικά σκέφτηκα πως το πρόβλημα μπορεί να είναι το οτι σύνδεσα το monitor στην 2η DVI έξοδο της κάρτας ή πως κάτι δεν πήγε καλά γιατί η κάρτα έχει μόνο DVI εξόδους αλλά τίποτα από αυτά δεν έφταιγε.
Απλά..απουσίαζε η ανάλυση που ήθελα. Με το xrandr προσπάθησα να δω τι συμβαίνει:


$xrandr -q
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
DVI-0 disconnected (normal left inverted right x axis y axis)
S-video disconnected (normal left inverted right x axis y axis)
DVI-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1024x768       60.0* 
   800x600        60.3     56.2
848x480 60.0
640x480 59.9

Όντως δεν υπήρχε τέτοιο mode που ήθελα. Η λύση είναι απλή: θα το προσθέσω! Το γιατί δεν υπήρχε αυτό ήταν άλλο θέμα και απλά ήθελα να παίξει με τη σωστή ανάλυση η οθόνη. Αρχικά με το gtf (calculate VESA GTF mode lines) θα βρούμε τις παραμέτρους που χρειαζόμαστε:

$gtf 1280 1024 60
   1280x1024 @ 60.00 Hz (GTF) hsync: 63.60 kHz; pclk: 108.88 MHz
  Modeline "1280x1024_60.00"  108.88  1280 1360 1496 1712  1024 1025 1028 1060  -HSync +Vsync

Μετά θα βάλουμε ένα νέο mode στο xrandr το 1280x1024_60.00. To xrandr παίρνει GTF mode lines ακριβώς αυτό που πήραμε με το gtf δλδ! :<br/>

$xrandr --newmode "1280x1024_60.00"  108.88  1280 1360 1496 1712  1024 1025 1028 1060 -HSync +Vsync

Ξανά xrandr -q για να δούμε οτι όντως υπάρχει αυτό το νέο mode:

Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
DVI-0 disconnected (normal left inverted right x axis y axis)
S-video disconnected (normal left inverted right x axis y axis)
DVI-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1024x768       60.0* 
   800x600        60.3     56.2
848x480 60.0
640x480 59.9
1280x1024_60.00 (0x157) 108.9MHz h: width 1280 start 1360 end 1496 total 1712 skew 0 clock 63.6KHz v: height 1024 start 1025 end 1028 total 1060 clock 60.0Hz

Τώρα χρειάζεται να το προσθέσουμε στο output μας (DVI-1) ώστε να το χρησιμοποιήσει το xrandr και να αλλάξει η ανάλυση:

$xrandr --addmode DVI-1 "1280x1024_60.00"

Για τέλος αρκεί να πούμε στο xrandr να χρησιμοποιήσει το νέο mode:

$xrandr --output DVI-1 --mode "1280x1024_60.00"

Αυτό ήταν όλα φαίνονται ωραία και πάλι!

posted by qubix on January 30, 2013

Λοιπόν ήρθε η ώρα να εγκαταστήσω έναν nginx. Το μηχανάκι στο οποίο θα κάνω το πείραμα έχει ήδη επάνω ένα lamp installation οπότε για αρχή θα απεγκαταστήσω τον apache


apt-get --purge remove apache2*
Ωραία τώρα που ξεφορτωθήκαμε τον apache, πάμε να βάλουμε τον nginx

apt-get install nginx php5-fpm
Reading package lists... Done
Building dependency tree
Reading state information... Done The following extra packages will be installed: nginx-common nginx-full The following NEW packages will be installed: nginx nginx-common nginx-full php5-fpm 0 upgraded, 4 newly installed, 0 to remove and 17 not upgraded. Need to get 3,209 kB of archives. After this operation, 9,382 kB of additional disk space will be used. Do you want to continue [Y/n]? y
Μετά πάμε να ρυθμίσουμε λίγο το php5-fpm. Τι είναι όμως αυτό το fpm? Κάνοντας ένα apt-cache show php5-fpm παίρνουμε το αποτέλεσμα: Description-en: server-side, HTML-embedded scripting language (FPM-CGI binary) This package provides the Fast Process Manager interpreter that runs as a daemon and receives Fast/CGI requests. Μάλιστα, τώρα που μάθαμε τι είναι αυτό που θα ρυθμίσουμε και που εγκαταστήσαμε, πάμε στο

nano /etc/php5/fpm/php-fpm.conf
Σκοπός μας είναι να αλλάξουμε μερικές μεταβλητές τις οποίες δυστυχώς δεν βρίσκουμε στο παραπάνω αρχείο και πρέπει να πάμε στο conf του pool [www] του php5-fpm. Τα pools είναι ένας τρόπος να παραμετροποιούμε διαφορετικά sites ή groups από sites στα οποία θα συμπεριφέρεται διαφορετικά ο php5-fpm daemon.

nano /etc/php5/fpm/pool.d/www.conf
Στο αρχείο αυτό βάζουμε τα παρακάτω: pm.max_children = 25 pm.start_servers = 4 pm.min_spare_servers = 2 pm.max_spare_servers = 10 pm.max_requests = 500 request_terminate_timeout = 35s και κάνουμε ένα restart τον daemon:

/etc/init.d/php5-fpm restart
Τα παραπάνω values είναι ενδεικτικά για 1g RAM και εσείς ανάλογα με το μηχάνημά σας μπορείτε να τα τροποποιήσετε αναλόγως.
Σειρά τώρα έχει ο nginx, θέλουμε απλά να του βάλουμε τα παρακάτω: client_max_body_size 20M; client_body_buffer_size 128k; Το αρχείο είναι το /etc/nginx/nginx.conf. Αν τα παραπάνω δεν τα βρίσκουμε, τα βάζουμε μέσα στο http block, στο οποίο υπάρχουν διάφορα ενδιαφέροντα όπως gzip support, που είναι τα logs κλπ κλπ.
Τώρα πάμε να δούμε λίγο το default profile στο sites-enabled:

nano /etc/nginx/sites-enabled/default
To πρώτο που έκανα είναι να αλλάξω το root path από /usr/share/nginx σε /var/www .Επίσης έκανα comment τη γραμμή listen [::]:80 default_server; που είναι για ipv6.
Τώρα πάμε να του πούμε πως θέλουμε τα php scripts να τα περνάει στο php5-fpm. To section αυτό είναι κάτω από το: # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
Και το κάνουμε κάπως έτσι:

 fastcgi_split_path_info ^(.+.php)(/.+)$;
 # NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini
 # With php5-cgi alone:
 # fastcgi_pass 127.0.0.1:9000;
 # With php5-fpm:
 fastcgi_pass unix:/var/run/php5-fpm.sock;
 fastcgi_index index.php;
 include fastcgi_params;
Όπως βλέπουμε το κομμάτι με το από CGI παραμένει commented, αφού εμείς έχουμε fcgi με το php5-fpm. Καλό είναι να βάλουμε τα .htaccess files να μην είναι προσβάσιμα οπότε:

 # deny access to .htaccess files, if Apache's document root
 # concurs with nginx's one
 location ~ /.ht {
    deny all;
 }
Μετά από όλα αυτά, πάμε να κάνουμε reload τον nginx:

/etc/nginx/nginx reload
Σε περίπτωση σφάλματος, κοιτάμε στο /var/log/nginx/error.log. Για παράδειγμα εγώ είχα ενεργοποιήσει το ssl, το οποίο χτυπούσε και δεν μπορούσε να ξεκινήσει ο nginx.

Τεστάρουμε τώρα την εγκατάστασή μας πηγαίνοντας στο http://localhost

posted by qubix on January 15, 2013

Λοιπόν, το καλό με το linux είναι πως μπορείς να το έχεις χρόνια χωρίς να κάνεις επανεγκαταστάσεις. Ακόμη και να αλλάξεις διανομή μπορείς (εφόσον είναι στην ίδια οικογένεια πχ από debian testing σε aptosid σε siduction)! Το κακό είναι πως έτσι μπορεί να μαζευτεί πολλή σαβούρα.

Μερικά απλά βηματάκια
1) Κοιτάμε τι πακέτα έχουμε εγκαταστήσει και όσα τα θεωρούμε πλέον αχρείαστα ή άχρηστα, τα απεγκαθιστούμε με:
apt-get --purge remove my_useless_package
το όρισμα --purge remove το βάζουμε ώστε να μην κρατηθούν τα configuration αρχεία, κάτι που εκ του default το apt/dpkg/synaptic/aptitude έχουν ως πρακτική.

2) Καθαρίζουμε τα cached αρχεία του apt
Παρόλο που σε κάποιες περιπτώσεις είναι χρήσιμο να υπάρχουν τα πακέτα που έχουμε εγκαταστήσει σε μορφή deb, πράγμα που το apt κάνει εξ'ορισμού στο /var/apt/cache, γενικώς μπορούμε να τα στείλουμε στον κουβά κάνοντας:
apt-get clean

3) Καθαρίζουμε πλέον άχρηστα πακέτα που μας λέει το apt
Αν το apt μας ειδοποιήσει πως υπάρχουν πακέτα τα οποία δεν χρειάζονται πια, καλό είναι να τα βγάλουμε με:
apt-get autoremove

4) Ψάχνουμε για τυχόν ορφανά πακέτα
Εγκαθιστώντας το deborphan μπορούμε να δούμε μια λίστα με πακέτα τα οποία κάποια στιγμή ίσως εγκαταστάθηκαν ως εξαρτήσεις και πλέον δεν χρειάζονται πουθενά:
H εντολή είναι... deborphan :P
Για να βγάλουμε τα πακέτα αυτά μπορούμε να κάνουμε:
apt-get --purge remove `deborphan`
Στο bash shell ότι βάζουμε μέσα σε "`" αντικαθίσταται με το output του.

5) Επειδή είναι πιθανό να έχουν ξεμείνει configuration αρχεία από παλιότερες εγκαταστάσεις ή από παλιότερες εκδώσεις προγραμμάτων, καλό είναι κατά διαστήματα να ψάχνουμε για τέτοια configuration αρχεία. Ένας τρόπος είναι:
dpkg --list | grep '^rc\b' | awk '{ print $2 }'
Τι κάνει αυτή η εντολή:
- dpkg --list : πετάει μια λίστα με όλα τα πακέτα που υπάρχουν στο σύστημα
- grep '^rc\b' : ψάχνει για το string 'rc' στο output του dpkg --list και επιστρέφει μόνο αυτά που βρίσκει
- awk '{ print $2 }' : από αυτά που βρήκε η grep, μας διαλέγει μόνο τη δεύτερη στήλη η οποία είναι το package name.

Αν στο τέλος περάσουμε το αποτέλεσμα πάλι στο dpkg μέσω xargs, μπορούμε να τα διώξουμε οριστικά!
dpkg --list | grep '^rc\b' | awk '{ print $2 }'| xargs dpkg -P
Το -P στο dpkg είναι το PURGE.
Την ίδια λειτουργία μπορούμε να κάνουμε και με το deborphan: deborphan --find-config

Ορφανά, άχρηστα, παλιά πακέτα είναι αυτά που είτε δεν χρησιμοποιούνται πλέον από το σύστημα, είτε δεν υπάρχουν στα repositories. Οι λόγοι είναι διάφοροι όπως:
- δεν υπάρχει πλέον maintainance του πακέτου
- το πακέτο μπορεί να έχει μείνει ορφανό χωρίς developer εδώ και καιρό και να μην είχε και πολλούς χρήστες οπότε και η debian QA ομάδα μπορεί να το έχει απομακρύνει
- η τελευταία έκδοση του εν λόγω software μπορεί να έχει πακεταριστεί με άλλο όνομα είτε επειδή έχουν γίνει πολλές αλλαγές, είτε για να μην υπάρχει confict με την παλιότερη έκδοση για λόγους συμβατότητας
- το πρόγραμμα έχει αλλάξει όνομα, ο maintainer το έχει μετονομάσει αλλά έχει κρατήσει κάποια μεταβατικά πακέτα με το παλιό και μετά αυτά έχουν απομακρυνθεί από τα repos.

Όποιος και να 'ναι ο λόγος, πλέον ξέρετε πως να ξεφορτωθείτε τα παλιά αυτά πακέτα!

posted by qubix on January 11, 2013

Σε περίπτωση που ο chromium δεν μπορεί να δει το νεοεγκατεστημένο gnash, τσεκάρουμε 2 πράγματα:
1) αν είναι εγκατεστημένο το πακέτο browser-plugin-gnash και αν οχι το βάζουμε
2) σε περίπτωση που δεν υπάρχει καθόλου στα repos, ψάχνουμε για το mozilla-plugin-gnash και το εγκαθιστούμε. Μετά κάνουμε ένα symlink από τον φάκελο plugins του mozilla στον αντίστοιχο του chromium (μπορεί να είναι πχ /usr/lib/mozilla/plugins και αντίστοιχα για chromium) και αν δεν υπάρχει καν φάκελος plugins στον chromium, τον δημιουργούμε.

Μετά θα πρέπει να βλέπουμε κανονικά βίντεο και να βαράμε youtoubιάδες με χέβυ μέταλ :P

posted by qubix on January 11, 2013

Προσπαθώντας να κάνω ένα dist-upgrade, κόλλησε η διαδικασία. Συγκεκριμένα:


Unpacking replacement wine ...
dpkg: error processing /var/cache/apt/archives/wine1.5-i386_1.5.19-0ubuntu3.1_i386.deb
trying to overwrite '/usr/share/applications/wine.desktop', which is also in package wine-bin
Η λύση είναι απλή, λέμε στο dpkg να κάνει force-overwrite για κάθε περίπτωση για την οποία αποτυγχάνει:

dpkg -i --force-overwrite /var/cache/apt/archives/wine1.5-i386_1.5.19-0ubuntu3.1_i386.deb 
Στη δική σας περίπτωση θα βάλετε το αντίστοιχο /var/cache/.../..
Επειδή τώρα είναι πιθανό να εκκρεμούν και άλλα πακέτα προς εγκατάσταση από τα οποία μπορεί να εξαρτάται και το πακέτο που είχε κολλήσει, μετά τρέχουμε την

apt-get -f install
Το "-f" από το help βλέπουμε πως σημαίνει:
"-f Attempt to correct a system with broken dependencies in place"

posted by qubix on January 9, 2013

Καταρχήν, τι έστι xmail: ένας προχώ για την εποχή του MTA που πλέον δεν αναπτύσσεται, τον έχουν παρατήσει οι devs του.
Δυστυχώς σε ένα datacenter που έπεσε στα χέρια μου, υπάρχει ο εν λόγω mail server ο οποίος το ομολογώ έχει ωραίο web interface με τις απαραίτητες δυνατότητες, και view από τα διάφορα logs που κρατάει.
Αποφάσισα λοιπόν για να κάνω καλύτερο και πιο εύκολο trace προβλημάτων, να εγκαταστήσω το utility xmail queue manager,το οποίο βγαίνει για windoze,linux, solaris κ.α. Όπως και ο server και αυτό είναι παρατημένο εντελώς...αφού το κατέβασα, πήγα να το τρέξω και το μόνο που έλαβα ως απάντηση ήταν το:


 ./xqmwin 
Traceback (most recent call last):
File "qmgrwin.py", line 8, in ?
File "/usr/local/lib/python2.3/site-packages/wxPython/init.py", line 20, in ?
File "/usr/local/lib/python2.3/site-packages/wxPython/wxc.so", line 4, in ?
ImportError: libwx_gtkd-2.4.so: cannot open shared object file: No such file or directory


Παραβλέπω τα python2.3, libwx_gtkd-2.4 που είναι αρχαιολογίες, αλλά έχω python2.6 και το libwx_gtkd-2.8.x. Το πρόβλημα είναι όμως πως αυτό ντε και καλά θέλει το libwx_gtkd-2.4. Εντάξει λοιπόν, το καλό είναι πως το εν λόγω library (shared object για να είμαστε πιο ακριβείς) το έχει ήδη ο xqm στο tgz που κατέβασα, οπότε αρκεί ένα copy στο /usr/lib ή ένα ln και κομπλέ όλα.

Αλλά ..όοοχι...τώρα πετάει άλλο σφάλμα!


./xqmwin 
Traceback (most recent call last):
File "qmgrwin.py", line 8, in ?
File "/usr/local/lib/python2.3/site-packages/wxPython/init.py", line 20, in ?
File "/usr/local/lib/python2.3/site-packages/wxPython/wxc.so", line 4, in ?
ImportError: libstdc++-libc6.2-2.so.3: cannot open shared object file: No such file or directory


Άηντε βρες τώρα πακέτο από την εποχή του debian etch!! Ευτυχώς υπάρχει το archives:
http://archive.debian.org/debian/pool/main/g/gcc-2.95/libstdc++2.10-glibc2.2_2.95.4-27_i386.deb
Ελπίζω να δουλεύει και στο μέλλον το λινκ..anywayz το κατέβασα, το έκανα install με το dpkg και:


ImportError: libgdk-1.2.so.0: cannot open shared object file: No such file or directory

Παρόμοιο error...IT IS HOPELESS!!!
ΤΕΛΟΣΠΑΝΤΩΝ...τι περιμένεις από αρχαιολογίες software, να τρέξουν?? Αυτό έπαιζε και σε kernel 2.4(!!!)...Για να μη τα πολυλογώ άρχισα τα symlinks στις αντίστοιχες εκδόσεις που είχα ή μπορούσα να βάλω:
ln -s /usr/lib/i386-linux-gnu/libgtk-3.so.0 /usr/lib/libgtk-1.2.so.0
ln -s /usr/lib/i386-linux-gnu/libgdk-3.so.0 /usr/lib/libgdk-1.2.so.0
ln -s /usr/lib/i386-linux-gnu/libgmodule-2.0.so.0 /usr/lib/libgmodule-1.2.so.0
ln -s /usr/lib/i386-linux-gnu/libgthread-2.0.so.0 /usr/lib/libgthread-1.2.so.0
ln -s /lib/i386-linux-gnu/libglib-2.0.so.0 /lib/libglib-1.2.so.0

Και το αποτέλεσμα:
ImportError: /usr/lib/libwx_gtkd-2.4.so: undefined symbol: gdk_root_window

AARRRGGGGGGGGHHHH!!!!!!!!
posted by qubix on January 8, 2013

ΑΦού λοιπόν κατάφερα και έβαλα τη νέα μου tv κάρτα..δεν είχα ήχο! Μετά από μερικές στιγμές πανικού (άλλωστε έβαλα έναν πανάκριβο ενισχυτή και μεγάλα ηχεία..), κοίταξα το /proc/asound/cards και τα περιεχόμενα έδειξαν πως η default κάρτα είχε γίνει το output της τιβι κάρτας:
0 [IVTV0 ]: CX2341[56] - IVTV-0
CX2341[56] #0 Hauppauge WinTV PVR-150 TV/FM Radio/Line-In Capture
1 [SB ]: HDA-Intel - HDA ATI SB
HDA ATI SB at 0xfe9f4000 irq 16
2 [HDMI ]: HDA-Intel - HDA ATI HDMI HDA ATI HDMI at 0xfeaec000 irq 43


Προφανώς η "1" επιλογή ήταν η σωστή και όχι η "0". Για να αλλάξουμε τώρα την default επιλογή της κάρτας, αρκεί να φτιάξουμε ένα αρχείο, το /etc/asound.conf
στο οποίο θα βάλουμε τα εξής:
defaults.ctl.card 1
defaults.pcm.card 1
defaults.timer.card 1
και με ένα /etc/init.d/alsa-utils restart
ΕΧΩ ΚΑΙ ΠΑΛΙ ΗΧΟ!!

posted by qubix on December 28, 2012

Λοιπόν τελικά έβαλα arch να υσηχάσω στο λάπτοπ. Όλα καλά και όλα ωραία, μου πήρε μια μέρα να το σετάρω γενικώς και είναι ελαφρύ, γρήγορο και με πολύ καλή ανταπόκριση.
Δυστυχώς όμως..δεν μπορούσα να συνδεθώ ΜΕ ΤΙΠΟΤΑ με dhcp από την ethernet θύρα. Αρχικά δεν έβγαζα άκρη με διάφορα περίεργα μηνύματα στο dmesg τα οποία δεν πολυκαταλάβαινα
e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
ADDRCONF(NETDEV_UP): eth0: link is not ready

και το dhcpd να κολλάει στο
waiting for carrier...
Μετά από πολύ ψάξιμο, ανακάλυψα πως υπάρχει bug με το MSI όταν προσπαθεί να ξυπνήσει η κάρτα καθώς βρίσκεται σε D3 status (μπορείτε να τσεκάρετε το status με lspci -vvnn, θα δείτε κάτι σαν το
Status: D3 NoSoftRst- PME-Enable+ DSel=0 DScale=1 PME+)
Χοντρικά λοιπόν, η κάρτα πρέπει να ξυπνήσει όταν είναι inactive και γιαυτό χρησιμοποιούνται τα MSI/MSI-X interrupts, οπότε στα logs βλέπουμε τα request για αυτά τα interrupts, τα οποία όμως δεν καταφέρνουν τίποτα απολύτως καθότι ο εν λόγω driver έχει κάποιο bug και δεν καταλαβαίνει πως να στείλει το ανάλογο μήνυμα στον kernel οτι ένα interrupt συνέβη επειδή πχ συνδέσαμε το καλώδιο lan στην θύρα.

Κάπου εδώ αρχίζει ο δεύτερος γολγοθάς προσπαθώντας να βρω workaround. Τα παρακάτω απέτυχαν παταγωδώς:
1) διαγραφή και επαναφόρτωση του module
rmmod e1000e && modprobe e1000e
2) διάφορα boot flags όπως
pcie_msi=off/auto/no_msi
3) disable από το laptop mode tools το power management της κάρτας

τελικά τη λύση έδωσε το powertop(!!) Μόλις από το menu "tunables" άλλαξα το PM για την ethernet από Good σε Bad, et voila, όλα δουλεύουν ρολόι!!
όχι πως αυτό τώρα είναι σοβαρή λύση..αλλαά...

hyperworks