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

[jim_p]

Συνδεομαι με ssh (putty) στο rpi που τρεχει debian 11 stable και οταν του δινω poweroff/reboot, δεν κλεινει το παραθυρο του putty αλλα μενει εκει να με κοιταει. Αντιθετα, σε αλλα συστηματα που συνδεομαι, βγαζει το prompt για κλεισιμο οταν σταματησει η συνδεση (ή με γυρναει στο δικο μου prompt οταν μπαινω απο το τερματικο μου), οποτε τι λειπει απο εκει για να εχω την ιδια συμπεριφορα?

[Gentoo]

Συνδεομαι με ssh (putty) στο rpi που τρεχει debian 11 stable και οταν του δινω poweroff/reboot, δεν κλεινει το παραθυρο του putty αλλα μενει εκει να με κοιταει. Αντιθετα, σε αλλα συστηματα που συνδεομαι, βγαζει το prompt για κλεισιμο οταν σταματησει η συνδεση (ή με γυρναει στο δικο μου prompt οταν μπαινω απο το τερματικο μου), οποτε τι λειπει απο εκει για να εχω την ιδια συμπεριφορα?

Ίσως πρέπει να ορίσεις στο sshd_config του rpi -> TCPKeepAlive no (με επανεκκίνηση του ssh φυσικά στον server για να πάρει την αλλαγή).

[jim_p]

Ειναι commented out η συγκεκριμενη επιλογη, αν και ειναι σε yes. Και ετσι ειναι και στα αλλα συστηματα που εχω, ακομα και σε αυτα που δεν τρεχουν debian!
Μηπως λοιπον εινια καποιο policy ή κατι τετοιο του systemd που μου λειπει? Το μονο σημαντικο πακετο που εβγαλα οταν εστησα το λειτουργικο στο rpi ηταν το apparmor, μαζι με τις εξαρτησεις του προφανως.

[Gentoo]

Ειναι commented out η συγκεκριμενη επιλογη, αν και ειναι σε yes. Και ετσι ειναι και στα αλλα συστηματα που εχω, ακομα και σε αυτα που δεν τρεχουν debian!
Μηπως λοιπον εινια καποιο policy ή κατι τετοιο του systemd που μου λειπει? Το μονο σημαντικο πακετο που εβγαλα οταν εστησα το λειτουργικο στο rpi ηταν το apparmor, μαζι με τις εξαρτησεις του προφανως.

Εμένα για ρυθμιση του ssh server μου κάνει πάντως.

[jim_p]

Το βρηκα. Το libpam-systemd ηταν, που ειναι και recommended dependency στο openssh-server.

[Yiannis230]

Ευχαριστώ αλλά όχι ακόμα.
Αν σπάσει, δεν έχω καμιά όρεξη και πάλι να προσπαθήσω να κρατήσω τη σταθερή έκδοση ή να εγκαταστήσω τους οδηγούς της nvidia.
Θα περιμένω να περάσει στο testing...

Με την αναβάθμιση στη νέα έκδοση mesa 22.2.0-1 από το testing, το πρόβλημα με τα artifacts του nouveau λύθηκε.
Ευχαριστώ για τη βοήθεια

[jim_p]

Ενας λιγοτερος με nvidia 340
Εχεις τουλαχιστον καταφερει να δουλεψει το vaapi με τον nouveau?

[jim_p]

Για οποιον εχει ati τελευταιας γενιας και sid
https://old.reddit.com/r/debian/comm...6500_gpus_not/

Να εγινε κατι με την χτεσινη ενημερωση του πυρηνα σε 5.19.11?

- - - Updated - - -

Kernel 6.0(rc7) στο experimental απο σημερα, για οποιον τον τρωει το χερι του.
https://tracker.debian.org/news/1366...-experimental/

[jim_p]

Debian 12 Switches To PipeWire & WirePlumber By Default With The GNOME Desktop
https://www.phoronix.com/news/Debian-12-PipeWire

- - - Updated - - -

Επιτελους non-free fw στο κανονικο iso!
https://old.reddit.com/r/debian/comm..._gr_concluded/

Στα δικα μου τωρα. Εινια κανεις με stable και το cockpit (276) απο το backports ή εστω 276+ αν εινια σε testing/unstable? Ειπα να το βαλω χτες στο rpi που τρεχει stable και εφυγε το κομματι του απο το motd!
Κανονικα ελεγε (rpi3b ειναι το hostname)

Debian GNU/Linux 11 rpi3b tty1
Web console: https://rpi3b:9090/ or https://192.168.1.124:9090/

αλλα τωρα λεει μονο την πρωτη σειρα, που τραβαει απο το /etc/issue.
Η δευτερη σειρα, που ειναι του cockpit, ηταν απο το αρχειο /etc/motd.d/cockpit, το οποιο ηταν symlink στο /run/cockpit/motd, το οποιο με τη σειρα του ειναι symlink στο /run/cockpit/active.motd, που ειναι το πραγματικο αρχειο με το κειμενο. Τα αρχεια μεσα στο /run/cockpit υπαρχουν ακομα, το /etc/motd.d/cockpit ειναι αυτο που λειπει, μαζι με ολο το φακελο /etc/motd.d!
Να ξερω τουλαχιστον αν την πατατα την κανανε οι maintainers του debian ή εινια ετσι απο upstream.

Να πω και τον πονο μου. Ηθελα να δειχνει εκει περα αν ειμαι συνδεδεμενος στο wifi και τη θερμοκρασια του rpi, γιαυτο εκανα 2 σκριπτακια στο /etc/update-motd.d/ που κανουν τα παρακατω

# cat 20-wifi
#!/bin/sh
echo Connected on $(iwgetid -r)

# cat 30-temp
#!/bin/sh
pitemp=$(cat /sys/class/thermal/thermal_zone0/temp)
echo Temp $((pitemp/1000))C

Δουλευουν, αλλα τρεχουν αφου γινει login στο tty ή μεσω ssh, ενω τα παραπανω φαινονται ακριβως πανω απο το login prompt στο tty.

[jim_p]

Οι... παρενεργειες της αποφασης να μπει η alpha του kodi 20 στο unstable, μιας και η 19 δεν χτιζεται με ffmpeg 5 και βαριουνται να ψαξουν για patches.
https://old.reddit.com/r/debian/comm...4_on_bookworm/

Btw, η 20a3 εχει 25 μερες που βγηκε στο github και 16 μερες που ανακοινωθηκε απο τη σελιδα τους, αλλα οι dev δεν ψηνονται να ξαναπακεταρουν.

- - - Updated - - -

Τα εσβησα και τα 2 και τωρα το dmesg βγαζει μονο για το log του συστηματος

[   12.268965] systemd-journald[197]: File /var/log/journal/3e9770c9969d40f7937afbe445885d21/system.journal corrupted or uncleanly shut down, renaming and replacing.

Επισης, ο παραπανω φακελος εχει και αλλα παρομοια αρχεια. Τι να τα κανω?

# ls /var/log/journal/3e9770c9969d40f7937afbe445885d21/

σουτ τον φακελο 3e9770c9969d40f7937afbe445885d21

Παρολο που πλεον στο dmesg εχω μονο το μηνυμα που αναφερω, ο φακελος που ελεγα εχει φτασει τα 101 αρχεια, με το ~60% να ειναι user-* και το αλλο ~40% να ειναι system-*. Να τα ξανασβησω? Πως θα μπορουσα να τα σβησω ολα εκτος απο τα user-1000.journal και system.journal?

[imitheos]

Παρολο που πλεον στο dmesg εχω μονο το μηνυμα που αναφερω, ο φακελος που ελεγα εχει φτασει τα 101 αρχεια, με το ~60% να ειναι user-* και το αλλο ~40% να ειναι system-*.

SYNOPSIS
/etc/systemd/journald.conf

SystemMaxUse=, SystemMaxFiles=,
Enforce size limits on the journal files stored. The options
prefixed with "System" apply to the journal files when stored on a
persistent file system, more specifically /var/log/journal.

SystemMaxUse= control how much disk space the
journal may use up at most.

SystemMaxFiles= control how many individual
journal files to keep at most. Note that only archived files are
deleted to reduce the number of files until this limit is reached;
active files will stay around. This means that, in effect, there
might still be more journal files around in total than this limit
after a vacuuming operation is complete. This setting defaults to
100.

Ανάλογα με το τι θέλεις να κάνεις, πείραξε την αντίστοιχη μεταβλητή

Να τα ξανασβησω? Πως θα μπορουσα να τα σβησω ολα εκτος απο τα user-1000.journal και system.journal?

Το χειροκίνητο σβήσιμο είναι παρωχημένη νοοτροπία (νοοτροπία windows που έλεγε παλιά και ο wantilles).

DESCRIPTION
journalctl may be used to query the contents of the systemd(1) journal
as written by systemd-journald.service(8).

--vacuum-size=, --vacuum-time=, --vacuum-files=
Removes the oldest archived journal files until the disk space they
use falls below the specified size (specified with the usual "K",
"M", "G" and "T" suffixes), or all archived journal files contain
no data older than the specified timespan (specified with the usual
"s", "m", "h", "days", "months", "weeks" and "years" suffixes), or
no more than the specified number of separate journal files remain.
Note that running --vacuum-size= has only an indirect effect on the
output shown by --disk-usage, as the latter includes active journal
files, while the vacuuming operation only operates on archived
journal files. Similarly, --vacuum-files= might not actually reduce
the number of journal files to below the specified number, as it
will not remove active journal files.

--vacuum-size=, --vacuum-time= and --vacuum-files= may be combined
in a single invocation to enforce any combination of a size, a time
and a number of files limit on the archived journal files.
Specifying any of these three parameters as zero is equivalent to
not enforcing the specific limit, and is thus redundant.

Διαλέγεις και παίρνεις. Ανάλογα τι θέλεις να σβήσεις, βάλε την ανάλογη παράμετρο. Και επίσης το παρακάτω ορίζει αν θέλεις να κρατάει logs από κάθε boot ή να κρατάει μόνο "runtime" δηλαδή να τα βλέπεις όσο το μηχάνημα δουλεύει και κατά το reboot να χάνονται.

SYNOPSIS
/etc/systemd/journald.conf

Storage=
Controls where to store journal data. One of "volatile",
"persistent", "auto" and "none". If "volatile", journal log data
will be stored only in memory, i.e. below the /run/log/journal
hierarchy (which is created if needed). If "persistent", data will
be stored preferably on disk, i.e. below the /var/log/journal
hierarchy (which is created if needed), with a fallback to
/run/log/journal (which is created if needed), during early boot
and if the disk is not writable. "auto" behaves like "persistent"
if the /var/log/journal directory exists, and "volatile" otherwise
(the existence of the directory controls the storage mode). "none"
turns off all storage, all log data received will be dropped (but
forwarding to other targets, such as the console, the kernel log
buffer, or a syslog socket will still work). Defaults to "auto" in
the default journal namespace, and "persistent" in all others.

Note that when this option is changed to "volatile", existing
persistent data is not removed. In the other direction,
journalctl(1) with the --flush option may be used to move volatile
data to persistent storage.

Άσχετα με το τι λέμε για το systemd, έχει μια manpage για το κάθε τι και η κάθε manpage είναι 5000 γραμμές και εξηγεί κάθε λεπτομέρεια.

[jim_p]

Το πιστευεις οτι τωρα εψαχνα να βρω καποια παλια σου μηνυματα που ελεγες για το journalctl!? Τοτε λεγαμε για το ποσο καιρο θα κραταει αυτα τα logs και θυμαμαι οτι ειχα αλλαξει και το σχετικο αρχειο, αλλα καποια ενημερωση το εκανε overwrite και τωρα τα εχει ολα στοκ.

- - - Updated - - -

Αποφασισα να το κανω με μερες, αλλα ειδα εναν που τρεχει απλα

journalctl --vacuum-time=1

Οταν εκει δεν εχει γραμμα, τι υποτιθεται οτι δηλωνει? Το αντιστοιχο κομματι στο manpage λεει

       --vacuum-size=, --vacuum-time=, --vacuum-files=
           Removes the oldest archived journal files until the disk space they
           use falls below the specified size (specified with the usual "K",
           "M", "G" and "T" suffixes), or all archived journal files contain
           no data older than the specified timespan (specified with the usual
           "s", "m", "h", "days", "months", "weeks" and "years" suffixes), or
           no more than the specified number of separate journal files remain.
           Note that running --vacuum-size= has only an indirect effect on the
           output shown by --disk-usage, as the latter includes active journal
           files, while the vacuuming operation only operates on archived
           journal files. Similarly, --vacuum-files= might not actually reduce
           the number of journal files to below the specified number, as it
           will not remove active journal files.

- - - Updated - - -

Θυμαται κανεις ποια εινια η εντολη του systemd για να δω ποιο service δεν εχει ξεκινησει ακομα ή σωστα?
Εβαλα το rpi νωριτερα να δω κατι και αργουσε παλι χαρακτηριστικα! Και δεν νομιζω να ειναι απο τα σβησμενα logs, γιατι το πρωι δουλευε αψογα.

[imitheos]

Θυμαται κανεις ποια εινια η εντολη του systemd για να δω ποιο service δεν εχει ξεκινησει ακομα ή σωστα?
Εβαλα το rpi νωριτερα να δω κατι και αργουσε παλι χαρακτηριστικα! Και δεν νομιζω να ειναι απο τα σβησμενα logs, γιατι το πρωι δουλευε αψογα.

systemctl --failed για να δεις αν απέτυχε κάτι. Αν απλά αργεί κάτι, τότε systemd-analyze blame για να δεις ποια υπηρεσία άργησε.

[jim_p]

Το blame το χρησιμοποιω συχνα και το ξερω. Το αλλο τωρα λεει 0 failed.
Τωρα δουλευει καλα βεβαια, πριν εκανε πχ μισο με ενα λεπτο μεχρι να επιστρεψει το output απο ενα apt-cache search ή απο το dmesg! Θα μαθω ποιο εινια τη Δευτερα που θα αργησει το boot στο pc λογω trim.

- - - Updated - - -

Απο την ενημερωση της pam σε 1.5.2-3 στο unstable.

Unpacking libpam-modules-bin (1.5.2-3) over (1.5.2-2) ...
dpkg: error processing archive /var/cache/apt/archives/libpam-modules-bin_1.5.2-3_i386.deb (--unpack):
 trying to overwrite '/usr/share/man/man5/namespace.conf.5.gz', which is also in package libpam-modules:i386 1.5.2-2
Errors were encountered while processing:
 /var/cache/apt/archives/libpam-modules-bin_1.5.2-3_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Και το σχετικο bug report, απο ποιον αλλο, απο το Marillat!
https://bugs.debian.org/cgi-bin/bugr...gi?bug=1021336

- - - Updated - - -

Κανεις με testing/unstable και inadyn? Μετα την περσινη ενημερωση σε 2.8.1 που ηταν η μονη που πηρε το πακετο μετα απο 8 χρονια που ηταν ξεχασμενο στο repo, ο υπευθυνοτατος (νεος?) maintainer του το ξαναενημερωσε χτες στην latest εκδοση... που βγηκε πριν 10 μηνες.
3+ χρονια πριν καποιος ζητησε, μεταξυ αλλων, και ενα systemd service γιατι πλεον δεν ειμαστε στην εποχη του sysvinit. 1+ χρονο πριν ζητησα και εγω το ιδιο πραγμα, παραθετοντας το ιδιο το inadyn.service απο upstream.

Και σημερα ο τυπος ενημερωσε το πακετο στην τελευταια εκδοση, κλεινοντας και τα 2 παραπανω bug reports. Αλλα εδω δεν βλεπω inadyn.service πουθενα! Αντιθετα υπαρχει ακομα σκριπτακι στο init.d. Πως γινεται αυτο?
Επισης, δεν θυμαμαι που τσεκαρω αν το systemd παραπονιεται οτι δεν υπαρχει systemd service και ξεκιναει απο το init.d.

[jim_p]

Θυμαται κανεις ποια εινια η εντολη του systemd για να δω ποιο service δεν εχει ξεκινησει ακομα ή σωστα?

Το systemctl list-jobs ητανε τελικα, συν το systemctl status που λεει ποσα services δεν εχουν ξεκινησει σωστα ή ακομα.

- - - Updated - - -

Accepted linux 6.0-1~exp1 (source) into experimental
https://tracker.debian.org/news/1371...-experimental/