Περιεργο προβλημα στην εκκινηση

[jim_p]

Καλησπερα.

Επειδη μαλλον δεν ξερεις ποσα χρονια κουβαλαω στην λινουξοκαμπουρα μου...
Ειμαι σε debian 10,5 χρονια, εχω δει 50+ ενημερωσεις του πυρηνα, απο τον 2.6.20 ή 2.6.22 ως τον 4.17 που εχει σημερα και εδω και ~9 χρονια ακολουθω την εξης τακτικη: οταν περναει νεος πυρηνας, εκκινω σε αυτον και αν δεν υπαρχει προβλημα, αφαιρω τον παλιο, μιας και ειναι πλεον obsolete. Εβγαλα τον 4.16 λοιπον πριν ~10 μερες που περασα σε 4.17.

Μιας και δεν εχω τροπο να βαλω τον 4.16 απο το μαμα repo, τον βρηκα απο το "past" κομματι του liquirix repo, τον εβαλα, αλλα ουτε παλι ειχα wake on lan. Τα ιδια και με τον 4.17 του liquorix, οποτε σκεφτομαι οτι δεν εινια ο πυρηνας και ειναι το systemd 239 που μου τα χαλασε.
 

[mphxths]

Τζιμη για δοκιμασε την λυση που δινει ενας εδω

Τελευταιο ποστ στην σελιδα..στην ουσια φτιαχνει systemd service και το τρεχει στο interface που θελει...μια δοκιμη δεν βλαπτει..αν δεν παιξει απλα σβηνεις το service.

(Το στορυ σε αυτο το θεμα ειναι οτι καποιος ειχε centos 6.5 και wol και μετα εκανε upgrade σε centos 7.0 και δεν ειχε πια wol..απο οτι βλεπω στο distrowatch η εκδοση 7 ειναι η μονη που εχει systemd..στις προηγουμενες δεν αναφερεται καποια εκδοση systemd...)

[jim_p]

Η λυση με το systemd service ή με το rc.local ειναι στην ουσια ματσακονια. Απλα βαζεις να τρεχει το ethtool σε καθε εκκινηση για να αλλαζει την γνωστη παραμετρο, να μπαινει η καρτα σε "αναμονη" και ετσι εχεις wol στην επομενη εκκινηση.
Δεν αλλαζει κατι αν ειναι προβληματικος ο πυρηνας ή ο driver ή το init system, γιαυτο και μπορει να εφαρμοστει πραγματικα οπουδηποτε. Π.χ. καποτε ειχα μια παλια realtek στο μπρικι την οποια αντικατεστησα με μια intel γιαυτο το λογο ακριβως, επειδη η καρτα δεν υποστηριζε απο τη μανα της wol και δεν ηθελα να κανω την ματσακονια.
Το κακο με την δικη μου realtek στον σταθερο ειναι πως οχι μονο υποστηριζει wol, οχι μονο το wol δουλευει κανονικα αν κανω τερματισμο απο τα windows, αλλα και οτι δουλευει σωστα εδω και 6+ χρονια. Γιαυτο προτιμω να βρω τι πραγματικα φταιει, να το φτιαξω και μετα να κραξω τον οποιο maintainer εκανε την μαλακια.

Επεξ/σία 2 Αυγούστου 2018 από jim_p

[mphxths]

@jim_p

Σερφαρω δεξια-αριστερα να δω κατι σχετικο...ισως το κερνελ δεν ειναι η αιτια αλλα δες το παρακατω

https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.17.11 (κανε search στην σελιδα και βαλε να βρει την λεξη wol)

Εχει μια πολυ ενδιαφερουσα αναφορα σε bug/fix στο θεμα σου...δεν ξερω ποια εκδοση κερνελ 4.17.x εχεις ή αν οντως το κερνελ παιζει ρολο ή αν αυτο που βλεπουμε εκει ειναι σχετικο...αλλα εχει το ενδιαφερον του..

[jim_p]

Αυτο εδω λες

commit 109c03ba6c4ed8af1f77ccfc33878b05c258cd8a
Author: Heiner Kallweit <[email protected]>
Date:   Tue Jul 24 22:21:04 2018 +0200

    r8169: restore previous behavior to accept BIOS WoL settings
    
    [ Upstream commit 18041b523692038d41751fd8046638c356d77a36 ]
    
    Commit 7edf6d314cd0 tried to resolve an inconsistency (BIOS WoL
    settings are accepted, but device isn't wakeup-enabled) resulting
    from a previous broken-BIOS workaround by making disabled WoL the
    default.
    This however had some side effects, most likely due to a broken BIOS
    some systems don't properly resume from suspend when the MagicPacket
    WoL bit isn't set in the chip, see
    https://bugzilla.kernel.org/show_bug.cgi?id=200195
    Therefore restore the WoL behavior from 4.16.
    
    Reported-by: Albert Astals Cid <[email protected]>
    Fixes: 7edf6d314cd0 ("r8169: disable WOL per default")
    Signed-off-by: Heiner Kallweit <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Ναι φαινεται να ταιριαζει με το προβλημα μου. 4.17.8 εχω παντως.

[mphxths]

Μηπως να πεταγες πανω τον .11 καλου κακου να σιγουρεψουμε οτι δεν μπαινει στον δρομο μας ο κερνελ ?

[jim_p]

Που να τον βρω? Θα περναγα αυτον του liquorix αλλα εκεινος εχει 4.17.7!
https://liquorix.net/debian/pool/main/l/linux-liquorix/

Παω να τον περασω τωρα να σιγουρευτουμε τουλαχιστον...

$ uname -a
Linux mitsos 4.17.0-11.1-liquorix-amd64 #1 ZEN SMP PREEMPT liquorix 4.17-7.1~sid (2018-08-01) x86_64 GNU/Linux

Οτι καταλαβαινεις, καταλαβαινω

[tritonas00]

17 ώρες πριν, jim_p είπε

Ειμαι σε debian 10,5 χρονια

ηρωας, βαρεα ενσημα, extra επιδομα υπομονης και δωρεαν καταρτιση σε αιγυπτο-σουμεριανες γραφες 

καιρος να ερθεις σε μας για συνταξη, να ηρεμησει το κεφαλι σου 

Επεξ/σία 2 Αυγούστου 2018 από tritonas00

[mphxths]

47 λεπτά πριν, jim_p είπε

Οτι καταλαβαινεις, καταλαβαινω

Ο 4.17.7 που ο τυπος τον ονοματιζει μετα 4.17.0-μπλαμπλα ? Ειναι σοβαρος?

Δηλ οποιος τρεχει debian αναγκαστικα πρεπει να παιξει με του τυπου το ρεπο για να περασει καποιον αλλον κερνελ ?Ή πιανεις τα  compiles μετα?

Ρε που φτασαμε ?

[jim_p]

Οχι, δεν εινια αναγκη να βαλεις τον πυρηνα αυτουνου. Το μαμα repo εχει τον 4.17 σημερα αλλα δεν δινει καποιον παλιοτερο για να βαλεις. Αυτος εχει τον 4.17 στο main του repo του και τον 4.16 στο past (δικο του στησιμο προφανως).

[mphxths]

Λοιπον για να τελειωνουμε με το κερνελ και να φευγει απο την μεση , φρεσκο και ζεστο :

https://www.dropbox.com/s/4dyew5mtr91zudb/linux-image-4.17.11-custom_4.17.11-custom-10.00.Custom_amd64.deb?dl=0 (το kernel image)
https://www.dropbox.com/s/udsu8w7s721gtp1/linux-headers-4.17.11-custom_4.17.11-custom-10.00.Custom_amd64.deb?dl=0 (τα headers)

Πως γινονται install ξερεις πιστευω..
Το compile εγινε σε virtual machine , debian buster (το testing δεν ειναι αυτο?) , με το configuration του εγκατεστημενου κερνελ , και δοκιμαστηκε και boot-αρει ενω ολα δειχνουν οτι λειτουργουν κανονικα.
Για την ιστορια η αποδειξη οτι boot-αρει .

Παραυτα προχωρας με δικη σου ευθυνη..το οτι δουλεψε σε μενα και μαλιστα σε virtual machine δεν σημαινει οτι θα δουλεψει και σε σενα..κρατα και παλιοτερο κερνελ να υπαρχει καλου κακου.
Απο κει και περα δεν ξερω αν διορθωνει το "προβλημα" με το wake on lan..δεν μπορω να το τεσταρω..δοκιμασε τον και τεσταρε την φαση.Τουλαχιστον να ξερουμε οτι τρεχεις τον τελευταιο κερνελ και να επικεντρωθουμε σε αλλη κατευθυνση αν δεν λυθει κατι με τον κερνελ.

ΥΓ :Αν ηξερα οτι ακομα και σημερα το compile κραταει 30 χρονια θα εδινα περισσοτερους πυρηνες στο virtual machine , θυμηθηκα εποχες '90ς που καθομασταν και κοιτουσαμε το kernel compile με τις ωρες και κοιμομασταν πανω στην καρεκλα

Mηπως ηρθε η ωρα να ερθεις στην παρεα του arch που λεει και ο τριτωνας ?  Και μενα μου αρεσει το debian αλλα δεν μπορω να μενω πισω σε εκδοσεις προγραμματων/κερνελς κλπ

Επεξ/σία 2 Αυγούστου 2018 από mphxths

[tritonas00]

1 ώρα πριν, mphxths είπε

ΥΓ :Αν ηξερα οτι ακομα και σημερα το compile κραταει 30 χρονια θα εδινα περισσοτερους πυρηνες στο virtual machine , θυμηθηκα εποχες '90ς που καθομασταν και κοιτουσαμε το kernel compile με τις ωρες και κοιμομασταν πανω στην καρεκλα

το πρωτο που εκανα ειχε παρει 1.5 μερα σε 450mhz amd k6

[mphxths]

56 λεπτά πριν, tritonas00 είπε

το πρωτο που εκανα ειχε παρει 1.5 μερα σε 450mhz amd k6

Ουτε που θυμαμαι τοτε παλια ποσο κρατουσε .Η ηττα ηταν οταν στο τελος δεν εβγαινε κερνελ γιατι σου πεταγε "Size too big" και επρεπε να ξανακανεις το config και να ξε-ενσωματωσεις καποια πραγματα και να τα κανεις modules.Πολυ manual φαση...μακρυα απο μας...

Τεσπα με το παραπανω compile μαλακιστηκα..επρεπε να δωσω παραπανω απο 2 πυρηνες στο VM , γιατι πηγε κανα διωρο στο νερο η μαλακια...τουλαχιστον αν παιξει σωστα χαλαλι το κωλοβαρεμα που εριξα μεχρι να τελειωσει

[jim_p]

Σε ευχαριστω για τον κοπο που εκανες να χτισεις τα 2 πακετα καταρχην. Τα εγκατεστησα εδω και παρολο που μπηκαν κανονικα, εκανε και το dkms τον driver για την nvidia, οταν εκκινω στον δικο σου δεν με βγαζει ποτε στο desktop. Βγαζει και 2 μηνυματα με failed στο boot.
Οποτε το αφηνουμε εδω να δουμε αν αλλαξει κατι σε νεοτερη ενημερωση ή στον 4.18.

[mphxths]

@jim_p

Μπορει να μην σε βγαζει desktop (κατι παιχτηκε προφανως με την nvidia και τους drivers υποθετω) , αλλα αν μπορεις να βγεις σε console , θα μπορουσες να τσεκαρεις το wol στην καρτα..

Αν δεν εγινε δουλεια...το αφηνουμε..αν εγινε ομως..πλακωνεις ενα compile και τελειωσες

Επεξ/σία 3 Αυγούστου 2018 από mphxths