optimq
Anmeldungsdatum: 7. Dezember 2009
Beiträge: 1409
|
Hallo zusammen! Ich habe jetzt direkt keine Probleme. Aber mir ist etwas aufgefallen im Zusammenhang mit Systeminformationen ermitteln in Verbindung mit der verwendeten Kernel-Version. Lauten die im Link genannten Befehle bei Verwendung von Kernel 4.*.* anders? Gegebenenfalls, Wie? Anschließend Beispiele um zu Vergleichen. #Kernel 4.0.4
~$ sudo dmidecode -t0 -t1
# dmidecode 2.12
/dev/mem: No such file or directory
~$ sudo lshw -C system
x-pc
Beschreibung: Computer
Breite: 64 bits
Fähigkeiten: vsyscall32
~$ ~$ sudo dmidecode | grep -A3 'BIOS Information'
/dev/mem: No such file or directory
~$ sudo dmidecode | grep -A3 'BIOS Information'
/dev/mem: No such file or directory
~$ #Kernel 3.19.0-18
~$ sudo dmidecode -t0 -t1
# dmidecode 2.12
SMBIOS 2.7 present.
Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: American Megatrends Inc.
Version: F9
Release Date: 09/19/2012
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 8192 kB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 4.6
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: To be filled by O.E.M.
Version: To be filled by O.E.M.
Serial Number: To be filled by O.E.M.
UUID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Wake-up Type: Power Switch
SKU Number: To be filled by O.E.M.
Family: To be filled by O.E.M.
~$ sudo lshw -C system
x-pc
Beschreibung: Arbeitsplatzrechner
Produkt: To be filled by O.E.M. (To be filled by O.E.M.)
Hersteller: Gigabyte Technology Co., Ltd.
Version: To be filled by O.E.M.
Seriennummer: To be filled by O.E.M.
Breite: 64 bits
Fähigkeiten: smbios-2.7 dmi-2.7 vsyscall32
Konfiguration: boot=normal chassis=desktop family=To be filled by O.E.M. sku=To be filled by O.E.M. uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
~$ sudo dmidecode | grep -A3 'BIOS Information'
BIOS Information
Vendor: American Megatrends Inc.
Version: F9
Release Date: 09/19/2012
~$
Danke! Gruß Andi
|
verdooft
Anmeldungsdatum: 15. September 2012
Beiträge: 3991
|
Wundert mich, weil laut: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=73f0718e74e25ac7381450a7a21257b8f26f43f0
Option defaults to /dev/mem enabled
Hast du den Kernel selbst konfiguriert/kompiliert, also "/dev/mem virtual device support" disabled? Da wird auch Y empfohlen: +config DEVMEM
+ bool "/dev/mem virtual device support"
+ default y
+ help
+ Say Y here if you want to support the /dev/mem device.
+ The /dev/mem device is used to access areas of physical
+ memory.
+ When in doubt, say "Y". dmidecode brauchts anscheinend enabled, aus der Manpage:
-d, --dev-mem FILE
Read memory from device FILE (default: /dev/mem)
|
optimq
(Themenstarter)
Anmeldungsdatum: 7. Dezember 2009
Beiträge: 1409
|
verdooft schrieb:
Hast du den Kernel selbst konfiguriert/kompiliert, also "/dev/mem virtual device support" disabled?
Hallo verdooft! Nein, ich habe die Module linux-headers-*-generic_*_amd64.deb, linux-headers-*_*_all.deb und linux-image-*-generic_*_amd64.deb nach dem Download von http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.0.4-wily/ und nach dem Wechsel in den entsprechenden Ordner nur mit sudo dpkg -i *.deb einfach installiert. Mein Rechner läuft gerade mit Kernel 4.0.4. . /dev/mem gibt es unter Verwendung dieses Kernels bei mir nicht. Gestartet mit Kernel 3.19.0-18 müsste es diesen Ordner ja dann vermutlich wieder geben. Ich weiß aktuell nicht, wie es mit dem Kernel 3.19.0-18 aussehen würde. Aber die weiteren Dateien in /dev haben alle ein ?-Zeichen im Papierblatt-Symbol. ~$ ls -m /dev
autofs, block, bsg, btrfs-control, bus, cdrom, char, console, core,
cpu, cpu_dma_latency, cuse, disk, dm-0, dm-1, dm-2, dri, ecryptfs, fd,
full, fuse, hidraw0, hpet, hwrng, i2c-0, i2c-1, i2c-2, i2c-3, i2c-4,
i2c-5, i2c-6, input, kmsg, kubuntu-vg, log, loop0, loop1, loop2,
loop3, loop4, loop5, loop6, loop7, loop-control, mapper, mcelog, mei0,
memory_bandwidth, net, network_latency, network_throughput, null,
nvidia0, nvidiactl, port, ppp, psaux, ptmx, pts, ram0, ram1, ram10,
ram11, ram12, ram13, ram14, ram15, ram2, ram3, ram4, ram5, ram6, ram7,
ram8, ram9, random, rfkill, rtc, rtc0, sda, sda1, sda2, sda5, sdb,
sg0, sg1, sg2, shm, snapshot, snd, sr0, stderr, stdin, stdout, tty,
tty0, tty1, tty10, tty11, tty12, tty13, tty14, tty15, tty16, tty17,
tty18, tty19, tty2, tty20, tty21, tty22, tty23, tty24, tty25, tty26,
tty27, tty28, tty29, tty3, tty30, tty31, tty32, tty33, tty34, tty35,
tty36, tty37, tty38, tty39, tty4, tty40, tty41, tty42, tty43, tty44,
tty45, tty46, tty47, tty48, tty49, tty5, tty50, tty51, tty52, tty53,
tty54, tty55, tty56, tty57, tty58, tty59, tty6, tty60, tty61, tty62,
tty63, tty7, tty8, tty9, ttyprintk, ttyS0, ttyS1, ttyS10, ttyS11,
ttyS12, ttyS13, ttyS14, ttyS15, ttyS16, ttyS17, ttyS18, ttyS19, ttyS2,
ttyS20, ttyS21, ttyS22, ttyS23, ttyS24, ttyS25, ttyS26, ttyS27,
ttyS28, ttyS29, ttyS3, ttyS30, ttyS31, ttyS4, ttyS5, ttyS6, ttyS7,
ttyS8, ttyS9, uhid, uinput, urandom, vcs, vcs1, vcs2, vcs3, vcs4,
vcs5, vcs6, vcs7, vcsa, vcsa1, vcsa2, vcsa3, vcsa4, vcsa5, vcsa6,
vcsa7, vfio, vga_arbiter, vhci, vhost-net, zero
~$
Gruß Andi
|
optimq
(Themenstarter)
Anmeldungsdatum: 7. Dezember 2009
Beiträge: 1409
|
Mit Kernel 3.19.0-18 ~$ ls -m /dev
autofs, block, bsg, btrfs-control, bus, cdrom, char, console, core,
cpu, cpu_dma_latency, cuse, disk, dm-0, dm-1, dm-2, dri, ecryptfs, fd,
full, fuse, hidraw0, hpet, i2c-0, i2c-1, i2c-2, i2c-3, i2c-4, i2c-5,
i2c-6, input, kmsg, kubuntu-vg, log, loop0, loop1, loop2, loop3,
loop4, loop5, loop6, loop7, loop-control, mapper, mcelog, mei0, mem,
memory_bandwidth, net, network_latency, network_throughput, null,
nvidia0, nvidiactl, port, ppp, psaux, ptmx, pts, ram0, ram1, ram10,
ram11, ram12, ram13, ram14, ram15, ram2, ram3, ram4, ram5, ram6, ram7,
ram8, ram9, random, rfkill, rtc, rtc0, sda, sda1, sda2, sda5, sdb,
sg0, sg1, sg2, shm, snapshot, snd, sr0, stderr, stdin, stdout, tty,
tty0, tty1, tty10, tty11, tty12, tty13, tty14, tty15, tty16, tty17,
tty18, tty19, tty2, tty20, tty21, tty22, tty23, tty24, tty25, tty26,
tty27, tty28, tty29, tty3, tty30, tty31, tty32, tty33, tty34, tty35,
tty36, tty37, tty38, tty39, tty4, tty40, tty41, tty42, tty43, tty44,
tty45, tty46, tty47, tty48, tty49, tty5, tty50, tty51, tty52, tty53,
tty54, tty55, tty56, tty57, tty58, tty59, tty6, tty60, tty61, tty62,
tty63, tty7, tty8, tty9, ttyprintk, ttyS0, ttyS1, ttyS10, ttyS11,
ttyS12, ttyS13, ttyS14, ttyS15, ttyS16, ttyS17, ttyS18, ttyS19, ttyS2,
ttyS20, ttyS21, ttyS22, ttyS23, ttyS24, ttyS25, ttyS26, ttyS27,
ttyS28, ttyS29, ttyS3, ttyS30, ttyS31, ttyS4, ttyS5, ttyS6, ttyS7,
ttyS8, ttyS9, uhid, uinput, urandom, vcs, vcs1, vcs2, vcs3, vcs4,
vcs5, vcs6, vcs7, vcsa, vcsa1, vcsa2, vcsa3, vcsa4, vcsa5, vcsa6,
vcsa7, vfio, vga_arbiter, vhci, vhost-net, zero
~$
Die ?-Zeichen in den Dateisymbolen gibt es hier allerdings auch. Gruß Andi
|
verdooft
Anmeldungsdatum: 15. September 2012
Beiträge: 3991
|
In der Datei config-4.0.4-040004-generic steht # CONFIG_DEVMEM is not set
In der Patchdatei 0003-configs-based-on-Ubuntu-4.0.2-1.1 steht auch:
+# CONFIG_DEVMEM is not set Interpretiere ich eigentlich so, dass der Standardwert, also Y verwendet wird. Anderseits steht in der Configdatei nirgends "xyz=n". is not set = n? Fazit: Die Ubuntukernelkonfig ist schuld.
This is the case until v4.0-rc2-vivid[3] where the patch is updated to turn DEVMEM off. I can't however find any reason for doing so or a mention in the change logs.
https://lwn.net/Articles/643960/
|
optimq
(Themenstarter)
Anmeldungsdatum: 7. Dezember 2009
Beiträge: 1409
|
verdooft, Danke für Deine Hinweise! Für mich als *buntu-Trottel klingt In der Patchdatei 0003-configs-based-on-Ubuntu-4.0.2-1.1 steht auch: +# CONFIG_DEVMEM is not set
nach Absicht und nicht nach einem Versehen.
Interpretiere ich eigentlich so, dass der Standardwert, also Y verwendet wird. Anderseits steht in der Configdatei nirgends "xyz=n". is not set = n?
verdooft, tut mir Leid, ein Gespräch unter Japanern kann genau so gut verstehen 😉 . Nämlich gar nicht.
Für was steht y oder p oder n? Für mich scheint es, wie bereits vermutet, die Informationen anders zu ermitteln sein. Ist >dmidecode< hier der falsche Befehl? Ich habe mal /usr/sbin/dmidecode mit GVIM nach HEX konvertiert, bzw. in HEX anzeigen lassen. Zeile: 0e6c0: 646d 6964 6563 6f64 652e 0a00 4661 696c dmidecode...Fail
oder: | 000e650: 0045 6467 6500 4e6f 0059 6573 004f 454d .Edge.No.Yes.OEM
000e660: 0023 2053 4d42 494f 5320 696d 706c 656d .# SMBIOS implem
000e670: 656e 7461 7469 6f6e 7320 6e65 7765 7220 entations newer
000e680: 7468 616e 2076 6572 7369 6f6e 2025 752e than version %u.
000e690: 2575 2061 7265 206e 6f74 0a23 2066 756c %u are not.# ful
000e6a0: 6c79 2073 7570 706f 7274 6564 2062 7920 ly supported by
000e6b0: 7468 6973 2076 6572 7369 6f6e 206f 6620 this version of
000e6c0: 646d 6964 6563 6f64 652e 0a00 4661 696c dmidecode...Fail
|
Gruß Andi
|
verdooft
Anmeldungsdatum: 15. September 2012
Beiträge: 3991
|
Hm, wenn ich neue Kernels teste, lade ich den Source, übernehme die Konfiguration vom bestehenden Kernel und nicke die hinzugekommenen Optionen ab. Nicht ubuntuspezifisch wäre das: CONFIG_DEVMEM=y Damit wäre /dev/mem weiter verfügbar und darauf zugreifende Programme funktionieren weiter. Vielleicht wird die Option ja wieder umgesetzt, ich weiß nicht, wo man sowas melden kann. y bedeutet yes (Unterstützung aktiviert), m bedeutet Modul (Funktionalität wird per Modul bereitgestellt, z.B. Unterstützung für ein Dateisystem, einen Verschlüsselungsalgo...), n eigentlich no, aber scheint hier als "is not set" in der Konfigurationsdatei aufzutauchen. Wird übrigens auch hier thematisiert, sogar mit Bezug auf dmidecode:
http://osdir.com/ml/kernel-team/2015-05/msg00568.html 4.1 könnts schon wieder haben: Seems to have been lost in the 4.1 rebase. I've reenabled it, and
assuming it builds the next -rc should have it.
http://comments.gmane.org/gmane.linux.ubuntu.devel.kernel.general/56688 Negativ, hab den RC 4 geladen, in der config-4.1.0-040100rc4-generic steht immer noch # CONFIG_DEVMEM is not set
# CONFIG_DEVKMEM is not set Tipp: original verwenden, nicht die Ubuntuverbastelung. 😀
|
optimq
(Themenstarter)
Anmeldungsdatum: 7. Dezember 2009
Beiträge: 1409
|
Und genau das dieses "is not set" dort steht, scheint kein Versehen zu sein. Ganz im Gegenteil.
Das muss jetzt nicht in Stein gemeißelt sein. Spiegelt aber den aktuellen Stand unter Kernel 4.*.* wieder. Und dann können die dmidecode-Befehle aus Systeminformationen ermitteln eben nicht funktionieren. Und wenn das schon so explizit hingeschrieben wird, ist es da nur vorübergehend und wird später wieder angepasst? Oder ist der Pfad unter Kernel 4.*.* generell ein anderer? Und es wird nur hingeschrieben, weil /dev/mem seit Jahren bekannt ist? Gruß Andi
|
optimq
(Themenstarter)
Anmeldungsdatum: 7. Dezember 2009
Beiträge: 1409
|
Hallo zusammen! Es ist jetzt zwar keine direkte Lösung zur Eingangsfrage. Aber eine gute Möglichkeit, Systeminformationen anders zu ermitteln. Entschuldigung, mir fiel erst heute ein, dass ich doch längst das sehr gute inxi (inxi-Optionen) installiert habe. Das unter 14.04 angebotene, ist jetzt nicht perfekt. Trotzdem ist es nahezu überragend und lässt fast keine Fragen offen. Edit: Noch ein kleines Stück besser, sieht es nach der Installation von inxi_2.2.21-0ubuntu1-14.04_all.deb aus. Gruß Andi
|
verdooft
Anmeldungsdatum: 15. September 2012
Beiträge: 3991
|
Du kannst inxi übrigens auch an der Paketverwaltung vorbei updaten: Dazu:
sudo nano /etc/inxi.conf
Die Zeile in das ändern:
B_ALLOW_UPDATE=true
Anschließend funktioniert die integrierte Updatefunktion:
sudo inxi -U
Starting inxi self updater.
Currently running inxi version number: 2.2.19
Current version patch number: 00
Updating inxi in /usr/bin using svn server as download source...
Successfully updated to svn server version: 2.2.21
...
|
optimq
(Themenstarter)
Anmeldungsdatum: 7. Dezember 2009
Beiträge: 1409
|
Danke verdooft für diesen Tipp! 👍 ~$ sudo inxi -U
[sudo] password for :
Starting inxi self updater.
Currently running inxi version number: 2.2.21
Current version patch number: 00
Updating inxi in /usr/bin using svn server as download source...
Successfully updated to svn server version: 2.2.21
New svn server version patch number: 00
To run the new version, just start inxi again.
----------------------------------------
Starting download of man page file now.
Checking Man page download URL...
Man file download URL verified: http://inxi.googlecode.com/svn/trunk/inxi.1.gz
Downloading Man page file now.
Download/install of man page successful. Check to make sure it works: man inxi
~$
Gruß Andi
|