Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comp.os.unix.linux.misc > #132252 > unrolled thread
| Started by | Andreas Kohlbach <ank@spamfence.net> |
|---|---|
| First post | 2023-06-29 16:21 -0400 |
| Last post | 2023-07-01 20:59 +0200 |
| Articles | 20 on this page of 189 — 23 participants |
Back to article view | Back to de.comp.os.unix.linux.misc
Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-06-29 16:21 -0400
Re: Numlock aktivieren Marco Moock <mo01@posteo.de> - 2023-06-29 22:40 +0200
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-06-29 18:03 -0400
Re: Numlock aktivieren Frank Miller <miller@posteo.ee> - 2023-06-30 00:40 +0200
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-06-29 19:21 -0400
Re: Numlock aktivieren Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2023-06-30 03:27 +0000
Re: Numlock aktivieren Frank Miller <miller@posteo.ee> - 2023-06-30 03:35 +0200
Re: Numlock aktivieren Frank Miller <miller@posteo.ee> - 2023-06-30 03:50 +0200
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-06-29 23:29 -0400
Re: Numlock aktivieren Frank Miller <miller@posteo.ee> - 2023-06-30 06:49 +0200
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-06-30 02:09 -0400
Re: Numlock aktivieren Frank Miller <miller@posteo.ee> - 2023-06-30 23:35 +0200
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-01 00:30 -0400
Re: Numlock aktivieren Arno Welzel <usenet@arnowelzel.de> - 2023-07-04 08:51 +0200
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-04 22:47 -0400
Re: Numlock aktivieren Frank Miller <miller@posteo.ee> - 2023-07-05 05:25 +0200
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-05 00:15 -0400
Re: Numlock aktivieren Frank Miller <miller@posteo.ee> - 2023-07-05 06:48 +0200
Notwendigkeit von Firmware-Paketen anzeigen (was: Numlock aktivieren) Tim Landscheidt <tim@tim-landscheidt.de> - 2023-07-05 10:43 +0000
Re: Notwendigkeit von Firmware-Paketen anzeigen Helmut Waitzmann <nn.throttle@xoxy.net> - 2023-07-09 21:34 +0200
Re: Numlock aktivieren Arno Welzel <usenet@arnowelzel.de> - 2023-07-10 16:54 +0200
Re: Numlock aktivieren Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2023-07-10 20:17 +0200
Re: Numlock aktivieren Arno Welzel <usenet@arnowelzel.de> - 2023-07-15 13:50 +0200
Re: Numlock aktivieren Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2023-07-15 19:58 +0200
Re: Numlock aktivieren Arno Welzel <usenet@arnowelzel.de> - 2023-07-16 04:45 +0200
Re: Numlock aktivieren Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2023-07-16 05:18 +0000
Re: Numlock aktivieren Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2023-07-16 20:37 +0200
Re: Numlock aktivieren Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2023-07-16 20:30 +0200
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-15 16:42 -0400
Re: Numlock aktivieren Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2023-07-16 20:44 +0200
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-16 19:53 -0400
Re: Numlock aktivieren Frank Miller <miller@posteo.ee> - 2023-07-17 03:35 +0200
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-16 22:18 -0400
Re: Numlock aktivieren Marcus Jodorf <m@bogomips.de> - 2023-07-18 07:35 +0200
Re: Numlock aktivieren Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-18 09:53 +0200
Re: Numlock aktivieren "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-07-18 10:36 +0200
Was genau ist Booten? (was: Numlock aktivieren) Andreas Kohlbach <ank@spamfence.net> - 2023-07-18 17:50 -0400
Re: Was genau ist Booten? (was: Numlock aktivieren) Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2023-07-19 20:12 +0200
Re: Was genau ist Booten? (was: Numlock aktivieren) Joerg Lorenz <hugybear@gmx.ch> - 2023-07-22 11:30 +0200
Re: Numlock aktivieren Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2023-07-17 20:14 +0200
Re: Numlock aktivieren Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-17 22:30 +0200
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-17 17:21 -0400
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-10 20:22 -0400
Re: Numlock aktivieren Frank Miller <miller@posteo.ee> - 2023-07-11 03:33 +0200
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-10 21:46 -0400
Re: Numlock aktivieren Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-11 08:47 +0200
Re: Numlock aktivieren Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2023-07-11 20:21 +0200
Re: Numlock aktivieren Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2023-07-12 14:02 +0000
Re: Numlock aktivieren Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2023-07-12 20:00 +0200
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-12 22:56 -0400
Re: Numlock aktivieren Frank Miller <miller@posteo.ee> - 2023-07-11 04:22 +0200
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-11 01:38 -0400
Re: Numlock aktivieren Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-11 08:48 +0200
Re: Numlock aktivieren "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-07-11 11:12 +0200
Re: Numlock aktivieren Frank Miller <miller@posteo.ee> - 2023-07-11 11:27 +0200
Re: Numlock aktivieren Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-15 11:34 +0200
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-15 16:38 -0400
Re: Numlock aktivieren Bernd Mayer <beam.bam.boom@knuut.de> - 2023-06-30 22:46 +0200
Re: Numlock aktivieren Frank Miller <miller@posteo.ee> - 2023-06-30 23:33 +0200
Re: Numlock aktivieren Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2023-06-30 21:56 +0000
Re: Numlock aktivieren Arno Welzel <usenet@arnowelzel.de> - 2023-07-04 08:54 +0200
Re: Numlock aktivieren Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2023-07-04 14:45 +0000
Re: Numlock aktivieren Arno Welzel <usenet@arnowelzel.de> - 2023-07-10 16:58 +0200
Re: Numlock aktivieren Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2023-07-10 16:01 +0000
Re: Numlock aktivieren Arno Welzel <usenet@arnowelzel.de> - 2023-07-15 13:53 +0200
Re: Numlock aktivieren Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2023-07-15 17:54 +0000
Re: Numlock aktivieren Bernd Mayer <beam.bam.boom@knuut.de> - 2023-07-01 07:35 +0200
Re: Numlock aktivieren michaelnoeusenet@mac.com (Michael Noe) - 2023-07-01 08:29 +0200
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-01 15:05 -0400
UEFI-Upgrade-Unlust (was: Numlock aktivieren) michaelnoeusenet@mac.com (Michael Noe) - 2023-07-02 09:47 +0200
Re: UEFI-Upgrade-Unlust Andreas Kohlbach <ank@spamfence.net> - 2023-07-02 22:51 -0400
Re: UEFI-Upgrade-Unlust Bernd Mayer <beam.bam.boom@knuut.de> - 2023-07-03 05:18 +0200
Re: UEFI-Upgrade-Unlust Andreas Kohlbach <ank@spamfence.net> - 2023-07-03 18:08 -0400
Re: UEFI-Upgrade-Unlust michaelnoeusenet@mac.com (Michael Noe) - 2023-07-04 17:33 +0200
Re: Numlock aktivieren Bernd Mayer <beam.bam.boom@knuut.de> - 2023-07-03 22:28 +0200
Re: Numlock aktivieren Arno Welzel <usenet@arnowelzel.de> - 2023-07-04 08:26 +0200
Re: Numlock aktivieren Bernd Mayer <beam.bam.boom@knuut.de> - 2023-07-01 09:42 +0200
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-01 15:06 -0400
Re: Numlock aktivieren Claus Reibenstein <creibens@gmail.com> - 2023-07-02 12:51 +0200
Re: Numlock aktivieren michaelnoeusenet@mac.com (Michael Noe) - 2023-07-02 13:11 +0200
Re: Numlock aktivieren Marcus Jodorf <m@bogomips.de> - 2023-07-02 17:18 +0200
Re: Numlock aktivieren michaelnoeusenet@mac.com (Michael Noe) - 2023-07-02 18:39 +0200
Re: Numlock aktivieren Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-03 08:57 +0200
Re: Numlock aktivieren Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-07-03 09:20 +0000
Re: Numlock aktivieren Marco Moock <mo01@posteo.de> - 2023-07-03 11:41 +0200
Re: Numlock aktivieren Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-07-03 10:40 +0000
Re: Numlock aktivieren Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-03 12:54 +0200
Re: Numlock aktivieren Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-07-03 11:08 +0000
Re: Numlock aktivieren Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-03 16:21 +0200
Re: Numlock aktivieren Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-07-03 19:13 +0000
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-03 19:21 -0400
Re: Numlock aktivieren Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-07-03 23:55 +0000
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-03 22:00 -0400
Re: Numlock aktivieren Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-07-04 09:15 +0000
Re: Numlock aktivieren Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2023-07-04 20:09 +0200
Re: Numlock aktivieren Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-07-04 21:05 +0000
Re: Numlock aktivieren Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2023-07-05 20:42 +0200
Re: Numlock aktivieren Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-07-05 20:28 +0000
Re: Numlock aktivieren Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2023-07-06 09:25 +0200
Re: Numlock aktivieren Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2023-07-06 20:04 +0200
Re: Numlock aktivieren Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-07-06 19:14 +0000
Re: Numlock aktivieren Marcus Jodorf <m@bogomips.de> - 2023-07-04 04:11 +0200
Re: Numlock aktivieren Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-04 10:02 +0200
Re: Numlock aktivieren Holger Schauer <Holger.Schauer@gmx.de> - 2023-07-13 15:47 +0200
Re: Numlock aktivieren Hermann Riemann <nospam.ng@hermann-riemann.de> - 2023-07-04 10:12 +0200
Re: Numlock aktivieren Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-04 13:30 +0200
Re: Numlock aktivieren Claus Reibenstein <creibens@gmail.com> - 2023-07-04 20:48 +0200
Re: Numlock aktivieren Claus Reibenstein <creibens@gmail.com> - 2023-07-04 20:45 +0200
Re: Numlock aktivieren Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-05 09:49 +0200
Re: Numlock aktivieren Claus Reibenstein <creibens@gmail.com> - 2023-07-05 17:57 +0200
Re: Numlock aktivieren Joerg Lorenz <hugybear@gmx.ch> - 2023-07-05 18:58 +0200
Re: Numlock aktivieren Enrik Berkhan <Enrik.Berkhan@inka.de> - 2023-07-05 08:54 +0000
Re: Numlock aktivieren Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-05 22:34 +0200
Re: Numlock aktivieren Enrik Berkhan <Enrik.Berkhan@inka.de> - 2023-07-06 05:28 +0000
Re: Numlock aktivieren Joerg Lorenz <hugybear@gmx.ch> - 2023-07-06 09:07 +0200
Re: Numlock aktivieren Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-07 11:14 +0200
Re: Numlock aktivieren Marcus Jodorf <m@bogomips.de> - 2023-07-06 23:16 +0200
Re: Numlock aktivieren Enrik Berkhan <Enrik.Berkhan@inka.de> - 2023-07-07 04:49 +0000
Re: Numlock aktivieren Arno Welzel <usenet@arnowelzel.de> - 2023-07-03 15:55 +0200
Re: Numlock aktivieren Marco Moock <mo01@posteo.de> - 2023-07-03 11:41 +0200
Re: Numlock aktivieren Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-03 12:54 +0200
Re: Numlock aktivieren Arno Welzel <usenet@arnowelzel.de> - 2023-07-03 15:57 +0200
Re: Numlock aktivieren michaelnoeusenet@mac.com (Michael Noe) - 2023-07-03 22:28 +0200
Re: Numlock aktivieren Marcus Jodorf <m@bogomips.de> - 2023-07-04 04:26 +0200
Re: Numlock aktivieren Marcus Jodorf <m@bogomips.de> - 2023-07-03 12:25 +0200
Re: Numlock aktivieren "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-07-02 17:30 +0200
Re: Numlock aktivieren Claus Reibenstein <creibens@gmail.com> - 2023-07-02 21:14 +0200
Re: Numlock aktivieren Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2023-07-02 19:58 +0000
Re: Numlock aktivieren Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-07-02 23:56 +0000
Re: Numlock aktivieren Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-03 09:05 +0200
Re: Numlock aktivieren Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-07-03 09:14 +0000
Re: Numlock aktivieren Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-03 12:55 +0200
Re: Numlock aktivieren Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-07-03 11:09 +0000
Re: Numlock aktivieren Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-03 16:23 +0200
Re: Numlock aktivieren Claus Reibenstein <creibens@gmail.com> - 2023-07-03 13:13 +0200
Re: Numlock aktivieren Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-03 16:28 +0200
Re: Numlock aktivieren Claus Reibenstein <creibens@gmail.com> - 2023-07-04 20:52 +0200
Re: Numlock aktivieren Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-05 09:51 +0200
Re: Numlock aktivieren Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2023-07-03 12:47 +0000
Re: Numlock aktivieren "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-07-03 15:02 +0200
Re: Numlock aktivieren Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2023-07-03 13:33 +0000
Re: Numlock aktivieren Paul Muster <exp-311223@news.muster.net> - 2023-07-03 17:08 +0200
Re: Numlock aktivieren Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2023-07-03 15:39 +0000
Re: Numlock aktivieren Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-03 16:29 +0200
Re: Numlock aktivieren Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2023-07-03 14:43 +0000
Re: Numlock aktivieren Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-03 20:21 +0200
Re: Numlock aktivieren Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-03 09:06 +0200
Re: Numlock aktivieren Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-07-03 09:16 +0000
Re: Numlock aktivieren Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-03 12:57 +0200
Re: Numlock aktivieren Claus Reibenstein <creibens@gmail.com> - 2023-07-03 13:19 +0200
Re: Numlock aktivieren Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-03 16:31 +0200
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-02 22:55 -0400
Re: Numlock aktivieren Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-07-03 09:17 +0000
Re: Numlock aktivieren Joerg Lorenz <hugybear@gmx.ch> - 2023-07-03 12:14 +0200
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-03 18:10 -0400
Re: Numlock aktivieren Arno Welzel <usenet@arnowelzel.de> - 2023-07-04 08:47 +0200
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-04 22:42 -0400
Re: Numlock aktivieren Frank Miller <miller@posteo.ee> - 2023-07-05 05:29 +0200
Re: Numlock aktivieren Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-05 09:53 +0200
Re: Numlock aktivieren Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2023-06-30 03:23 +0000
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-06-30 01:42 -0400
Re: Numlock aktivieren Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2023-06-30 13:27 +0000
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-01 00:28 -0400
Re: Numlock aktivieren Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2023-07-01 17:24 +0000
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-01 14:50 -0400
Re: Numlock aktivieren Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2023-07-01 19:22 +0000
Re: Numlock aktivieren Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-07-03 09:08 +0200
Re: Numlock aktivieren Paul Muster <exp-311223@news.muster.net> - 2023-07-03 12:43 +0200
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-03 19:30 -0400
Re: Numlock aktivieren Arno Welzel <usenet@arnowelzel.de> - 2023-07-03 11:26 +0200
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-03 19:44 -0400
Re: Numlock aktivieren Arno Welzel <usenet@arnowelzel.de> - 2023-07-04 08:45 +0200
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-04 22:39 -0400
Re: Numlock aktivieren Frank Miller <miller@posteo.ee> - 2023-07-05 05:37 +0200
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-05 00:20 -0400
Re: Numlock aktivieren Arno Welzel <usenet@arnowelzel.de> - 2023-07-10 17:03 +0200
Re: Numlock aktivieren Ralph Angenendt <dein.name@strg-alt-entf.org> - 2023-07-05 13:52 +0000
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-05 17:50 -0400
Re: Numlock aktivieren Frank Miller <miller@posteo.ee> - 2023-07-06 00:44 +0200
Re: Numlock aktivieren Arno Welzel <usenet@arnowelzel.de> - 2023-07-10 17:01 +0200
Re: Numlock aktivieren "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-07-01 21:18 +0200
Re: Numlock aktivieren Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2023-07-01 19:35 +0000
Re: Numlock aktivieren Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2023-07-01 20:58 +0200
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-01 19:02 -0400
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-01 19:35 -0400
Re: Numlock aktivieren Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2023-07-02 20:16 +0200
Re: Numlock aktivieren erzhausen <erzhausen@gmx.net> - 2023-06-30 07:55 +0200
Re: Numlock aktivieren Andreas Kohlbach <ank@spamfence.net> - 2023-07-01 00:28 -0400
Re: Numlock aktivieren Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2023-07-01 20:59 +0200
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2023-07-17 22:30 +0200 |
| Message-ID | <u948e4$1rlp2$1@news1.tnib.de> |
| In reply to | #132846 |
Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> wrote: >2023-07-10T21:24:27.288632-04:00 ist der Zeitpunkt, zu dem diese Ausgabe >erzeugt wurde. Wann begann danach bei diesem Vorgang nach Deiner Auffassung >der "Boot-Vorgang"? Das müßte ja wenigstens nach 2023-07-10T21:24:27 sein. >Diese und die vorherigen Ausgaben kamen vom Linux-Kernel Deiner Maschine. Nein. es ist der Zeitpunkt, zu der ein Prozess den Kernel-Ringbuffer in das syslog geschoben hat. Das ist üblicherweise zu einem Zeitpunkt wesentlich später im Bootprozess, wenn nämlich syslog oder journald schon läuft. -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | Andreas Kohlbach <ank@spamfence.net> |
|---|---|
| Date | 2023-07-17 17:21 -0400 |
| Message-ID | <87fs5mtes5.fsf@usenet.ankman.de> |
| In reply to | #132846 |
On Mon, 17 Jul 2023 20:14:01 +0200, Sieghard Schicktanz wrote: > > Du schriebst am Sun, 16 Jul 2023 19:53:58 -0400: > >> > [Mikrocode laden] > >> Vielleicht aber der zweite Eintrag, der "microcode" hat >> >> | 2023-07-10T21:24:27.288632-04:00 workhorse kernel: [ 0.081608] SRBDS: >> | Mitigation: Microcode >> >> Immer noch deutlich vor der ersten Sekunde. > > 2023-07-10T21:24:27.288632-04:00 ist der Zeitpunkt, zu dem diese Ausgabe > erzeugt wurde. Wann begann danach bei diesem Vorgang nach Deiner Auffassung > der "Boot-Vorgang"? Das müßte ja wenigstens nach 2023-07-10T21:24:27 sein. > Diese und die vorherigen Ausgaben kamen vom Linux-Kernel Deiner Maschine. Es geht darum, wann Microcode geladen wurde, *nicht*, ab wann ein Boot genau als Boot bezeichnet werden kann. Oder damit verbundene Angaben zu Zeitstempeln. Ich weiß nicht mehr, warum Du und auch andere jetzt auf das Thema "Was genau ist Booten" abschweifen. Oder warum ich darauf überhaupt einging. Das ist für die eigentliche Fragestellung, wann Microcode geladen wird, völlig unerheblich. Das Thema läuft wieder mal völlig aus dem Ruder, weil abgeschweift wird. Und vielleicht auch nur vor dem Hintergrund Gründe zu finden, andere zu beschuldigen? | Dann solltest Du Dich aus solchen Diskussionen heraushalten undbrav | alles akzeptieren, was "der Computer" von Dir will, so wie es ein | "sog. DAU" halt tut. Das. Sollte ich doch noch anfangen, Regulars zu filtern? -- Andreas
[toc] | [prev] | [next] | [standalone]
| From | Andreas Kohlbach <ank@spamfence.net> |
|---|---|
| Date | 2023-07-10 20:22 -0400 |
| Message-ID | <874jmb70wf.fsf@usenet.ankman.de> |
| In reply to | #132678 |
On Mon, 10 Jul 2023 16:54:32 +0200, Arno Welzel wrote: > > Andreas Kohlbach, 2023-07-05 04:47: > >> On Tue, 4 Jul 2023 08:51:49 +0200, Arno Welzel wrote: >>> >>> Unahabhängig vom Numlock-Status: >>> >>> Mikrocode wird nicht von der Linux-Distribution geliefert, sondern vom >>> Hardware-Hersteller. Wenn eine Linux-Distribution sich wegen veraltetem >>> BIOS komisch verhält, ist die Lösung, das BIOS zu aktualisieren. >> >> Ich habe hier Unmengen von Firmware Paketen. >> >> Und wer ist der Hardware-Hersteller? Da die CPU von besagten Bugs >> betroffen ist, dürften die Intel bzw. AMD sein. Nicht aber DELL in meinem >> Fall. > > Intel und AMD liefern an Dell und die bauen das dann in ihr BIOS/UEFI ein. Das war auch die Annahme meiner eher rhetorischen Frage. > Siehe z.B.: > > <https://www.deskmodder.de/blog/2022/01/22/neuer-intel-mikrocode-in-kritischen-sicherheits-firmware-update/> > >> Und Intel und AMD tun gut daran, den Microcode auch zu >> veröffentlichen. Somit sollte er für jede Distribution verfügbar sein. > > Tun sie ja. Siehe oben. Aber man integriert das nicht in Linux sondern > nutzt das, um das BIOS/UEFI des Systems zu aktualisieren - denn der > Mikrocode ist für die CPU gedacht und nicht für Software und er muss > vorhanden sein *bevor* Linux bootet. > >> Weiter wir der Installer bei der Installation wissen, welche CPU da >> läuft, und entsprechenden Microcode automatisch installieren. > > Nein. Dann hatte ich das mit dem Mikrocode missverstanden. Ich war der Annahme, dass der (beim Booten) in entsprechende Chips (CPU, Netzwerkkarte...) "injiziert" wird. Also in meinem Fall (DELL!!!!111 ;-)) Intel den Code liefert, und OS-Hersteller wie Microsoft oder Linux sich den besorgen und einpflegen. Ich war der Annahme, weil nach dem ersten Booten nach der Installation Bluetooth nicht lief. Google meinte, ich soll entsprechenden Mikrocode installieren. Google hatte Recht, und nach dem nächsten Boot funktionierte auch Bluetooth. -- Andreas
[toc] | [prev] | [next] | [standalone]
| From | Frank Miller <miller@posteo.ee> |
|---|---|
| Date | 2023-07-11 03:33 +0200 |
| Message-ID | <64ACB159.8090303@backwurst.de> |
| In reply to | #132696 |
Andreas Kohlbach wrote: > On Mon, 10 Jul 2023 16:54:32 +0200, Arno Welzel wrote: [..snip..] >> Intel und AMD liefern an Dell und die bauen das dann in ihr BIOS/UEFI ein. > > Das war auch die Annahme meiner eher rhetorischen Frage. So rhetorisch wie die Frage in deinem Anfangsposting? ;-) [..snip..] > Dann hatte ich das mit dem Mikrocode missverstanden. > > Ich war der Annahme, dass der (beim Booten) in entsprechende Chips > (CPU, Netzwerkkarte...) "injiziert" wird. Also in meinem Fall > (DELL!!!!111 ;-)) Intel den Code liefert, und OS-Hersteller wie Microsoft > oder Linux sich den besorgen und einpflegen. Da liegst du diesmal garnicht mal ganz falsch. Warum verlässt du dich eigentlich nur auf Meinungen anderer Newsgroup-User und 'Google', anstatt mal selber /korrekte/ Fakten zu recherchieren? Das offizielle Wiki von Debian erklärt Microcode sehr genau: https://wiki.debian.org/Microcode (Und jetzt komm mir bloss nicht mit "Da wird aber noch Debian 11 als Stable angegeben, vielleicht hat sich das ja geändert?" Dann kotze ich ins Notebook!) > Ich war der Annahme, weil nach dem ersten Booten nach der Installation > Bluetooth nicht lief. Google meinte, ich soll entsprechenden Mikrocode > installieren. Google hatte Recht, und nach dem nächsten Boot > funktionierte auch Bluetooth. Ach Guck! Wie *überraschend*! Wie gut, daß du Google hast.
[toc] | [prev] | [next] | [standalone]
| From | Andreas Kohlbach <ank@spamfence.net> |
|---|---|
| Date | 2023-07-10 21:46 -0400 |
| Message-ID | <87mt03jk3c.fsf@usenet.ankman.de> |
| In reply to | #132697 |
On Tue, 11 Jul 2023 03:33:13 +0200, Frank Miller wrote: > > Andreas Kohlbach wrote: >> >> Ich war der Annahme, dass der (beim Booten) in entsprechende Chips >> (CPU, Netzwerkkarte...) "injiziert" wird. Also in meinem Fall >> (DELL!!!!111 ;-)) Intel den Code liefert, und OS-Hersteller wie Microsoft >> oder Linux sich den besorgen und einpflegen. > > Da liegst du diesmal garnicht mal ganz falsch. Ich war immer dieser Meinung. Hatte mich vielleicht ungeschickt ausgedrückt. > Warum verlässt du dich eigentlich nur auf Meinungen anderer > Newsgroup-User und 'Google', anstatt mal selber /korrekte/ Fakten zu > recherchieren? Ich nutze durchaus Google und Hinweise hier, um selbst zu recherchieren. > Das offizielle Wiki von Debian erklärt Microcode sehr genau: > https://wiki.debian.org/Microcode (Und jetzt komm mir bloss nicht mit > "Da wird aber noch Debian 11 als Stable angegeben, vielleicht hat sich > das ja geändert?" Dann kotze ich ins Notebook!) | Processor microcode is akin to processor firmware. The kernel is | able to update the processor's firmware without the need to update | it via a BIOS update. Das war immer meine Annahme. Danke Wiki für die Bestätigung. :-) Vielleicht hatte ich mich eben ungeschickt ausgedrückt als ich sagte, Intel (in meinem Fall) wird den nötigen Code nach Finden eines Bugs anderen zur Verfügung stellen, die dann für die Distribution sorgen. >> Ich war der Annahme, weil nach dem ersten Booten nach der Installation >> Bluetooth nicht lief. Google meinte, ich soll entsprechenden Mikrocode >> installieren. Google hatte Recht, und nach dem nächsten Boot >> funktionierte auch Bluetooth. > > Ach Guck! Wie *überraschend*! Wie gut, daß du Google hast. Wer weiß, wie lange noch. -- Andreas
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2023-07-11 08:47 +0200 |
| Message-ID | <u8ituh$icq4$1@news1.tnib.de> |
| In reply to | #132696 |
Andreas Kohlbach <ank@spamfence.net> wrote: >Ich war der Annahme, weil nach dem ersten Booten nach der Installation >Bluetooth nicht lief. Google meinte, ich soll entsprechenden Mikrocode >installieren. Google hatte Recht, und nach dem nächsten Boot >funktionierte auch Bluetooth. Microcode oder Firmware? Grüße Marc -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> |
|---|---|
| Date | 2023-07-11 20:21 +0200 |
| Message-ID | <20230711202131.35608877@Achmuehle.WOR> |
| In reply to | #132707 |
Hallo Marc, Du schriebst am Tue, 11 Jul 2023 08:47:45 +0200: > >installieren. Google hatte Recht, und nach dem nächsten Boot > >funktionierte auch Bluetooth. > > Microcode oder Firmware? Bei einem Bluetooth-Modul? Weder noch, sondern dessen Betriebsprogramm, nach herkömmlicher Nomenklatur "Software". Weder auf einem (in- oder externen) Massenspeicher noch in einem Flash- oder E-EPROM, und auch nicht in einem Prozessor auf dem Modul selber (üblicherweise als "Firmware" bezeichnet) - die könnte - und müßte nach jedem Einschalten - man halt nicht (nach-) laden. -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz -----------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> |
|---|---|
| Date | 2023-07-12 14:02 +0000 |
| Message-ID | <168917055805.24414.7475993674923595260.XPN@ID-37099.user.uni-berlin.de> |
| In reply to | #132723 |
Sieghard Schicktanz schrieb am 11/7/2023 20:21: > Du schriebst am Tue, 11 Jul 2023 08:47:45 +0200: > >> >installieren. Google hatte Recht, und nach dem nächsten Boot >> >funktionierte auch Bluetooth. >> >> Microcode oder Firmware? > > Bei einem Bluetooth-Modul? Die für Bluetooth-Module mit Chip von Realtek nötige Firmware befindet sich bei Debian und Co unter /lib/firmware/rtl_bt. Hat mich bei einem USB-BT-Sender mit großer Reichweite etwas gewundert, dass der ein Firmware-Paket aus nonfree benötigt, ist aber bei Realtek anscheinend so. > Weder noch, sondern dessen Betriebsprogramm, nach herkömmlicher Nomenklatur > "Software". Derartige Software wird üblicherweise "Firmware" genannt. > Weder auf einem (in- oder externen) Massenspeicher noch in > einem Flash- oder E-EPROM, und auch nicht in einem Prozessor auf dem Modul > selber (üblicherweise als "Firmware" bezeichnet) - die könnte - und müßte > nach jedem Einschalten - man halt nicht (nach-) laden. /lib/firmware ist voll von Firmware für USB-Geräte, die beim Anstecken derselbigen in ein RAM geladen wird. -- Gerald
[toc] | [prev] | [next] | [standalone]
| From | Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> |
|---|---|
| Date | 2023-07-12 20:00 +0200 |
| Message-ID | <20230712200007.23002e7a@Achmuehle.WOR> |
| In reply to | #132732 |
Hallo Gerald, Du schriebst am 12 Jul 2023 14:02:38 GMT: > Die für Bluetooth-Module mit Chip von Realtek nötige Firmware befindet > sich bei Debian und Co unter /lib/firmware/rtl_bt. > Hat mich bei einem USB-BT-Sender mit großer Reichweite etwas gewundert, > dass der ein Firmware-Paket aus nonfree benötigt, ist aber bei Realtek > anscheinend so. "Irgendwo nebenan" hat doch wer aus den Debian-"Statuten" zitiert, daß das so gehört, weil diese Software nicht als Source-Code verfüügbar ist. > > Weder noch, sondern dessen Betriebsprogramm, nach herkömmlicher > > Nomenklatur "Software". > > Derartige Software wird üblicherweise "Firmware" genannt. Ja, schon, die Nomenklatur dazu ist nicht erst seit kurzem alles andere als eindeutig, und für jede Einsortierung lassen sich wohl Gegenargumente finden. Als der Begriff "Firmware" aufkam, sollte er eben den Unterschied zur "flüchtigen" (weil im Arbeitsspeicher gehalteten) "Software" darstellen. Nur hat sich das halt nicht so recht und vor allem nicht konsistent durchgesetzt, und es entstand halt das heutige Kuddelmuddel. ... > /lib/firmware ist voll von Firmware für USB-Geräte, die beim Anstecken > derselbigen in ein RAM geladen wird. Eben, also _eigentlich_ keine Firmware, die müßte fest im Gerät sitzen. -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz -----------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Andreas Kohlbach <ank@spamfence.net> |
|---|---|
| Date | 2023-07-12 22:56 -0400 |
| Message-ID | <87h6q8ikou.fsf@usenet.ankman.de> |
| In reply to | #132723 |
On Tue, 11 Jul 2023 20:21:31 +0200, Sieghard Schicktanz wrote:
>
> Hallo Marc,
>
> Du schriebst am Tue, 11 Jul 2023 08:47:45 +0200:
>
>> >installieren. Google hatte Recht, und nach dem nächsten Boot
>> >funktionierte auch Bluetooth.
>>
>> Microcode oder Firmware?
>
> Bei einem Bluetooth-Modul?
Bluetooth Chip.
Hier ein WLAN/Bluetooth Hybrid. Nennt sich AR9462 und nutzt den
Treiber ath3k.
lsmod sagt dazu:
bluetooth 954368 59 btrtl,btmtk,btintel,btbcm,bnep,ath3k,btusb,rfcomm
^^^^^
--
Andreas
[toc] | [prev] | [next] | [standalone]
| From | Frank Miller <miller@posteo.ee> |
|---|---|
| Date | 2023-07-11 04:22 +0200 |
| Message-ID | <64ACBCC8.20605@backwurst.de> |
| In reply to | #132678 |
Arno Welzel wrote: >> On Tue, 4 Jul 2023 08:51:49 +0200, Arno Welzel wrote: >>> Mikrocode wird nicht von der Linux-Distribution geliefert, sondern vom >>> Hardware-Hersteller. Wenn eine Linux-Distribution sich wegen veraltetem >>> BIOS komisch verhält, ist die Lösung, das BIOS zu aktualisieren. Oder aber die Linux-Distri übernimmt den zur Verfügung gestellten Microcode des Herstellers und packt es in ein installierbares Paket. > Tun sie ja. Siehe oben. Aber man integriert das nicht in Linux sondern > nutzt das, um das BIOS/UEFI des Systems zu aktualisieren - denn der > Mikrocode ist für die CPU gedacht und nicht für Software und er muss > vorhanden sein *bevor* Linux bootet. Nein. Auch *während* Linux (zumindest Debian) bootet. Du verwechselst komplette BIOS/UEFI upgrades mit Microcode. "Microcode updates are only applied at boot, so you have to reboot to activate them. You will have to keep the packages installed as explained above: the microcode updates have to be reapplied at every boot." RTFM: https://wiki.debian.org/Microcode#Updating_CPU_microcode_within_Debian_.28Intel_or_AMD.29 Kurz gefasst IMHO - es gibt zumindest zwei Möglichkeiten, CPUs auf halbwegs aktuellen Stand zu bringen: Entweder das Update nackt von einem (meist Windows- oder DOS-basiertem) Medium booten und installieren. Rebooten und hoffen, daß nix schief gegangen ist. Die neue Firmware des Herstellers wird dann quasi "fest eingebrannt". Oder Microcode-Pakete installieren, die bei jedem Bootvorgang vor dem eigentlichen Betriebssystem quasi "Patches" auf die CPU kleben und anschließend im laufenden Betrieb wirken.
[toc] | [prev] | [next] | [standalone]
| From | Andreas Kohlbach <ank@spamfence.net> |
|---|---|
| Date | 2023-07-11 01:38 -0400 |
| Message-ID | <877cr7j9ck.fsf@usenet.ankman.de> |
| In reply to | #132699 |
On Tue, 11 Jul 2023 04:22:00 +0200, Frank Miller wrote: > > Arno Welzel wrote: >>> On Tue, 4 Jul 2023 08:51:49 +0200, Arno Welzel wrote: >>>> Mikrocode wird nicht von der Linux-Distribution geliefert, sondern vom >>>> Hardware-Hersteller. Wenn eine Linux-Distribution sich wegen veraltetem >>>> BIOS komisch verhält, ist die Lösung, das BIOS zu aktualisieren. > > Oder *Und*, meiner Einschätzung nach. > [...] aber die Linux-Distri übernimmt den zur Verfügung gestellten > Microcode des Herstellers und packt es in ein installierbares Paket. Wenn eine beider Methoden implementiert wird, sollte ein Bug, wie Spectre, nicht zum Zuge kommen. Beide Methoden zusammen können wohl auch nicht schaden. Und da ich als OP (wie erwähnt) 100 % meiner BIOS Upgrades versaut habe, bin ich über die Verfügbarkeit des Mikrocode [1] glücklich. [1] Sollte es nicht "Microcode" oder "Mikrokode" (*grusel*) sein? -- Andreas
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2023-07-11 08:48 +0200 |
| Message-ID | <u8iu0s$ics0$1@news1.tnib.de> |
| In reply to | #132699 |
Frank Miller <miller@posteo.ee> wrote: >"Microcode updates are only applied at boot, so you have to reboot to >activate them. You will have to keep the packages installed as explained >above: the microcode updates have to be reapplied at every boot." Aber es gibt doch auch UEFI-Firmwares, die den Microcode integriert haben und diesen bei jedem Boot von sich aus in den Prozessor schießen? Grüße Marc -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet3@hjp.at> |
|---|---|
| Date | 2023-07-11 11:12 +0200 |
| Message-ID | <slrnuaq77v.6ou.hjp-usenet3@trintignant.hjp.at> |
| In reply to | #132708 |
On 2023-07-11 06:48, Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
> Frank Miller <miller@posteo.ee> wrote:
>>"Microcode updates are only applied at boot, so you have to reboot to
>>activate them. You will have to keep the packages installed as explained
>>above: the microcode updates have to be reapplied at every boot."
>
> Aber es gibt doch auch UEFI-Firmwares, die den Microcode integriert
> haben und diesen bei jedem Boot von sich aus in den Prozessor
> schießen?
Ja, gibt es auch. Steht auch so in dem von Frank zitierten Artikel.
Prinzipiell startet die CPU mit dem Microcode, mit dem sie ausgeliefert
wurde, und Updates müssen irgendwann im Betrieb durchgeführt werden - im
Idealfall natürlich möglichst früh im Bootprozess. UEFI wäre der
richtige Ort dafür, aber da viele User das nie updaten, checkt der Kernel
auch noch, ob der Microcode aktuell ist und lädt den wenn notwendig.
hp
[toc] | [prev] | [next] | [standalone]
| From | Frank Miller <miller@posteo.ee> |
|---|---|
| Date | 2023-07-11 11:27 +0200 |
| Message-ID | <64AD2078.1070308@backwurst.de> |
| In reply to | #132708 |
Marc Haber wrote: > Frank Miller <miller@posteo.ee> wrote: >>"Microcode updates are only applied at boot, so you have to reboot to >>activate them. You will have to keep the packages installed as explained >>above: the microcode updates have to be reapplied at every boot." > > Aber es gibt doch auch UEFI-Firmwares, die den Microcode integriert > haben und diesen bei jedem Boot von sich aus in den Prozessor > schießen? *sigh* Es steht doch IMO wirklich *alles* zum Verständnis Nötige im Wiki-Artikel: "The BIOS (or UEFI) updates the CPU microcode during boot, however most of the time either the motherboard vendor won't issue frequent BIOS/UEFI updates, or the user won't install such updates. For these reasons, the system processor is likely to be running with outdated microcode on a vast number of systems. [..] The CPU microcode update system is composed of software (kernel drivers, user-space utilities), and CPU-vendor-provided "opaque" update data. The kernel drivers and user-space utilities related to CPU microcode updates are free software, compliant to the Debian Free Software Guidelines. The CPU-vendor-provided "opaque" update data itself, however, is non-free, and its contents are unknown to Debian. This "opaque" data is sent as-is to the CPU for processing, but only when the kernel and user-space utilities deem it necessary to do so. This means the microcode update is not sent to the system processor unless it is actually needed. For example, the system will never send microcode update data to the processor when the processor reports that its already running either the same version or a newer version of the microcode (because the UEFI/BIOS already updated it). It will also not send microcode update data that is not appropriate to that system processor." So, Vorlese-Stunde beendet.
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2023-07-15 11:34 +0200 |
| Message-ID | <u8tp7h$1ci7i$1@news1.tnib.de> |
| In reply to | #132712 |
Frank Miller <miller@posteo.ee> wrote: >Marc Haber wrote: >> Frank Miller <miller@posteo.ee> wrote: >>>"Microcode updates are only applied at boot, so you have to reboot to >>>activate them. You will have to keep the packages installed as explained >>>above: the microcode updates have to be reapplied at every boot." >> >> Aber es gibt doch auch UEFI-Firmwares, die den Microcode integriert >> haben und diesen bei jedem Boot von sich aus in den Prozessor >> schießen? > >*sigh* Es steht doch IMO wirklich *alles* zum Verständnis Nötige im Wiki-Artikel: > > >"The BIOS (or UEFI) updates the CPU microcode during boot, however most of >the time either the motherboard vendor won't issue frequent BIOS/UEFI updates, >or the user won't install such updates. For these reasons, the system processor >is likely to be running with outdated microcode on a vast number of systems. >[..] Zusammengefasst: Ja, gibt es, aber die Updates über die Linux-Distribution sind eventuell schneller als der Mainboardhersteller. Das ist doch kein Grund sich aufzuregen. >So, Vorlese-Stunde beendet. Danke. -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | Andreas Kohlbach <ank@spamfence.net> |
|---|---|
| Date | 2023-07-15 16:38 -0400 |
| Message-ID | <87bkgcx640.fsf@usenet.ankman.de> |
| In reply to | #132766 |
On Sat, 15 Jul 2023 11:34:41 +0200, Marc Haber wrote: > > Frank Miller <miller@posteo.ee> wrote: >>Marc Haber wrote: >>> >>> Aber es gibt doch auch UEFI-Firmwares, die den Microcode integriert >>> haben und diesen bei jedem Boot von sich aus in den Prozessor >>> schießen? >> >>*sigh* Es steht doch IMO wirklich *alles* zum Verständnis Nötige im Wiki-Artikel: >> >> >>"The BIOS (or UEFI) updates the CPU microcode during boot, however most of >>the time either the motherboard vendor won't issue frequent BIOS/UEFI updates, >>or the user won't install such updates. For these reasons, the system processor >>is likely to be running with outdated microcode on a vast number of systems. >>[..] > > Zusammengefasst: Ja, gibt es, aber die Updates über die > Linux-Distribution sind eventuell schneller als der > Mainboardhersteller. Und potentiell gefährlich, wenn es jemand mit zwei linken Händen wie mir tut. > Das ist doch kein Grund sich aufzuregen. :-) -- Andreas
[toc] | [prev] | [next] | [standalone]
| From | Bernd Mayer <beam.bam.boom@knuut.de> |
|---|---|
| Date | 2023-06-30 22:46 +0200 |
| Message-ID | <u7neub$20sac$1@news.nnpt4.net> |
| In reply to | #132261 |
Am 30.06.23 um 05:29 schrieb Andreas Kohlbach: > Dann müsste ich davon ausgehen, dass Linux (oder irgendein OS) im BIOS > (das Ding, was noch vor dem Booten von Festplatte/CD/USB... kommt?) > Änderungen vornehmen kann. Kann es das? > >> Einfach mal nachschauen vielleicht, nur um sicher zu gehen? > > Booten dauert hier extrem lange (das Runterfahren noch länger als das > Booten). Dann muss ich alles wieder starten, mich im Browser wieder > überall von Hand einloggen... Das mit dem Numlock ist dann doch nicht so > wichtig. Hallo, wenn der PC länger im Einsatz war oder älter ist, dann kann die Batterie fürs BIOS schlapp machen. Dadurch können sich BIOS-Einstellungen ungünstig verändern und es können die Probleme auftreten die Du oben erwähnst. Wenn man keine zwei linke Hände hat dann ist solch ein Batteriewechsel recht einfach. Die Batterie ist auch nicht teuer, etwas abhängig vom Händler. Ich wundere mich schon sehr, daß Du Dich so strikt weigerst mal kurz im BIOS nachzusehen. Bernd Mayer
[toc] | [prev] | [next] | [standalone]
| From | Frank Miller <miller@posteo.ee> |
|---|---|
| Date | 2023-06-30 23:33 +0200 |
| Message-ID | <649F4A11.1040908@backwurst.de> |
| In reply to | #132285 |
Bernd Mayer wrote: [..snip..] > Ich wundere mich schon sehr, daß Du Dich so strikt weigerst mal kurz im > BIOS nachzusehen. Er sagte doch, daß *er* im BIOS seit Jahren nichts geändert hat, also *kann* sich da auch per Definition nichts geändert haben. Daher schaut er auch garnicht erst nach; das ist eben seine Logik. Ist ja nicht das erste Mal, daß er nach Hilfe fragt und dann sämtliche Anregungen und Vorschläge in den Wind schlägt, weil das ja seiner Meinung nach alles garnicht zielführend sein *kann* und es außerdem ja auch jahrelang "einfach so" funktioniert hat.
[toc] | [prev] | [next] | [standalone]
| From | Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> |
|---|---|
| Date | 2023-06-30 21:56 +0000 |
| Message-ID | <168816218955.24414.13966336150642950762.XPN@ID-37099.user.uni-berlin.de> |
| In reply to | #132285 |
Bernd Mayer schrieb am 30/6/2023 22:46: > Am 30.06.23 um 05:29 schrieb Andreas Kohlbach: > >> Booten dauert hier extrem lange (das Runterfahren noch länger als das >> Booten). Dann muss ich alles wieder starten, mich im Browser wieder >> überall von Hand einloggen... Was für einen vorsintflutlichen Brauser verwendest du denn? Moderne Brauser können ihre offenen Tabs nach Neustart automagisch wiederherstellen und haben einen Passwortmanager eingebaut. >> Das mit dem Numlock ist dann doch nicht so >> wichtig. > > wenn der PC länger im Einsatz war oder älter ist, dann kann die Batterie > fürs BIOS schlapp machen. > > Dadurch können sich BIOS-Einstellungen ungünstig verändern und es können > die Probleme auftreten die Du oben erwähnst. Guter Hinweis, eine leere CMOS-Knopfzelle kann zu den seltsamsten Effekten führen. Bei meinem kleinen Industrie-PC waren dies nicht mehr funktionierende SATA-Anschlüsse. > Wenn man keine zwei linke Hände hat dann ist solch ein Batteriewechsel > recht einfach. Bei PCs ja, bei Notbüchern und Miniatur-PCs braucht es einen Lötkolben und zum Teil viel Schraubarbeit. -- Gerald
[toc] | [prev] | [next] | [standalone]
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
Back to top | Article view | de.comp.os.unix.linux.misc
csiph-web