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

[imitheos]

Δεν ξέρω αν σας έκατσε και εσας, αλλά ένα update μου διάλυσε το σύστημα. Αφορά το udisks2 το οποίο γίνεται update από την έκδοση 2.9.4 στην 2.10.0. Μολις γίνεται update παραπονείται το udisks service ότι δεν μπορεί να ξεκινήσει και στη συνέχεια δεν φορτώνει ούτε desktop.... Αφου έφαγα 2-3 ώρες και ξήλωσα ένα σωρό πράγματα ένα downgrade και hold στην παλιά έκδοση λύνει όλα τα προβλήματα.

TL;DR Δεν μπορώ να ξέρω με σιγουριά τι έφταιξε στη δική σου περίπτωση αλλά υποθέτω αν εγκαταστήσεις τα libblockdev-crypto3, libblockdev-nvme3 libblockdev-mdraid2 μετά θα σου λειτουργήσει σωστά.




Μήπως σου λείπουν κάποια plugins της libblockdev (πχ το nvme που είναι νέο και δεν υπήρχε στην έκδοση 2);

# debian sid
# systemctl status udisks2.service

Ιουλ 11 09:55:00 systemd[1]: Starting udisks2.service - Disk Manager...
Ιουλ 11 09:55:00 udisksd[74]: udisks daemon version 2.10.0 starting
Ιουλ 11 09:55:00 udisksd[74]: failed to load module nvme: libbd_nvme.so.3: cannot open shared object file: No such file or directory
Ιουλ 11 09:55:00 udisksd[74]: Failed to load the 'nvme' libblockdev plugin
Ιουλ 11 09:55:00 systemd[1]: udisks2.service: Main process exited, code=dumped, status=5/TRAP
Ιουλ 11 09:55:00 systemd[1]: udisks2.service: Failed with result 'core-dump'.
Ιουλ 11 09:55:00 systemd[1]: Failed to start udisks2.service - Disk Manager.

# /usr/libexec/udisks2/udisksd

udisks-Message: 09:56:43.017: udisks daemon version 2.10.0 starting

** (udisksd:344): WARNING **: 09:56:43.023: failed to load module nvme: libbd_nvme.so.3: cannot open shared object file: No such file or directory

(udisksd:344): udisks-ERROR **: 09:56:43.023: Failed to load the 'nvme' libblockdev plugin

Δες τώρα το ίδιο πράγμα σε udisks 2.9 με libblockdev 2άρα (σε tumbleweed αλλά δεν παίζει ρόλο για το συγκεκριμένο. απλά για να μην κάνω downgrade το debian):

# systemctl status udisks2.service
Ιουλ 11 06:20:53 udisksd[1710]: udisks daemon version 2.9.4 starting
Ιουλ 11 06:20:53 udisksd[1710]: Failed to load config files: Failed to get contents of the config dir (/etc/libblockdev/conf.d/)Error opening directory “/etc/libblockdev/conf.d/”: No such file or directory. Using the built-in config
Ιουλ 11 06:20:53 udisksd[1710]: failed to load module swap: libbd_swap.so.2: cannot open shared object file: No such file or directory
Ιουλ 11 06:20:53 udisksd[1710]: failed to load module mdraid: libbd_mdraid.so.2: cannot open shared object file: No such file or directory
Ιουλ 11 06:20:53 udisksd[1710]: failed to load module part: libbd_part.so.2: cannot open shared object file: No such file or directory
Ιουλ 11 06:20:53 udisksd[1710]: Failed to load the 'part' libblockdev plugin
Ιουλ 11 06:20:53 udisksd[1710]: Failed to load the 'swap' libblockdev plugin
Ιουλ 11 06:20:53 udisksd[1710]: Failed to load the 'mdraid' libblockdev plugin
Ιουλ 11 06:20:54 systemd[1]: Started Disk Manager.
Ιουλ 11 06:20:54 udisksd[1710]: Acquired the name org.freedesktop.UDisks2 on the system message bus

Δεν βρίσκει ένα φορτηγό plugins και παρόλα αυτά τρέχει κανονικά.

Χωρίς δηλαδή να το έχω ψάξει, πιστεύω ότι η νέα έκδοση (μάλλον η 3άρα έκδοση της libblockdev φταίει και όχι η 2.10 του udisks) άλλαξε συμπεριφορά και δεν συνεχίζει την φόρτωση plugins όταν δεν βρει κάποιο (οπότε και να συνεχίσει με μειωμένη λειτουργικότητα) αλλά σταματάει εντελώς το φόρτωμα οπότε σταματάει και το udisks.

# apt info udisks2
Package: udisks2
Version: 2.10.0-2
Depends: libudisks2-0 (= 2.10.0-2), libblockdev-fs3, libblockdev-loop3, libblockdev-part3, libblockdev-swap3, dbus, parted, udev, libacl1 (>= 2.2.23), libatasmart4 (>= 0.13), libblkid1 (>= 2.16), libblockdev-utils3 (>= 3.0), libblockdev3 (>= 3.0), libc6 (>= 2.34), libglib2.0-0 (>= 2.68), libgudev-1.0-0 (>= 212), libmount1 (>= 2.30), libpolkit-agent-1-0 (>= 0.102), libpolkit-gobject-1-0 (>= 0.102), libsystemd0 (>= 209), libuuid1 (>= 2.16)
Recommends: dosfstools, e2fsprogs, eject, libblockdev-crypto3, libblockdev-nvme3, ntfs-3g, polkitd, libpam-systemd, exfatprogs
Suggests: btrfs-progs, f2fs-tools, libblockdev-mdraid2, mdadm, nilfs-tools, reiserfsprogs, udftools, udisks2-btrfs, udisks2-lvm2, xfsprogs

Βλέπεις ότι το debian δεν βάζει όλα τα plugins της libblockdev ως εξαρτήσεις. Σωστά έπρατε και έβαζε τα crypto, nvme3 ως recommended επειδή δεν τα χρειάζονται όλοι, και το mdraid2 ως suggested επειδή το χρειάζονται ακόμη λιγότεροι χρήστες. Μάλλον όμως αυτό άλλαξε στην 3άρα έκδοση και τώρα χρειάζονται να υπάρχουν όλα στο σύστημα.

# zypper info --requires udisks2

Πληροφορίες για το πακέτο udisks2:
----------------------------------
Αποθετήριο             : Κύριο Αποθετήριο (OSS)
Όνομα                  : udisks2
Έκδοση                 : 2.9.4-6.4
Προμηθευτής            : openSUSE
Απαιτεί                : [43]
    libbd_utils.so.2()(64bit)
    libblockdev-swap >= 2.19
    libblockdev >= 2.19
    libblockdev-crypto >= 2.19
    libblockdev-fs >= 2.19
    libblockdev-loop >= 2.19
    libblockdev-mdraid >= 2.19
    libblockdev-part >= 2.19

Αντίθετα το tumbleweed έκανε την εύκολη, αλλά λάθος, λύση να τα βάζει όλα ως εξαρτήσεις (και εγώ τα blockαρα και δεν τα εγκαθιστούσα για αυτό είδες να μην τα βρίσκει στο log που έδωσα παραπάνω).

[Slammer]

Το θέμα είναι ότι σπάνια έχουμε σφάλματα που καθιστούν τον υπολογιστή σχεδόν άχρηστο και αυτό ήταν ένα από αυτά. Όταν είσαι με laptop και χωρίς άλλο υπολογιστή κοντά είναι δύσκολο να το ψάξεις όταν συμβεί ακόμα και αν η λύση είναι απλή. Έφαγα κανένα δίωρο μέχρι να το λύσω... θα μου πείς βέβαια, και θα έχεις απόλυτο δίκιο, "τι κάνεις update όταν δεν είναι κατάλληλη η στιγμή, και δεν είσαι προετοιμασμένος γι αυτό;"

Τέλος πάντων, η 2.10.0-3, έβαλε όλες τις εξαρτήσεις στο πακέτο και πλέον δουλεύει κανονικά ( έβαλαν το mdadm στα suggested, αλλά το libblockdev-mdraid3 στα required, το οποίο φέρνει υποχρεωτικά το mdadm...)

Package: udisks2
Version: 2.10.0-3
Depends: libudisks2-0 (= 2.10.0-3), libblockdev-crypto3, libblockdev-fs3, libblockdev-loop3, libblockdev-mdraid3, libblockdev-nvme3, libblockdev-part3, libblockdev-swap3, dbus, parted, udev, libacl1 (>= 2.2.23), libatasmart4 (>= 0.13), libblkid1 (>= 2.16), libblockdev-utils3 (>= 3.0), libblockdev3 (>= 3.0), libc6 (>= 2.34), libglib2.0-0 (>= 2.68), libgudev-1.0-0 (>= 212), libmount1 (>= 2.30), libpolkit-agent-1-0 (>= 0.102), libpolkit-gobject-1-0 (>= 0.102), libsystemd0 (>= 209), libuuid1 (>= 2.16)
Recommends: dosfstools, e2fsprogs, eject, ntfs-3g, polkitd, libpam-systemd, exfatprogs
Suggests: btrfs-progs, f2fs-tools, mdadm, nilfs-tools, reiserfsprogs, udftools, udisks2-btrfs, udisks2-lvm2, xfsprogs

[imitheos]

Το θέμα είναι ότι σπάνια έχουμε σφάλματα που καθιστούν τον υπολογιστή σχεδόν άχρηστο και αυτό ήταν ένα από αυτά. Όταν είσαι με laptop και χωρίς άλλο υπολογιστή κοντά είναι δύσκολο να το ψάξεις όταν συμβεί ακόμα και αν η λύση είναι απλή. Έφαγα κανένα δίωρο μέχρι να το λύσω... θα μου πείς βέβαια, και θα έχεις απόλυτο δίκιο, "τι κάνεις update όταν δεν είναι κατάλληλη η στιγμή, και δεν είσαι προετοιμασμένος γι αυτό;"

Εννοείται ότι μπορεί να μην έχεις χρόνο όταν συμβεί το πρόβλημα. Αν, δε, μιλάμε για περίπτωση που δεν παίζει το desktop και είσαι σε κονσόλα με text browsers είναι ακόμη πιο δύσκολο να βρεις πληροφορίες (εδώ βέβαια μας λύνει τα χέρια να υπάρχει εγκατεστημένο ένα fluxbox, windowmaker, whatever που έχει μηδαμινές εξαρτήσεις και τρέχει χωρίς dbus / udisks / κτλ οπότε θα μπορεί να τρέξει ό,τι και να βαρέσει στο update. ίσα ίσα να υπάρχει ένα desktop για να μπορεί να τρέξει ο firefox).

Αυτό το κατεβατό που έγραψα δεν ήταν κεκαλυμμένη μομφή προς εσένα ότι έφταιγες και δεν έκανες την έρευνά σου ή κάτι τέτοιο. Απλά προσπάθησα να εξηγήσω γιατί στην μία έκδοση έπαιζε και στην άλλη όχι.

Τέλος πάντων, η 2.10.0-3, έβαλε όλες τις εξαρτήσεις στο πακέτο και πλέον δουλεύει κανονικά ( έβαλαν το mdadm στα suggested, αλλά το libblockdev-mdraid3 στα required, το οποίο φέρνει υποχρεωτικά το mdadm...)

Package: udisks2
Version: 2.10.0-3
Depends: libudisks2-0 (= 2.10.0-3), libblockdev-crypto3, libblockdev-fs3, libblockdev-loop3, libblockdev-mdraid3, libblockdev-nvme3, libblockdev-part3, libblockdev-swap3, dbus, parted, udev, libacl1 (>= 2.2.23), libatasmart4 (>= 0.13), libblkid1 (>= 2.16), libblockdev-utils3 (>= 3.0), libblockdev3 (>= 3.0), libc6 (>= 2.34), libglib2.0-0 (>= 2.68), libgudev-1.0-0 (>= 212), libmount1 (>= 2.30), libpolkit-agent-1-0 (>= 0.102), libpolkit-gobject-1-0 (>= 0.102), libsystemd0 (>= 209), libuuid1 (>= 2.16)
Recommends: dosfstools, e2fsprogs, eject, ntfs-3g, polkitd, libpam-systemd, exfatprogs
Suggests: btrfs-progs, f2fs-tools, mdadm, nilfs-tools, reiserfsprogs, udftools, udisks2-btrfs, udisks2-lvm2, xfsprogs

Σε αυτό δεν φταίει το debian που φέρνει το mdadm και τα λοιπά. Αυτό είναι βλακεία της libblockdev (ή του udisks) και δεν θα έπρεπε να γίνεται έτσι. Για αυτό δεν είναι σε μία βιβλιοθήκη και τα δίνει σαν plugins σε ξεχωριστά αρχεία γιατί δεν είναι απολύτως απαραίτητα. Δεν θα έπρεπε να χρειάζονται όλα για να τρέξει. Πολύς κόσμος δεν τα χρειάζεται και μπορούν να δημιουργήσουν προβλήματα. Εγώ τα blockαρα στο tumbleweed γιατί κάποιο plugin (ή το crypt ή το raid) οδηγούσε στο να εμφανίζεται, στο άσχετο, κάποιο παράθυρο που να ζητάει κωδικό root για να ανοίξει μια συσκευή και αν μπερδευόσουν και έβαζες τον κωδικό δημιουργούταν πρόβλημα επειδή η συσκευή ήταν ήδη ανοιχτή και χρησιμοποιούταν από το σύστημα. Μπορείς φυσικά να δημιουργήσεις κανόνες udev που να ορίζουν ότι την τάδε συσκευή θα την αγνοεί το udisks αλλά αυτό είναι ημίμετρο που δεν λύνει σωστά το πρόβλημα.

[hammered]

Για αρχη, βαλε και το avahi-daemon. Αν κανεις ping στο "domain" του εκτυπωτη, απανταει? Πχ

$ ping rpi3b.local
PING rpi3b.local (192.168.1.130) 56(84) bytes of data.
64 bytes from 192.168.1.130 (192.168.1.130): icmp_seq=1 ttl=64 time=26.2 ms
64 bytes from 192.168.1.130 (192.168.1.130): icmp_seq=2 ttl=64 time=9.27 ms
64 bytes from 192.168.1.130 (192.168.1.130): icmp_seq=3 ttl=64 time=7.84 ms
64 bytes from 192.168.1.130 (192.168.1.130): icmp_seq=4 ttl=64 time=6.82 ms

--- rpi3b.local ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 6.822/12.533/26.197/7.936 ms

Sorry για την αργορπορία. Τελικά το έλυσα.
Short story
Εγκατάσταση του systemd-resolved

Long story
To "ping hostname.local" έκανε fail με μήνυμα "Name or service not known". Ενώ γινόταν resolved μέσω του avahi-daemon.
Διάβασα και ξαναδιάβασα άρθρα για το πως κάνεις σωστά setup το mdns. Σε μένα ήταν ήδη σωστά. Αλλά σε ένα random comment σε ένα από τα άρθρο έγραφε ένας χρήστης κάτι του τύπου "(συγγραφέα) αυτά που γράφεις δεν ισχύουν πλέον στις σύγχρονες διανομές. Το avahi-daemon είναι deprecated από το systemd-resolved και αν δεν έχεις εγκαταστήσει το systemd-resolved το mdns δεν θα δουλεύει".

Δεν ξέρω αν πρέπει να τα έχω και τα 2 εγκατεστημένα ή θα υπάρχει conflict, αλλά τώρα το mdns μου δουλεύει κανονικά.

[jim_p]

Οποτε να πεταξω το avahi και να βαλω το systemd-resolved? Θελω ομως το συστημα να χρησιμοποιει το /etc/resolv.conf για τους dns.

Μιας και ειπαμε για systemd, με τη σημερινη αναβαθμηση σε systemd 253.x, το apt εβαλε και το systemd-dev. Γιατι?

The following NEW packages will be installed:
  systemd-dev
The following packages will be upgraded:
  libpam-systemd libsystemd-shared libsystemd0 libudev1 systemd
  systemd-timesyncd udev

- - - Updated - - -

Χρησιμοποιει κανεις aapt να μου πει αν εχει αυτο το προβλημα?

$ aapt list -a Desktop/Geddit_v1.0.apk | grep SdkVersion
aapt: symbol lookup error: /usr/lib/x86_64-linux-gnu/android/libandroidfw.so.0: undefined symbol: _Z18ExtractEntryToFileP10ZipArchiveP8ZipEntryi

Εννοειται πως η βιβλιοθηκη υπαρχει ηδη στο συγκεκριμενο path και το πακετο που τη φερνει ειναι εγκατεστημενο σαν direct εξαρτηση του aapt.

[Yiannis230]

Κώδικας:

The following NEW packages will be installed:
systemd-dev
The following packages will be upgraded:
libpam-systemd libsystemd-shared libsystemd0 libudev1 systemd
systemd-timesyncd udev

Στο Debian 12 το πακέτο ntp έχει αντικατασταθεί από το πακέτο ntpsec
Το timedatectl status δίνει: System clock synchronized: yes
Σε προσπάθεια εγκατάστασης και του systemd-timesyncd ζητά την απομάκρυση του ntpsec άρα συγχρονίζει και δεν το χρειάζεται!

[jim_p]

Δεν σε πιανω
Το systemd-timesyncd το εχω εδω και 1+ χρονο σιγουρα. Το systemd-dev μπηκε σημερα σαν direct εξαρτηση του udev και του systemd.

[Yiannis230]

Δεν σε πιανω
Το systemd-timesyncd το εχω εδω και 1+ χρονο σιγουρα. Το systemd-dev μπηκε σημερα σαν direct εξαρτηση του udev και του systemd.

Συγνώμη αλλά δεν αναφέρομαι στο systemd-dev, δεν ξέρω γιατί μπήκε σαν εξάρτηση. Ρωτάω αν χρειάζεται το systemd-timesyncd όταν υπάρχει στο σύστημα το ntpsec και φαίνεται να συγχρονίζει?

[jim_p]

Απο ntpsec εχω τα ntpsec-ntpdate και ntpsec-ntpdig. Το πρωτο το εχω για να τρεχω ntpdate οταν το ρολοϊ μου εινια πισω και δεν ξερω ποια ειναι η αντιστοιχη εντολη για το systemd-timesyncd. Το αλλο εινια εξαρτηση του πρωτου.

[Yiannis230]

Το ntpsec-ntpdate χρειάζεται μόνο σε μηχανήματα που δεν έχουν συνεχόμενη πρόσβαση σε δίκτυο (πχ laptops) για περιστασιακή ρύθμιση της ώρας. Όταν συνδέονται μετά από λίγο συγχρονίζει μόνο με το ntpsec και χωρίς το systemd-timesyncd

[jim_p]

Να το θεσω αλλιως τοτε. Τι κανω αν εχω μονο systemd-timesyncd και μετα απο διακοπη ρευματος η ωρα μου ειναι πισω επειδη η μπαταρια του bios εχει εξασθενησει? Αυτη τη στιγμη παραταω την ωρα οπως ειναι, γκρινιαζει το λειτουργικο για το filesystem που εγινε mounted στο μελλον, κανει fsck, μπαινει κανονικα, τρεχω ntpdate-debian (συγχρονισμος με καποιους ntp servers της διανομης) και τελος hwclock -w για να το γραψει στο bios.

[Yiannis230]

Αν το χρειάζεστε καλά κάνετε και το χρησιμοποιείτε, άλλωστε για αυτό υπάρχουν οι επιλογές.
Το ερώτημα όμως παραμένει, για το συγχρονισμό θα πρέπει να χρησιμοποιούμε το προτεινόμενο από τη διανομή πακέτο ntpsec ή το systemd-timesyncd (το ntpsec-ntpdate εγκαθίσταται και στα δυο).

[jim_p]

Επειδη μου ετυχε πριν λιγο αυτο με την ωρα, ποσταρω για να ακουσω καμια ιδεα.
Κοπηκε το ρευμα, χαθηκε η ωρα απο το bios και τερμα. Στην επομενη εκκινηση, το λινουξ ειχε τη σωστη ωρα, προφανως επειδη ετρεξε το systemd-timesyncd και τη συγχρονισε κατα την εκκινηση, οποτε σελιδες κλπ που εχουν https δουλεψανε ρολοϊ. Μετα μπηκα στα windows, ανοιξα το adslgr και βγηκε η ειδοποιηση πως το ρολοϊ μου παει πισω! Οποτε ξαναμπηκα στο λινουξ, ετρεξα ενα hwclock -w να γραφτει η ωρα στο ρολοϊ του bios και τερμα.

Θα μπορουσα να κανω το ιδιο με το systemd-timesyncd ωστε να μην τρεχω hwclock -w? Αν οχι, αν βαλω το hwclock -w στο /etc/rc.local θα εχει προλαβει το systemd-timesyncd να συγχρονισει την ωρα μεχρι να τρεξει το rc.local?

[imitheos]

Επειδη μου ετυχε πριν λιγο αυτο με την ωρα, ποσταρω για να ακουσω καμια ιδεα.
Κοπηκε το ρευμα, χαθηκε η ωρα απο το bios και τερμα. Στην επομενη εκκινηση, το λινουξ ειχε τη σωστη ωρα, προφανως επειδη ετρεξε το systemd-timesyncd και τη συγχρονισε κατα την εκκινηση, οποτε σελιδες κλπ που εχουν https δουλεψανε ρολοϊ. Μετα μπηκα στα windows, ανοιξα το adslgr και βγηκε η ειδοποιηση πως το ρολοϊ μου παει πισω! Οποτε ξαναμπηκα στο λινουξ, ετρεξα ενα hwclock -w να γραφτει η ωρα στο ρολοϊ του bios και τερμα.

Θα μπορουσα να κανω το ιδιο με το systemd-timesyncd ωστε να μην τρεχω hwclock -w? Αν οχι, αν βαλω το hwclock -w στο /etc/rc.local θα εχει προλαβει το systemd-timesyncd να συγχρονισει την ωρα μεχρι να τρεξει το rc.local?

Δεν παίζει να μπεις στο bios και να ορίσεις ώρα αντί να κάνεις όλα αυτά; Παρεμπιπτόντως, μπορεί η διακοπή ρεύματος να χάσει την ώρα του bios; Για αυτό δεν είναι η μπαταρία;

[dpap76]

Επειδη μου ετυχε πριν λιγο αυτο με την ωρα, ποσταρω για να ακουσω καμια ιδεα.
Κοπηκε το ρευμα, χαθηκε η ωρα απο το bios και τερμα. Στην επομενη εκκινηση, το λινουξ ειχε τη σωστη ωρα, προφανως επειδη ετρεξε το systemd-timesyncd και τη συγχρονισε κατα την εκκινηση, οποτε σελιδες κλπ που εχουν https δουλεψανε ρολοϊ. Μετα μπηκα στα windows, ανοιξα το adslgr και βγηκε η ειδοποιηση πως το ρολοϊ μου παει πισω! Οποτε ξαναμπηκα στο λινουξ, ετρεξα ενα hwclock -w να γραφτει η ωρα στο ρολοϊ του bios και τερμα.

To kernel σώζει την ώρα στο RTC clock κάθε 11 λεπτά. Περίμενες 11 λεπτά μεταξύ των reboot?

Αν πάντως θέλεις να βάλεις κάποιο command όταν κανει shutdown/reboot/halt/poweroff, σίγουρα δεν το βάζεις στο rc.local [και γενικά εν ετη 2023 δεν παίζουμε πλέον με το rc.local] (και οχι, πιθανότατα δεν θα έχει προλάβει το ntp να συγχρονίσει την ώρα όταν τρέξει το legacy rc.local)

Κάποιο systemd service σαν αυτό θα κάνει την δουλειά μάλλον

[Unit]
Description=Save system clock on shutdown
DefaultDependencies=no
After=final.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/hwclock -w

[Install]
WantedBy=final.target