Το thread του Debian (v.4)

[jim_p]

Καταρχην ειναι eide και εχει molex για τροφοδοσια. Μολις τον εβγαλα το συστημα ξεκινησε κανονικα, αφου γκρινιαξε οτι δεν τον βρηκε για να τον κανει mount. Μετα τσεκαρα στο /sys/block οτι στο ata1 ειναι οι 2 αλλοι σκληροι οποτε αυτος ηταν σιγουρα στο ata2. Τελος, οταν τον ξανασυνδεσα επανω, του εβαλα το αλλο molex που εχει μεινει απο το τροφοδοτικο και δουλεψε κανονικα. Βεβαια, το hdsentinel λεει αυτα εδω και καιρο

HDD Device  2: /dev/sdc
HDD Model ID : SAMSUNG SP0802N
HDD Serial No: 0637J1FW555749
HDD Revision : TK100-23
HDD Size     : 82615 MB
Interface    : IDE/ATA
Temperature  : 29 °C
Highest Temp.: 48 °C
Health       : 100 %
Performance  : 92 %
Power on time: 246 days, 4 hours, 38 minutes
Est. lifetime: more than 1000 days
  Problems occurred between the communication of the disk and the host 78 times. In case of a sudden crash or reboot it is recommended to try a different, short data cable (avoid round cables, use 80 wire standard cables instead).
    No actions needed.

και παρολο που εχω αλλαξει καλωδια συνεχιζει να λεει τα ιδια.

[imitheos]

Ακόμα και sataI να είναι, θέλει το πολύ 13 W.
Αλλα δεν μπορείς να προβλέψεις πώς θα συμπεριφερθεί ένα τροφοδοτικό στα τελευταία του.
Μπορεί, πχ, να δίνει σωστές τάσεις, αλλα όχι τα mA που χρειάζεται ο δίσκος.

Ναι έχεις δίκιο ότι με σιγουριά δεν μπορείς να πεις τίποτα.

Αυτό που έγραψα ήταν επειδή στις δικές μου περιπτώσεις, το πρώτο πράγμα που μου έδινε να καταλάβω ότι το τροφοδοτικό είχε πρόβλημα ήταν οι μνήμες και μετά ο επεξεργαστής. Ειδικά οι μνήμες ήταν οι πιο ευαίσθητες σε mA και γενικά στην συμπεριφορά του psu. Ποτέ δεν είχα πρόβλημα με τροφοδοτικό το οποίο να κατάλαβα μέσω του σκληρού. Αυτό βέβαια εννοείται ότι δεν είναι επιχείρημα. Επειδή δεν συνέβη σε εμένα δεν σημαίνει ότι δεν γίνεται απλά μου φάνηκε παράξενο.

Βεβαια, το hdsentinel λεει αυτα εδω και καιρο

Est. lifetime: more than 1000 days
  Problems occurred between the communication of the disk and the host 78 times. In case of a sudden crash or reboot it is recommended to try a different, short data cable (avoid round cables, use 80 wire standard cables instead).
    No actions needed.

και παρολο που εχω αλλαξει καλωδια συνεχιζει να λεει τα ιδια.

Δεν έχω χρησιμοποιήσει το sentinel αλλά αν είναι κάποιο θέμα που γράφτηκε στο firmware (π.χ s.m.a.r.t) είναι λογικό να στο εμφανίζει και μετά την αλλαγή καλωδίου. Αν γράψεις "smartctl -a /dev/sdc" θα δεις πιο λεπτομερείς πληροφορίες.

[mzaf]

Παρατήρησε κανείς μετά από αναβάθμιση σε 4.14 κάποια μικρή (πολύ μικρή) καθυστέρηση στην απόκριση του συστήματός του?

[GoofyX]

Θα είναι από τα KPTI patches. Δες στο dmesg αν υπάρχει η γραμμή

Kernel/User page tables isolation: enabled

τότε έχεις πυρήνα με ενεργό το Kernel PageTable Isolation.

[danths]

αμα θέλω να βάλω σε testing το αποθετηριο του lmde τι προσθέτω? βρήκα αυτο αλλα δεν ξερω αν ειναι σωστο

deb http://packages.linuxmint.com betsy main upstream import

[mzaf]

αμα θέλω να βάλω σε testing το αποθετηριο του lmde τι προσθέτω? βρήκα αυτο αλλα δεν ξερω αν ειναι σωστο

deb http://packages.linuxmint.com betsy main upstream import

Διάβασε
https://forums.linuxmint.com/viewtop...0fdbb84aac0e6b

[jim_p]

Παρατηρησα χτες οτι λινουξ και windows στο συστημα μου εχουν παλι 2 ωρες διαφορα. Καποτε, το timedatectl με ειχε συμβουλεψει αυτο

# timedatectl 
                      Local time: Wed 2018-01-17 12:10:56 EET
                  Universal time: Wed 2018-01-17 10:10:56 UTC
                        RTC time: Wed 2018-01-17 12:10:57
                       Time zone: Europe/Athens (EET, +0200)
       System clock synchronized: yes
systemd-timesyncd.service active: yes
                 RTC in local TZ: yes

Warning: The system is configured to read the RTC time in the local time zone.
         This mode can not be fully supported. It will create various problems
         with time zone changes and daylight saving time adjustments. The RTC
         time is never updated, it relies on external facilities to maintain it.
         If at all possible, use RTC in UTC by calling
         'timedatectl set-local-rtc 0'.

και το θεμα ειχε διορθωθει. Το προβλημα ειναι πως τωρα ειτε το βαλω 0, ειτε 1, η διαφορα στην ωρα παραμενει. Τι να κανω?

[mzaf]

Παρατηρησα χτες οτι λινουξ και windows στο συστημα μου εχουν παλι 2 ωρες διαφορα. Καποτε, το timedatectl με ειχε συμβουλεψει αυτο

# timedatectl 
                      Local time: Wed 2018-01-17 12:10:56 EET
                  Universal time: Wed 2018-01-17 10:10:56 UTC
                        RTC time: Wed 2018-01-17 12:10:57
                       Time zone: Europe/Athens (EET, +0200)
       System clock synchronized: yes
systemd-timesyncd.service active: yes
                 RTC in local TZ: yes

Warning: The system is configured to read the RTC time in the local time zone.
         This mode can not be fully supported. It will create various problems
         with time zone changes and daylight saving time adjustments. The RTC
         time is never updated, it relies on external facilities to maintain it.
         If at all possible, use RTC in UTC by calling
         'timedatectl set-local-rtc 0'.

και το θεμα ειχε διορθωθει. Το προβλημα ειναι πως τωρα ειτε το βαλω 0, ειτε 1, η διαφορα στην ωρα παραμενει. Τι να κανω?

Ρύθμιση από windows
Open regedit.

Navigate to the following key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation

Right-click in the white area and select New --> DWORD (32-bit Value)

Name the key RealTimeIsUniversal.

Double-click on it and set its value to 1.

[jim_p]

Δεν θελω να βαλω τα windows σε utc, αν ηταν θα το ειχα κανει αυτα τα 10 χρονια που ειμαι με dual boot debian και windows.
Το συγκεκριμενο θεμα εμφανιστηκε μια φορα μετα την μεταβαση σε systemd, μια φορα στο ασχετο περυσι και αλλη μια τωρα. Και πλεον, λογω systemd, δεν υπαρχει η επιλογη στο /etc/default/rcS που υπηρχε την εποχη του sysvinit.

- - - Updated - - -

Τωρα ειδα οτι ισχυουν τα παρακατω
- "timedatectl set-local-rtc 0" => "UTC" στην τελευταια γραμμη του /etc/adjtime => το debian βλεπει το ρολοϊ σαν utc
- "timedatectl set-local-rtc 1" => "LOCAL" στην τελευταια γραμμη του /etc/adjtime => το debian βλεπει το ρολοϊ σαν τοπικη ωρα
αλλα και παλι η διαφορα ειναι η ιδια.

Και το bios αυτη τη στιγμη λεει 12:30, αρα το debian ειναι που κανει λαθος και προσθετει +2.

[mzaf]

Δεν ξέρω Jim,κάποιο bug του debian ίσως?
Υπάρχει κάποιος συγκεκριμένος λόγος που δεν θέλεις να βάλεις τα windows σε utc?

[jim_p]

Ας πουμε επειδη ετσι το ειχα απο παντα και επειδη για να μεινει η αλλαγη στα windows, απ' οσα εχω διαβασει, πρεπει να κοπει η "ωρα ιντερνετ", δηλαδη ο συγχρονισμος που κανουν τα windows με καποιον ntp σερβερ για να κρατανε την ωρα σωστη.

[ifaigios]

Ας πουμε επειδη ετσι το ειχα απο παντα και επειδη για να μεινει η αλλαγη στα windows, απ' οσα εχω διαβασει, πρεπει να κοπει η "ωρα ιντερνετ", δηλαδη ο συγχρονισμος που κανουν τα windows με καποιον ntp σερβερ για να κρατανε την ωρα σωστη.

Δεν είναι καλό να πειράζουν και τα Windows και το Linux όλη την ώρα το system clock. Όπως σου γράφει και το timedatectl, η μόνη σωστή λύση είναι να βάλεις το Linux και τα Windows σε UTC, και να κλείσεις την "Ώρα Ίντερνετ" των Windows. Εγώ το έχω έτσι εδώ και 7 χρόνια και δουλεύει άψογα.

[jim_p]

Και εγω το εχω με τον αλλο τροπο, δηλαδη το debian σε local, απο τοτε που εχω debian, δηλαδη εδω και 10 χρονια, και δουλευε επισης αψογα. Και τωρα δεν δουλευει σωστα επειδη το debian δεν αντιλαμβανεται οτι η ωρα στο bios ειναι σε local και την θεωρει utc.
Να προσθεσω πως καποια στιγμη μεσα στην προηγουμενη εβδομαδα εγινε ενα ακυρο bios reset λογω διακοπης ρευματος και, τοτε, ξαναρυθμισα την ωρα μπαινοντας στο debian και τρεχοντας ενα απλο ntpdate-debian γιατι βαριομουν να την ρυθμισω απο το bios. Επισης, απ' οτι δειχνει το timedatactl, ειμαι στο σωστο timezone. Το ιδιο timezone δειχνουν και τα windows.

Τελος, να αναφερω και ενα παρατραγουδο που ετυχε σημερα και το προσεξα. Γυρω στις 9 παρα, εστειλα ενα μηνυμα στο fb σε ενα φιλο μου, και το timestamp του εγραφε 6:47! Και το τρελο ειναι οτι και σε αλλο browser, ακομα και σε αλλη συσκευη λεει οτι το εστειλα εκεινη την ωρα!

- - - Updated - - -

Εβαλα τελικα την (local) ωρα στο bios με ενα

hwclock --systohc

γιατι βαριομουν να μπω να τη γραψω, εβαλα και το "timedatectl set-local-rtc 1" και ολα ειναι οπως πριν.

[jim_p]

Ποσο στεκει αυτο που λεει εδω με το patchelf?
https://steemit.com/linux/@crokkon/f...out-pulseaudio

[imitheos]

Ποσο στεκει αυτο που λεει εδω με το patchelf?
https://steemit.com/linux/@crokkon/f...out-pulseaudio

Λογικά πρέπει να στέκει. Δεν έχω pulseaudio για να σου πω στα σίγουρα οπότε θα προσπαθήσω να το εξηγήσω.

Οι devs του firefox αποφάσισαν από μία έκδοση και μετά (επειδή είχαν πολλά bug reports για alsa ή για κάτι τέτοιο) ότι θα χτίζουν τα binaries του με pulseaudio. Αυτό ισχύει μόνο για τα binaries που υπάρχουν στο ftp.mozilla.org. Σε μία source διανομή όπως το gentoo, μπορείς να το χτίσεις με alsa αν θέλεις. Στις binary διανομές εξαρτάται από τι κάνει ο maintainer. Αν παίρνει το tar από το ftp.mozilla.org και απλά το κάνει repackage, τότε είναι χτισμένο με pulseaudio. Αν το χτίζει από την αρχή, τότε μπορεί να κάνει ό,τι θέλει.

Τι κάνει τώρα το apulse. Χτίζει βιβλιοθήκες με ακριβώς ίδιο όνομα με αυτές του pulseaudio και ένα ελάχιστο api ώστε οι εφαρμογές να νομίζουν ότι "μιλούν" με pulseaudio ενώ μιλάνε με alsa. Για να μην σου πηδάει το σύστημα, αυτές οι βιβλιοθήκες εγκαθίστανται όχι στο /usr/lib64 αλλά σε ένα κατάλογο που δεν υπάρχει στο /etc/ld.so.conf οπότε κανονικά δεν μπορούν να τις βρουν τα προγράμματα.

Όταν τρέχεις "apulse εφαρμογή", το wrapper κάνει μια δουλειά που είναι σαν να θέτεις τιμή στο LD_LIBRARY_PATH οπότε τα προγράμματα βλέπουν τις pulseaudio βιβλιοθήκες και λειτουργούν κανονικά. Δες ένα χαζό παράδειγμα παρακάτω:

% cd /opt/google/chrome 
% ldd nacl_helper|grep found
	libgconf-2.so.4 => not found
% export LD_LIBRARY_PATH=/opt/google/chrome/libs
% ldd nacl_helper|grep found

% cd /usr/lib64/firefox        
% ldd libxul.so|grep found

Η libxul όμως δεν εμφανίζει κάποιο μήνυμα επειδή δεν έχει γίνει compile με την libpulse ώστε να μπορεί να τρέχει ο FF και χωρίς pulseaudio (αλλά χωρίς ήχο φυσικά). Μάλλον θα πρέπει να την κάνει dlopen όταν την βρίσκει. Ίσως λόγω αυτής της dlopen να μην παίζει σωστά το να θέσεις τιμή στο LD_LIBRARY_PATH και για αυτό να πρέπει να πειράξεις το rpath της βιβλιοθήκης ώστε να ψάχνει και στον κατάλογο της βιβλιοθήκης.

Δεν είμαι 100% σίγουρος αλλά κάτι τέτοιο πρέπει να παίζει.

Edit: Από ό,τι διαβάζω στην manpage της dlopen, δουλεύουν και το DT_RPATH και το LD_LIBRARY_PATH οπότε μάλλον δεν είναι αυτό που εξήγησα.