[SAMMELTHREAD] Linux Kurze-Frage-Kurze-Antwort (KFKA)

@Biji-san: sobald die Versorgungsspannung weg ist, hat es sich erledigt mit "Warten".

Ich denke aber auch, daß die Hersteller versuchen mit einer Kombination von "Schreibcache aus" und Pufferkondensatoren das Risiko zu verringern. Wahrscheinlich geht FAT32 sowieso früher oder später kaputt ...
 
Biji-san schrieb:
Dateisysteme ohne Journaling:
  • FAT32
  • ext
  • ext2

Dateisysteme mit Journaling:
  • NTFS
  • ext3
  • ext4

Dateisysteme mit Journaling und Prüfsummen für Datenblöcke:
  • ZFS
  • Btrfs
Zum Vergrößern anklicken....
Bei der AVM Fritzbox wird wohl eher ein Flash-Filesystem with jffs2, logfs, ubifs oder yaffs zum Einsatz kommen.
 
Ich habe selber mal ein Gerät entwickelt (als ich noch kleine Elektronik-Applikationen entwickelt habe), welches auf einen USB-Stick schreibt. Das USB-Modul (irgendein Vinculum-Device) wurde dabei von einem Mikrocontroller (Atmel AVR) angesteuert. Dort habe ich das ganze so gelöst:
Die Versorgungsspannung wurde über einen Elko gepuffert, welcher so dimensioniert war das im schlimmsten Fall (=maximale Stromaufnahme + Sicherheit) etwa 50 ms Zeit bleiben, bevor der Brown-Out (Unterspannungsabschaltung des Prozessors) einsetzt. Der Mikrocontroller hat über einen A/D-Wandler ständig die Versorgungsspannung am Netzteileingang gemessen, um einen plötzlichen Spannungsabfall zu erkennen. Wurde ein solcher Spannungsabfall (Stecker gezogen) erkannt, brach die gerade laufende Funktion über einen Interrupt ab und das USB-Device wurde sorgfältig in Ruhe versetzt. Bei meinen Tests war die Sache eigentlich immer in 20ms gegessen, die restlichen 30ms wartete der Controller dann nur noch bis zum endgültigen "aus".

Ein solches Vorgehen gehört zu den Grundzügen in der Entwicklung von Anwendungen mit Mikrocontrollern, genauso wie die sichere Verwendung des Watchdogs (ein Timer, der im Fehlerfall nicht zurückgesetzt wird läuft ab und resettet das Programm).
 
Code: 
(1/1) Aktualisiere pipelight                                                    [#############################################] 100%
--2014-12-13 12:38:24--  https://bitbucket.org/mmueller2012/pipelight/raw/master/share/install-dependency-1434FC73.sig
Auflösen des Hostnamen »bitbucket.org (bitbucket.org)«... 131.103.20.168, 131.103.20.167
Verbindungsaufbau zu bitbucket.org (bitbucket.org)|131.103.20.168|:443... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 28862 (28K) [text/plain]
In »»/tmp/tmp.XyScMmXK4L«« speichern.

     0K .......... .......... ........                        100% 4,03M=0,007s

2014-12-13 12:38:25 (4,03 MB/s) - »»/tmp/tmp.XyScMmXK4L«« gespeichert [28862/28862]

gpg: Signatur vom Mi 10 Dez 2014 01:31:04 CET mittels RSA-Schlüssel ID 1434FC73
gpg: Korrekte Signatur von "Pipelight Dev Team (install-dependency) <webmaster@fds-team.de>" [unbekannt]
gpg: WARNUNG: Dieser Schlüssel trägt keine vertrauenswürdige Signatur!
gpg:          Es gibt keinen Hinweis, daß die Signatur wirklich dem vorgeblichen Besitzer gehört.
Haupt-Fingerabdruck  = CF23 08D4 3507 9A77 124E  01A2 83C7 3FB2 1434 FC73

Script dependency-installer is already up-to-date.
 local database is up to date

Muss ich mir Gedanken machen? Oder was soll die fehlerhafte Signatur?
 
Wenn ich das richtig sehe, verwendet "Ted" schon die fertig kompilierte Version via pacman. Das wollte ich mir auch mal anschauen, um nicht jedes mal selbst kompilieren zu müssen. Bisher kompiliere ich aber noch selbst, nachdem ich sie via packer gezogen habe.
Inwiefern das eine Rolle spielt, wer kompiliert, weiß ich nicht. Die Anleitungen sagen explizit nur für das bereits kompilierte, dass ich dem Schlüsselbund einen Schlüssel hinzufügen soll.

Bei Erstinstallation gab es keine solche Warnung, und das hier war auch meine erste Aktualisierung von pipelight.
 
Bei Erstinstallation gab es keine solche Warnung, und das hier war auch meine erste Aktualisierung von pipelight.
Zum Vergrößern anklicken....

Das ist richtig, aber hier geht es doch sicher um die GPG-Signatur der Download-Quelle:

'https://bitbucket.org/mmueller2012/pipelight/raw/master/share/install-dependency-1434FC73.sig'

Das träfe m.E. auf den Quelltext genauso zu wie auf das fertige Paket, denn am Ende erstellst Du Dir doch auch erst ein Paket oder installierst Du direkt?
 
Ich weiß nicht, in welchem Kontext die Meldung kommst, aber du hast hoffentlich die Schritte zur GPG Umstellung auf der Arch Webseite befolgt.
 
Jup, hab ich.

Code: 
[root@t440s sun]# rm -fr /etc/pacman.d/gnupg
Code: 
[root@t440s sun]# pacman-key --init
gpg: /etc/pacman.d/gnupg/trustdb.gpg: trust-db erzeugt
gpg: keine uneingeschränkt vertrauenswürdigen Schlüssel gefunden
gpg: starting migration from earlier GnuPG versions
gpg: porting secret keys from '/etc/pacman.d/gnupg/secring.gpg' to gpg-agent
gpg: migration succeeded
gpg: Generating pacman keyring master key...
gpg: Schlüssel D1C98B8D ist als uneingeschränkt vertrauenswürdig gekennzeichnet
gpg: Verzeichnis `/etc/pacman.d/gnupg/openpgp-revocs.d' erzeugt
gpg: Done
==> Aktualisiere Trust-Datenbank ...
gpg: 3 marginal-needed, 1 complete-needed, PGP Vertrauensmodell
gpg: Tiefe: 0  gültig:   1  signiert:   0  Vertrauen: 0-, 0q, 0n, 0m, 0f, 1u
Code: 
[root@t440s sun]# pacman-key --populate archlinux
==> Füge Schlüssel aus archlinux.gpg hinzu ...
gpg: 3 marginal-needed, 1 complete-needed, PGP Vertrauensmodell
gpg: Tiefe: 0  gültig:   1  signiert:   0  Vertrauen: 0-, 0q, 0n, 0m, 0f, 1u
==> Signiere die vertrauenswürdigen Schlüssel im Schlüsselbund lokal ...
  -> Signiere Schlüssel 0E8B644079F599DFC1DDC3973348882F6AC6A4C2 lokal ...
  -> Signiere Schlüssel 684148BB25B49E986A4944C55184252D824B18E8 lokal ...
  -> Signiere Schlüssel 44D4A033AC140143927397D47EFD567D4C7EA887 lokal ...
  -> Signiere Schlüssel 27FFC4769E19F096D41D9265A04F9397CDFD6BB0 lokal ...
  -> Signiere Schlüssel AB19265E5D7D20687D303246BA1DFB64FFF979E7 lokal ...
==> Importiere die Vertrauenswerte des Benutzers ...
gpg: inserting ownertrust of 4
gpg: setting ownertrust to 4
gpg: setting ownertrust to 4
gpg: setting ownertrust to 4
gpg: setting ownertrust to 4
==> Mache widerrufene Schlüssel im Schlüsselbund unbrauchbar ...
  -> Mache Schlüssel F5A361A3A13554B85E57DDDAAF7EF7873CFD4BB6 unbrauchbar ...
  -> Mache Schlüssel 7FA647CD89891DEDC060287BB9113D1ED21E1A55 unbrauchbar ...
  -> Mache Schlüssel D4DE5ABDE2A7287644EAC7E36D1A9E70E19DAA50 unbrauchbar ...
  -> Mache Schlüssel BC1FBE4D2826A0B51E47ED62E2539214C6C11350 unbrauchbar ...
  -> Mache Schlüssel 4A8B17E20B88ACA61860009B5CED81B7C2E5C0D2 unbrauchbar ...
  -> Mache Schlüssel 63F395DE2D6398BBE458F281F2DBB4931985A992 unbrauchbar ...
  -> Mache Schlüssel 0B20CA1931F5DA3A70D0F8D2EA6836E1AB441196 unbrauchbar ...
  -> Mache Schlüssel 8F76BEEA0289F9E1D3E229C05F946DED983D4366 unbrauchbar ...
  -> Mache Schlüssel 66BD74A036D522F51DD70A3C7F2A16726521E06D unbrauchbar ...
  -> Mache Schlüssel 81D7F8241DB38BC759C80FCE3A726C6170E80477 unbrauchbar ...
  -> Mache Schlüssel E7210A59715F6940CF9A4E36A001876699AD6E84 unbrauchbar ...
==> Aktualisiere Trust-Datenbank ...
gpg: 3 marginal-needed, 1 complete-needed, PGP Vertrauensmodell
gpg: Tiefe: 0  gültig:   1  signiert:   5  Vertrauen: 0-, 0q, 0n, 0m, 0f, 1u
gpg: Tiefe: 1  gültig:   5  signiert:  61  Vertrauen: 0-, 0q, 0n, 5m, 0f, 0u
gpg: Tiefe: 2  gültig:  60  signiert:   4  Vertrauen: 60-, 0q, 0n, 0m, 0f, 0u
gpg: nächste "Trust-DB"-Pflichtüberprüfung am 2015-03-31

Code: 
[root@t440s sun]# systemctl status haveged.service 
● haveged.service - Entropy Harvesting Daemon
   Loaded: loaded (/usr/lib/systemd/system/haveged.service; enabled)
   Active: active (running) since Sa 2014-12-13 16:17:57 CET; 17min ago
     Docs: man:haveged(8)
  Process: 430 ExecStart=/usr/bin/haveged -w 1024 -v 1 (code=exited, status=0/SUCCESS)
 Main PID: 434 (haveged)
   CGroup: /system.slice/haveged.service
           └─434 /usr/bin/haveged -w 1024 -v 1

Dez 13 16:17:57 t440s haveged[430]: haveged starting up
Dez 13 16:17:57 t440s systemd[1]: Started Entropy Harvesting Daemon.
Dez 13 16:17:57 t440s haveged[434]: haveged: ver: 1.9.1; arch: x86; vend: GenuineIntel; build: (gcc 4.8.2 ITV); collect: 128K
Dez 13 16:17:57 t440s haveged[434]: haveged: cpu: (L4 VC); data: 32K (L4 V); inst: 32K (L4 V); idx: 21/40; sz: 32709/60538
Dez 13 16:17:57 t440s haveged[434]: haveged: tot tests(BA8): A:1/1 B:1/1 continuous tests(B):  last entropy estimate 7.9945
Dez 13 16:17:57 t440s haveged[434]: haveged: fills: 0, generated: 0

Ich installiere Variante 1
http://pipelight.net/cms/install/installation-arch-linux.html

Code: 
[root@t440s sun]# pacman-key -r E49CC0415DC2D5CA
gpg: Schlüssel 5DC2D5CA: Öffentlicher Schlüssel "Pipelight Dev Team (Package Builder) <webmaster@fds-team.de>" importiert
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg:                              importiert: 1
==> Aktualisiere Trust-Datenbank ...
gpg: nächste "Trust-DB"-Pflichtüberprüfung am 2015-03-31
Code: 
[root@t440s sun]# pacman-key --lsign-key E49CC0415DC2D5CA
  -> Signiere Schlüssel E49CC0415DC2D5CA lokal ...
==> Aktualisiere Trust-Datenbank ...
gpg: 3 marginal-needed, 1 complete-needed, PGP Vertrauensmodell
gpg: Tiefe: 0  gültig:   1  signiert:   6  Vertrauen: 0-, 0q, 0n, 0m, 0f, 1u
gpg: Tiefe: 1  gültig:   6  signiert:  61  Vertrauen: 1-, 0q, 0n, 5m, 0f, 0u
gpg: Tiefe: 2  gültig:  60  signiert:   4  Vertrauen: 60-, 0q, 0n, 0m, 0f, 0u
gpg: nächste "Trust-DB"-Pflichtüberprüfung am 2015-03-31
Code: 
[root@t440s sun]# pipelight-plugin --update
--2014-12-13 16:34:51--  https://bitbucket.org/mmueller2012/pipelight/raw/master/share/install-dependency-1434FC73.sig
Auflösen des Hostnamen »bitbucket.org (bitbucket.org)«... 131.103.20.168, 131.103.20.167
Verbindungsaufbau zu bitbucket.org (bitbucket.org)|131.103.20.168|:443... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 28862 (28K) [text/plain]
In »»/tmp/tmp.gC6OY9uJ9N«« speichern.

/tmp/tmp.gC6OY9uJ9N              100%[============================================================>]  28,19K  --.-KB/s   in 0,003s 

2014-12-13 16:34:52 (8,80 MB/s) - »»/tmp/tmp.gC6OY9uJ9N«« gespeichert [28862/28862]

gpg: Signatur vom Mi 10 Dez 2014 01:31:04 CET mittels RSA-Schlüssel ID 1434FC73
gpg: Korrekte Signatur von "Pipelight Dev Team (install-dependency) <webmaster@fds-team.de>" [unbekannt]
gpg: WARNUNG: Dieser Schlüssel trägt keine vertrauenswürdige Signatur!
gpg:          Es gibt keinen Hinweis, daß die Signatur wirklich dem vorgeblichen Besitzer gehört.
Haupt-Fingerabdruck  = CF23 08D4 3507 9A77 124E  01A2 83C7 3FB2 1434 FC73

Script dependency-installer is already up-to-date.

Ich bin mir nicht ganz sicher, aber es müsste das hier sein, oder?
https://bugs.launchpad.net/pipelight/+bug/1371201

gpg: Good signature from "Pipelight Dev Team <email address hidden>"
Zum Vergrößern anklicken....
Mich irritiert jedoch, dass bei mir [unbekannt] steht...
gpg: Korrekte Signatur von "Pipelight Dev Team (install-dependency) <webmaster@fds-team.de>" [unbekannt]
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
[QUOTEIch bin mir nicht ganz sicher, aber es müsste das hier sein, oder?][/QUOTE]

Ich denke auch, dass hier einfach die Signaturprüfung zickt, aus welchem Grund auch immer. Vielleicht schreibst Du im pipelight-Blog gleich direkt den Entwickler an mit dem Fehlertext, da dürfte recht schnell eine Antwort kommen.
Oder Du nutzt doch das Repo direkt statt selbst zu kompilieren.
 
Ne Frage zu den Ebenen, also nun mal bei Mint 17. Auch oder vor allem die 4 und 5 mit ausführen lassen, sollen ja eben Sicherheitsupdates für Kernel etc. sein?
 
Wie liest man unter Linux aus, wieviel RAMriegel im System stecken und wie groß die einzelnen sind?

€dit:
Debian derivat
 
lithograf schrieb:
Wie liest man unter Linux aus, wieviel RAMriegel im System stecken und wie groß die einzelnen sind?
Zum Vergrößern anklicken....

Beispiel für ein T60 mit insgesamt 3GB RAM bestückt:

Code: 
[root]~ # dmidecode -t 6
# dmidecode 2.12
SMBIOS 2.4 present.

Handle 0x0008, DMI type 6, 12 bytes
Memory Module Information
        Socket Designation: DIMM Slot 1
        Bank Connections: 0 3
        Current Speed: Unknown
        Type: DIMM SDRAM
        Installed Size: 2048 MB (Double-bank Connection)
        Enabled Size: 2048 MB (Double-bank Connection)
        Error Status: OK

Handle 0x0009, DMI type 6, 12 bytes
Memory Module Information
        Socket Designation: DIMM Slot 2
        Bank Connections: 4 7
        Current Speed: Unknown
        Type: DIMM SDRAM
        Installed Size: 1024 MB (Double-bank Connection)
        Enabled Size: 1024 MB (Double-bank Connection)
        Error Status: OK
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben