Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comp.os.unix.linux.misc > #116028 > unrolled thread
| Started by | georg.schwarz@freenet.de (Georg Schwarz) |
|---|---|
| First post | 2021-03-28 23:05 +0200 |
| Last post | 2021-04-10 22:43 +0200 |
| Articles | 20 on this page of 236 — 31 participants |
Back to article view | Back to de.comp.os.unix.linux.misc
Vorteil von UEFI? georg.schwarz@freenet.de (Georg Schwarz) - 2021-03-28 23:05 +0200
Re: Vorteil von UEFI? Sven Hartge <sh-213@svenhartge.de> - 2021-03-28 23:28 +0200
Re: Vorteil von UEFI? Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-03-29 03:41 +0200
Re: Vorteil von UEFI? Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2021-03-29 07:30 +0200
Re: Vorteil von UEFI? georg.schwarz@freenet.de (Georg Schwarz) - 2021-03-29 10:17 +0200
Re: Vorteil von UEFI? Sven Hartge <sh-213@svenhartge.de> - 2021-03-29 10:50 +0200
Re: Vorteil von UEFI? Tim Ritberg <tim@server.invalid> - 2021-03-29 10:52 +0200
Re: Vorteil von UEFI? georg.schwarz@freenet.de (Georg Schwarz) - 2021-03-29 12:05 +0200
Re: Vorteil von UEFI? Tim Ritberg <tim@server.invalid> - 2021-03-29 12:19 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-29 13:52 +0200
Re: Vorteil von UEFI? georg.schwarz@freenet.de (Georg Schwarz) - 2021-03-29 15:49 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-30 10:01 +0200
Re: Vorteil von UEFI? georg.schwarz@freenet.de (Georg Schwarz) - 2021-03-31 22:39 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-01 15:39 +0200
Re: Vorteil von UEFI? Claus Reibenstein <creibens@gmail.com> - 2021-04-01 16:56 +0200
Re: Vorteil von UEFI? Claus Reibenstein <creibens@gmail.com> - 2021-04-01 17:09 +0200
Re: Vorteil von UEFI? Juergen Ilse <news@usenet-verwaltung.de> - 2021-04-02 09:43 +0000
Re: Vorteil von UEFI? Claus Reibenstein <creibens@gmail.com> - 2021-04-03 16:41 +0200
Re: Vorteil von UEFI? Sven Hartge <sh-213@svenhartge.de> - 2021-04-04 12:12 +0200
Re: Vorteil von UEFI? Claus Reibenstein <creibens@gmail.com> - 2021-04-04 14:16 +0200
Re: Vorteil von UEFI? Sven Hartge <sh-213@svenhartge.de> - 2021-04-04 15:35 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-04 16:19 +0200
Re: Vorteil von UEFI? Claus Reibenstein <creibens@gmail.com> - 2021-04-04 17:03 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-04 19:56 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-05 14:51 +0200
Re: Vorteil von UEFI? Frank Schletz <frank.schletz@web.de> - 2021-04-05 15:55 +0200
Re: Vorteil von UEFI? Juergen Ilse <news@usenet-verwaltung.de> - 2021-04-05 16:22 +0000
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-05 19:48 +0200
Re: Vorteil von UEFI? Juergen Ilse <news@usenet-verwaltung.de> - 2021-04-05 21:06 +0000
Re: Vorteil von UEFI? Marcus Jodorf <trap@killfile.de> - 2021-04-05 23:25 +0200
Re: Vorteil von UEFI? Juergen Ilse <news@usenet-verwaltung.de> - 2021-04-05 21:42 +0000
Re: Vorteil von UEFI? klaus reile <klaus.reile@no-more-mail-to.zr> - 2021-04-06 09:30 +0200
Re: Vorteil von UEFI? Ralph Angenendt <dein.name@strg-alt-entf.org> - 2021-04-06 13:46 +0000
Re: Vorteil von UEFI? Claus Reibenstein <creibens@gmail.com> - 2021-04-05 13:10 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-05 13:31 +0200
Re: Vorteil von UEFI? Claus Reibenstein <creibens@gmail.com> - 2021-04-05 14:13 +0200
Re: Vorteil von UEFI? Stephan Seitz <stse+usenet@rootsland.net> - 2021-04-05 16:38 +0000
Re: Vorteil von UEFI? Juergen Ilse <news@usenet-verwaltung.de> - 2021-04-05 16:15 +0000
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-05 19:49 +0200
Re: Vorteil von UEFI? Juergen Ilse <news@usenet-verwaltung.de> - 2021-04-05 21:09 +0000
Re: Vorteil von UEFI? Martin Vaeth <martin@mvath.de> - 2021-04-05 12:27 +0000
Re: Vorteil von UEFI? Matthias Gerds <m.gerds@posteo.de> - 2021-04-05 17:27 +0200
Re: Vorteil von UEFI? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-05 15:32 +0000
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-05 19:50 +0200
Re: Vorteil von UEFI? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-05 18:44 +0000
Re: Vorteil von UEFI? Juergen Ilse <news@usenet-verwaltung.de> - 2021-04-05 16:06 +0000
Re: Vorteil von UEFI? Claus Reibenstein <creibens@gmail.com> - 2021-04-06 17:50 +0200
Re: Vorteil von UEFI? Martin Vaeth <martin@mvath.de> - 2021-04-04 16:03 +0000
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-04 20:08 +0200
Re: Vorteil von UEFI? Juergen Ilse <news@usenet-verwaltung.de> - 2021-04-05 16:32 +0000
Re: Vorteil von UEFI? Martin Vaeth <martin@mvath.de> - 2021-04-05 18:35 +0000
Re: Vorteil von UEFI? Marcus Jodorf <trap@killfile.de> - 2021-04-01 17:39 +0200
Re: Vorteil von UEFI? Marcus Jodorf <trap@killfile.de> - 2021-04-01 17:53 +0200
Re: Vorteil von UEFI? Claus Reibenstein <creibens@gmail.com> - 2021-04-03 16:46 +0200
Re: Vorteil von UEFI? "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-04-01 20:25 +0000
Re: Vorteil von UEFI? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-02 07:08 +0000
Re: Vorteil von UEFI? Matthias Gerds <m.gerds@posteo.de> - 2021-04-02 09:39 +0200
Re: Vorteil von UEFI? Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2021-04-02 10:28 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-02 21:20 +0200
Re: Vorteil von UEFI? Matthias Gerds <m.gerds@posteo.de> - 2021-04-02 21:34 +0200
Re: Vorteil von UEFI? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-02 23:15 +0000
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-03 15:31 +0200
Re: Vorteil von UEFI? Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2021-04-03 01:51 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-03 15:32 +0200
Re: Vorteil von UEFI? Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2021-04-02 10:15 +0200
Re: Vorteil von UEFI? Juergen Ilse <news@usenet-verwaltung.de> - 2021-04-02 09:59 +0000
Re: Vorteil von UEFI? Matthias Gerds <m.gerds@posteo.de> - 2021-04-02 20:24 +0200
Re: Vorteil von UEFI? Helmut Waitzmann <nn.throttle@xoxy.net> - 2021-04-03 02:42 +0200
Re: Vorteil von UEFI? Matthias Gerds <m.gerds@posteo.de> - 2021-04-03 12:04 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-03 15:37 +0200
Re: Vorteil von UEFI? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-02 10:04 +0000
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-02 21:19 +0200
Re: Vorteil von UEFI? "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-04-02 17:33 +0000
Re: Vorteil von UEFI? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-02 23:20 +0000
Re: Vorteil von UEFI? Hermann Riemann <nospam.ng@hermann-riemann.de> - 2021-04-03 05:45 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-03 15:40 +0200
Re: Vorteil von UEFI? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-03 13:46 +0000
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-04 13:10 +0200
Re: Vorteil von UEFI? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-04 23:05 +0000
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-05 09:30 +0200
Re: Vorteil von UEFI? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-05 09:02 +0000
Re: Vorteil von UEFI? klaus reile <klaus.reile@no-mail-today.org> - 2021-04-05 11:42 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-02 21:17 +0200
Re: Vorteil von UEFI? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-02 23:26 +0000
Re: Vorteil von UEFI? Matthias Gerds <m.gerds@posteo.de> - 2021-04-03 12:13 +0200
Re: Vorteil von UEFI? Michael Bäuerle <michael.baeuerle@gmx.net> - 2021-04-03 14:26 +0200
Re: Vorteil von UEFI? Matthias Gerds <m.gerds@posteo.de> - 2021-04-03 14:44 +0200
[OT] Artikelformat (was: Vorteil von UEFI?) Michael Bäuerle <michael.baeuerle@gmx.net> - 2021-04-03 15:22 +0200
Re: Vorteil von UEFI? Sven Hartge <sh-213@svenhartge.de> - 2021-04-03 15:12 +0200
Re: Vorteil von UEFI? Michael Bäuerle <michael.baeuerle@gmx.net> - 2021-04-03 15:51 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-04 13:12 +0200
Re: Vorteil von UEFI? Sven Hartge <sh-213@svenhartge.de> - 2021-04-04 15:40 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-04 16:23 +0200
Re: Vorteil von UEFI? georg.schwarz@freenet.de (Georg Schwarz) - 2021-04-04 17:06 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-04 20:11 +0200
Re: Vorteil von UEFI? georg.schwarz@freenet.de (Georg Schwarz) - 2021-04-05 00:02 +0200
Re: Vorteil von UEFI? Sven Hartge <sh-214@svenhartge.de> - 2021-04-04 18:21 +0200
Re: Vorteil von UEFI? Frank Schletz <frank.schletz@web.de> - 2021-04-03 18:32 +0200
Re: Vorteil von UEFI? Frank Miller <miller@posteo.ee> - 2021-04-04 02:15 +0200
Re: Vorteil von UEFI? Michael Bäuerle <michael.baeuerle@gmx.net> - 2021-04-04 09:45 +0200
Re: Vorteil von UEFI? Sven Hartge <sh-213@svenhartge.de> - 2021-04-04 12:16 +0200
Re: Vorteil von UEFI? Michael Bäuerle <michael.baeuerle@gmx.net> - 2021-04-04 13:13 +0200
Re: Vorteil von UEFI? Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2021-04-04 14:37 +0200
Re: Vorteil von UEFI? Michael Bäuerle <michael.baeuerle@gmx.net> - 2021-04-04 16:12 +0200
Re: Vorteil von UEFI? Juergen Ilse <news@usenet-verwaltung.de> - 2021-04-05 16:59 +0000
Re: Vorteil von UEFI? Michael Bäuerle <michael.baeuerle@gmx.net> - 2021-04-05 20:16 +0200
Re: Vorteil von UEFI? Sven Hartge <sh-213@svenhartge.de> - 2021-04-04 15:49 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-04 16:36 +0200
Re: Vorteil von UEFI? Michael Bäuerle <michael.baeuerle@gmx.net> - 2021-04-04 17:35 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-04 16:30 +0200
Re: Vorteil von UEFI? Paul Muster <exp-311221@news.muster.net> - 2021-04-04 16:49 +0200
Re: Vorteil von UEFI? Martin Vaeth <martin@mvath.de> - 2021-04-04 15:37 +0000
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-04 20:13 +0200
Re: Vorteil von UEFI? Juergen Ilse <news@usenet-verwaltung.de> - 2021-04-05 16:43 +0000
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-03 15:42 +0200
Re: Vorteil von UEFI? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-03 15:14 +0000
Re: Vorteil von UEFI? "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-04-03 20:31 +0000
Re: Vorteil von UEFI? Martin Vaeth <martin@mvath.de> - 2021-04-04 05:29 +0000
Re: Vorteil von UEFI? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-04 06:32 +0000
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-04 13:16 +0200
Re: Vorteil von UEFI? Martin Vaeth <martin@mvath.de> - 2021-04-04 15:18 +0000
Re: Vorteil von UEFI? Sven Hartge <sh-214@svenhartge.de> - 2021-04-04 18:28 +0200
Re: Vorteil von UEFI? Martin Vaeth <martin@mvath.de> - 2021-04-04 17:49 +0000
Re: Vorteil von UEFI? Sven Hartge <sh-214@svenhartge.de> - 2021-04-04 21:58 +0200
Re: Vorteil von UEFI? Sven Hartge <sh-214@svenhartge.de> - 2021-04-05 15:13 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-05 16:25 +0200
Re: Vorteil von UEFI? Sven Hartge <sh-214@svenhartge.de> - 2021-04-05 16:29 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-07 13:14 +0200
Re: Vorteil von UEFI? Sven Hartge <sh-214@svenhartge.de> - 2021-04-07 13:25 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-07 13:48 +0200
Re: Vorteil von UEFI? Sven Hartge <sh-214@svenhartge.de> - 2021-04-07 13:57 +0200
Re: Vorteil von UEFI? Frank Schletz <frank.schletz@web.de> - 2021-04-05 13:34 +0200
Re: Vorteil von UEFI? "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-04-05 20:34 +0000
Re: Vorteil von UEFI? Juergen Ilse <news@usenet-verwaltung.de> - 2021-04-05 17:20 +0000
Re: Vorteil von UEFI? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-05 17:30 +0000
Re: Vorteil von UEFI? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-04-04 21:21 +0200
Re: Vorteil von UEFI? Martin Vaeth <martin@mvath.de> - 2021-04-05 05:41 +0000
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-05 14:52 +0200
Re: Vorteil von UEFI? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-04-06 18:07 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-06 20:48 +0200
Re: Vorteil von UEFI? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-04-07 22:19 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-08 11:10 +0200
Re: Vorteil von UEFI? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-04-08 20:35 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-09 12:06 +0200
Re: Vorteil von UEFI? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-04-10 21:52 +0200
Re: Vorteil von UEFI? Marcus Jodorf <trap@killfile.de> - 2021-04-11 00:30 +0200
Re: Vorteil von UEFI? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-04-11 23:10 +0200
Re: Vorteil von UEFI? Marcus Jodorf <trap@killfile.de> - 2021-04-13 01:06 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-13 18:05 +0200
Re: Vorteil von UEFI? Marcus Jodorf <trap@killfile.de> - 2021-04-13 19:25 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-24 11:09 +0200
Re: Vorteil von UEFI? "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-04-26 16:51 +0000
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-27 09:07 +0200
Re: Vorteil von UEFI? Bernd Mayer <beam.bam.boom@knuut.de> - 2021-04-24 17:57 +0200
Re: Vorteil von UEFI? Marcus Jodorf <trap@killfile.de> - 2021-04-26 22:49 +0200
Re: Vorteil von UEFI? Bernd Mayer <beam.bam.boom@knuut.de> - 2021-04-27 00:05 +0200
Re: Vorteil von UEFI? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-04-14 20:57 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-24 11:14 +0200
Re: Vorteil von UEFI? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-04-24 21:26 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-25 11:18 +0200
Re: Vorteil von UEFI? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-04-25 22:11 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-26 13:03 +0200
Re: Vorteil von UEFI? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-04-05 13:40 +0200
Re: Vorteil von UEFI? Martin Vaeth <martin@mvath.de> - 2021-04-05 14:01 +0000
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-05 16:33 +0200
Re: Vorteil von UEFI? Martin Vaeth <martin@mvath.de> - 2021-04-05 15:47 +0000
Re: Vorteil von UEFI? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-04-07 22:42 +0200
Re: Vorteil von UEFI? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-04 23:53 +0000
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-05 09:32 +0200
Re: Vorteil von UEFI? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-05 09:10 +0000
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-05 13:33 +0200
Re: Vorteil von UEFI? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-05 19:10 +0000
Re: Vorteil von UEFI? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-05 15:19 +0000
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-05 19:53 +0200
Re: Vorteil von UEFI? Juergen Ilse <news@usenet-verwaltung.de> - 2021-04-05 21:17 +0000
Re: Vorteil von UEFI? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-04-04 21:15 +0200
Re: Vorteil von UEFI? "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-04-04 22:16 +0000
Re: Vorteil von UEFI? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-04-05 12:56 +0200
Re: Vorteil von UEFI? Martin Vaeth <martin@mvath.de> - 2021-04-05 12:09 +0000
Re: Vorteil von UEFI? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-04-07 22:55 +0200
Re: Vorteil von UEFI? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-04-05 14:30 +0200
Re: Vorteil von UEFI? Martin Vaeth <martin@mvath.de> - 2021-04-05 15:09 +0000
Re: Vorteil von UEFI? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-04-07 23:27 +0200
Re: Vorteil von UEFI? Martin Vaeth <martin@mvath.de> - 2021-04-08 10:02 +0000
Re: Vorteil von UEFI? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-08 10:22 +0000
Re: Vorteil von UEFI? Robin Garcia Victoria <robin@bawue.de> - 2021-04-12 15:48 +0200
Re: Vorteil von UEFI? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-04-08 21:20 +0200
Re: Vorteil von UEFI? Marcus Jodorf <trap@killfile.de> - 2021-04-09 08:16 +0200
Re: Vorteil von UEFI? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-04-10 21:58 +0200
Re: Vorteil von UEFI? Martin Vaeth <martin@mvath.de> - 2021-04-09 09:26 +0000
Re: Vorteil von UEFI? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-04-10 22:14 +0200
Re: Vorteil von UEFI? Martin Vaeth <martin@mvath.de> - 2021-04-05 08:13 +0000
Re: Vorteil von UEFI? "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-04-04 15:47 +0000
Re: Vorteil von UEFI? Martin Vaeth <martin@mvath.de> - 2021-04-04 17:24 +0000
Re: Vorteil von UEFI? "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-04-04 18:42 +0000
Re: Vorteil von UEFI? Martin Vaeth <martin@mvath.de> - 2021-04-05 07:03 +0000
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-05 09:38 +0200
Re: Vorteil von UEFI? Martin Vaeth <martin@mvath.de> - 2021-04-05 09:22 +0000
Re: Vorteil von UEFI? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-04-05 15:27 +0200
Re: Vorteil von UEFI? Martin Vaeth <martin@mvath.de> - 2021-04-05 18:17 +0000
Re: Vorteil von UEFI? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-04-07 23:46 +0200
Re: Vorteil von UEFI? Martin Vaeth <martin@mvath.de> - 2021-04-08 10:35 +0000
Re: Vorteil von UEFI? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-05 00:12 +0000
Re: Vorteil von UEFI? "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-04-05 14:12 +0000
Re: Vorteil von UEFI? "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-04-05 19:19 +0000
Re: Vorteil von UEFI? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-04-05 15:24 +0000
Re: Vorteil von UEFI? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-04-05 15:30 +0200
Re: Vorteil von UEFI? Marcus Jodorf <trap@killfile.de> - 2021-04-04 21:24 +0200
Re: Vorteil von UEFI? Martin Vaeth <martin@mvath.de> - 2021-04-05 08:24 +0000
Re: Vorteil von UEFI? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-04-05 15:41 +0200
Re: Vorteil von UEFI? Marcus Jodorf <trap@killfile.de> - 2021-04-05 22:52 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-06 07:23 +0200
Re: Vorteil von UEFI? Marcus Jodorf <trap@killfile.de> - 2021-04-06 15:51 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-13 14:51 +0200
Re: Vorteil von UEFI? Marcus Jodorf <trap@killfile.de> - 2021-04-13 18:35 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-15 08:09 +0200
Re: Vorteil von UEFI? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-04-15 19:55 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-17 09:40 +0200
Re: Vorteil von UEFI? Enrik Berkhan <Enrik.Berkhan@inka.de> - 2021-04-13 17:53 +0000
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-15 08:10 +0200
Re: Vorteil von UEFI? Martin Vaeth <martin@mvath.de> - 2021-04-06 08:38 +0000
Re: Vorteil von UEFI? Claus Reibenstein <creibens@gmail.com> - 2021-04-03 16:52 +0200
Re: Vorteil von UEFI? Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2021-03-29 10:40 +0200
Re: Vorteil von UEFI? georg.schwarz@freenet.de (Georg Schwarz) - 2021-03-29 12:05 +0200
Re: Vorteil von UEFI? Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-03-29 22:58 +0200
Re: Vorteil von UEFI? Sven Hartge <sh-213@svenhartge.de> - 2021-03-30 07:41 +0200
Re: Vorteil von UEFI? Marcus Jodorf <trap@killfile.de> - 2021-03-29 21:51 +0200
Re: Vorteil von UEFI? Andreas Kohlbach <ank@spamfence.net> - 2021-03-29 17:02 -0400
Re: Vorteil von UEFI? Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-03-29 23:03 +0200
Re: Vorteil von UEFI? Marcus Jodorf <trap@killfile.de> - 2021-03-30 11:38 +0200
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-03-30 10:02 +0200
Re: Vorteil von UEFI? Tim Ritberg <tim@server.invalid> - 2021-03-30 10:53 +0200
Re: Vorteil von UEFI? Matthias Gerds <m.gerds@posteo.de> - 2021-03-30 13:08 +0200
Re: Vorteil von UEFI? "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-04-03 15:52 +0000
Re: Vorteil von UEFI? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-04-04 13:17 +0200
Re: Vorteil von UEFI? Kay Martinen <usenet@martinen.de> - 2021-04-10 22:43 +0200
Page 7 of 12 — ← Prev page 1 … 5 6 [7] 8 9 … 12 Next page →
| From | Martin Vaeth <martin@mvath.de> |
|---|---|
| Date | 2021-04-04 15:18 +0000 |
| Message-ID | <slrns6jm78.k7ia.martin@clover.invalid> |
| In reply to | #116306 |
Marc Haber <mh+usenetspam1118@zugschl.us> wrote: > Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote: >>==> UEFI ist horrend kompliziert und schlecht dokumentiert! > > Einen rechner über BIOS-Emulation bootfähig zu machen und ihn dann zu > booten ist NICHT einfacher. Doch ist es: Bei BIOS ist ganz klar, welcher Code aus welchem Sektor als Erstes ausgeführt wird, weil das überall dokumentiert ist. Und wie grub selbst von diesem Sektor aus weitermacht, ist ebenfalls (in grub) klar dokumentiert. Die einzige "Dokumentation" bei UEFI scheint jedoch zu sein, irgendwelche riesigen Skripte auszuführen, von denen niemand genau zu wissen scheint, was sie im Detail machen, die 'zig verschiedene Binaries ausführen, die wiederum in UEFI selbst irgendwo rumfuhrwerken (was anscheinend nur dann geht, wenn man vom richtigen Medium bei Mondschein gebootet hat und Saltz hinter sich wirft), und im Problemfall sitzt man dann da und hat mangels Dokumentation keinen Anhaltspunkt, was schief gelaufen sein könnte.
[toc] | [prev] | [next] | [standalone]
| From | Sven Hartge <sh-214@svenhartge.de> |
|---|---|
| Date | 2021-04-04 18:28 +0200 |
| Message-ID | <1h5fe2n3g00lv8@mids.svenhartge.de> |
| In reply to | #116322 |
Martin Vaeth <martin@mvath.de> wrote: > Marc Haber <mh+usenetspam1118@zugschl.us> wrote: >> Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote: >>> ==> UEFI ist horrend kompliziert und schlecht dokumentiert! >> Einen rechner über BIOS-Emulation bootfähig zu machen und ihn dann zu >> booten ist NICHT einfacher. > Doch ist es: Bei BIOS ist ganz klar, welcher Code aus welchem Sektor > als Erstes ausgeführt wird, weil das überall dokumentiert ist. Solange man nur eine Festplatte hat. Ich habe $hier gerade ein System mit 4 HDD (2x RAID1) vor mir, bei welchem die "erste" Platte für das BIOS unter Linux /dev/sdc ist, die zweite ist /dev/sdd, die dritte dann /dev/sda und die vierte /dev/sdb. GRUB ist nur in /dev/sda und /dev/sdb installiert (bisher), weil ich annahm, das dies auch für das BIOS so ist (was üblichweise auch so passt). Booten funktionierte ohne Probleme, weil das BIOS netterweise der Reihe nach alle Platten nach einem brauchbaren MBR absucht und dann startet, hier also dann von der dritten Platte (aka /dev/sda). Du kannst dir die Verwirrung gar nicht vorstellen, als /dev/sdc (also die erste HDD aus Sicht des BIOS) wg. Defekt durch eine andere HDD ausgetauscht wurde und unentdeckterweise noch einen alten MBR beinhaltete und dieser dann zuerst vom BIOS gefunden, gestartet und dann in einer Sackgasse landete. Ja, hätte man vorher besser prüfen sollen. Aber es zeigt, dass es leider nicht immer alles so offensichtlich ist, wie es scheint, selbst bei eigentlich sehr einfachen Mechanismen. S° -- Sigmentation fault. Core dumped.
[toc] | [prev] | [next] | [standalone]
| From | Martin Vaeth <martin@mvath.de> |
|---|---|
| Date | 2021-04-04 17:49 +0000 |
| Message-ID | <slrns6jv1g.kbs8.martin@clover.invalid> |
| In reply to | #116331 |
Sven Hartge <sh-214@svenhartge.de> schrieb: > Martin Vaeth <martin@mvath.de> wrote: > >> Doch ist es: Bei BIOS ist ganz klar, welcher Code aus welchem Sektor >> als Erstes ausgeführt wird, weil das überall dokumentiert ist. > > Solange man nur eine Festplatte hat. Auch dann ist es klar dokumentiert. Ob man das beachtet und daran denkt, ist eine andere Frage. > Ja, hätte man vorher besser prüfen sollen. WIMRE kann man Bootmedien-Reihenfolgen auch mit (U)EFI festlegen. Das Problem ist dann mit (U)EFI unverändert (wenn die neue Platte eine "passende" EFI-Partition hat). > Aber es zeigt, dass es leider nicht immer alles so offensichtlich ist, > wie es scheint, selbst bei eigentlich sehr einfachen Mechanismen. Vor allem zeigt es, dass man Komplexität möglichst meiden sollte. Und UEFI ist da gerade ein Schritt in die gegenteilige Richtung, und eben obendrein anscheinend nur durch den Source-Code selbst dokumentiert.
[toc] | [prev] | [next] | [standalone]
| From | Sven Hartge <sh-214@svenhartge.de> |
|---|---|
| Date | 2021-04-04 21:58 +0200 |
| Message-ID | <3h5fqhr3g00lv8@mids.svenhartge.de> |
| In reply to | #116335 |
Martin Vaeth <martin@mvath.de> wrote: > Sven Hartge <sh-214@svenhartge.de> schrieb: >> Aber es zeigt, dass es leider nicht immer alles so offensichtlich >> ist, wie es scheint, selbst bei eigentlich sehr einfachen >> Mechanismen. > Vor allem zeigt es, dass man Komplexität möglichst meiden sollte. Und > UEFI ist da gerade ein Schritt in die gegenteilige Richtung, und eben > obendrein anscheinend nur durch den Source-Code selbst dokumentiert. Mißverstehe mich nicht, ich sage nicht, das bei UEFI alles Sonnenschein ist, z.B. ist es, im Gegensatz zu Legacy-BIOS, extrem nervig einen redundaten Bootloader zu haben, weil man die ESP nicht wirklich einfach verRAIDen kann. Ich sage nur, das es in allen Varianten Fußangeln gibt, die man kennen muss, wenn man nicht im unpassendsten Moment reinfallen will und das hat mit Komplexität oder dem Fehlen der solchen nicht immer etwas zu tun. S! -- Sigmentation fault. Core dumped.
[toc] | [prev] | [next] | [standalone]
| From | Sven Hartge <sh-214@svenhartge.de> |
|---|---|
| Date | 2021-04-05 15:13 +0200 |
| Message-ID | <4h5hn673g00lv8@mids.svenhartge.de> |
| In reply to | #116351 |
Frank Schletz <frank.schletz@web.de> wrote: > On Sun, 04 Apr 2021 21:58:04 +0200, Sven Hartge wrote: >> Martin Vaeth <martin@mvath.de> wrote: >>> Sven Hartge <sh-214@svenhartge.de> schrieb: >>>> Aber es zeigt, dass es leider nicht immer alles so offensichtlich >>>> ist, wie es scheint, selbst bei eigentlich sehr einfachen >>>> Mechanismen. >> >>> Vor allem zeigt es, dass man Komplexität möglichst meiden sollte. >>> Und UEFI ist da gerade ein Schritt in die gegenteilige Richtung, und >>> eben obendrein anscheinend nur durch den Source-Code selbst >>> dokumentiert. >> >> Mißverstehe mich nicht, ich sage nicht, das bei UEFI alles >> Sonnenschein ist, z.B. ist es, im Gegensatz zu Legacy-BIOS, extrem >> nervig einen redundaten Bootloader zu haben, weil man die ESP nicht >> wirklich einfach verRAIDen kann. > ver-LUKS-en wohl auch nicht? Nein, es sei denn, jemand bringt dem UEFI LUKS bei. Was ich für meinen Laptop gemacht habe, ist Secure Boot an zu lassen, damit niemand zu einfach einen falschen GRUB-Stub mir unterjubeln kann und habe dafür dann /boot ver-LUKSv1-st, damit GRUB damit umgehen kann (der kann leider bisher noch kein LUKSv2). S° -- Sigmentation fault. Core dumped.
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2021-04-05 16:25 +0200 |
| Message-ID | <s4f6k1$212$1@news1.tnib.de> |
| In reply to | #116376 |
Sven Hartge <sh-214@svenhartge.de> wrote: >Was ich für meinen Laptop gemacht habe, ist Secure Boot an zu lassen, >damit niemand zu einfach einen falschen GRUB-Stub mir unterjubeln kann >und habe dafür dann /boot ver-LUKSv1-st, damit GRUB damit umgehen kann >(der kann leider bisher noch kein LUKSv2). Hast Du das irgendwo mal zusammengefasst? 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 | Sven Hartge <sh-214@svenhartge.de> |
|---|---|
| Date | 2021-04-05 16:29 +0200 |
| Message-ID | <5h5hrlo3g00lv8@mids.svenhartge.de> |
| In reply to | #116425 |
Marc Haber <mh+usenetspam1118@zugschl.us> wrote: > Sven Hartge <sh-214@svenhartge.de> wrote: >> Was ich für meinen Laptop gemacht habe, ist Secure Boot an zu lassen, >> damit niemand zu einfach einen falschen GRUB-Stub mir unterjubeln >> kann und habe dafür dann /boot ver-LUKSv1-st, damit GRUB damit >> umgehen kann (der kann leider bisher noch kein LUKSv2). > Hast Du das irgendwo mal zusammengefasst? Ich bin auch nur einer Anleitung gefolgt: https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html Ich habe mich dabei für das Beibehalten des separaten /boot entschieden, weil ich / nicht auf LUKSv1 downgraden wollte. Ich habe aber /boot noch zusätzlich via Keyfile freigeschaltet, damit ich die Passworte beim Booten nicht drei Mal eintippen muss. S° -- Sigmentation fault. Core dumped.
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2021-04-07 13:14 +0200 |
| Message-ID | <s4k465$6cb$1@news1.tnib.de> |
| In reply to | #116426 |
Sven Hartge <sh-214@svenhartge.de> wrote: >Marc Haber <mh+usenetspam1118@zugschl.us> wrote: >> Sven Hartge <sh-214@svenhartge.de> wrote: > >>> Was ich für meinen Laptop gemacht habe, ist Secure Boot an zu lassen, >>> damit niemand zu einfach einen falschen GRUB-Stub mir unterjubeln >>> kann und habe dafür dann /boot ver-LUKSv1-st, damit GRUB damit >>> umgehen kann (der kann leider bisher noch kein LUKSv2). > >> Hast Du das irgendwo mal zusammengefasst? > >Ich bin auch nur einer Anleitung gefolgt: >https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html Schöne Doku. Steht jetzt aber nichts raketenwissenschaftliches drin, das ist ja alles angenehm straightforward. Nur das Überhelfen eines eigenen Tastaturlayouts über den grub ist, äh, komplex. Vor dem Hintergrund, dass grub eigentlich nur noch Memory Management und Multitasking zum eigenen Betriebssystem fehlt, erstaunt mich, dass das _so_ kompliziert ist. >Ich habe aber /boot noch zusätzlich via Keyfile freigeschaltet, damit >ich die Passworte beim Booten nicht drei Mal eintippen muss. Ich habe sowieso die LVs einzeln verschlossen und müsste für jede LV einen Key eintippe, daher habe ich sowieso Keyfiles. 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 | Sven Hartge <sh-214@svenhartge.de> |
|---|---|
| Date | 2021-04-07 13:25 +0200 |
| Message-ID | <6h5mpfv3g00lv8@mids.svenhartge.de> |
| In reply to | #116516 |
Marc Haber <mh+usenetspam1118@zugschl.us> wrote: > Sven Hartge <sh-214@svenhartge.de> wrote: >> Marc Haber <mh+usenetspam1118@zugschl.us> wrote: >>> Sven Hartge <sh-214@svenhartge.de> wrote: >>>> Was ich für meinen Laptop gemacht habe, ist Secure Boot an zu >>>> lassen, damit niemand zu einfach einen falschen GRUB-Stub mir >>>> unterjubeln kann und habe dafür dann /boot ver-LUKSv1-st, damit >>>> GRUB damit umgehen kann (der kann leider bisher noch kein LUKSv2). >> >>> Hast Du das irgendwo mal zusammengefasst? >> >> Ich bin auch nur einer Anleitung gefolgt: >> https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html > Schöne Doku. Steht jetzt aber nichts raketenwissenschaftliches drin, > das ist ja alles angenehm straightforward. Korrekt. Dennoch habe ich es beim ersten Versuch geschafft den falschen (und einzigen) Keyslot von dem LUKS zu entfernen, in dem / liegt. Dadurch hatte ich dann ein *extrem* sicheres System erlangt und eine Neu-Installation gewonnen. Glücklicherweise hatte ich sonst noch nichts am System gemacht, so dass ich außer ein wenig Zeit nichts verloren hatte. Trotzdem für alle natürlich die Warnung: Wer mit LUKS arbeitet sollte wissen, was er macht. Sonst sind die Daten schnell nur noch Rauschen. > Nur das Überhelfen eines eigenen Tastaturlayouts über den grub ist, > äh, komplex. Ich behelfe mir damit, dass die Passphrase für /boot keine Zeichen beinhaltet, die im US-Layout nicht an der gleichen Stelle bei beim DE-Layout sind. >> Ich habe aber /boot noch zusätzlich via Keyfile freigeschaltet, damit >> ich die Passworte beim Booten nicht drei Mal eintippen muss. > Ich habe sowieso die LVs einzeln verschlossen und müsste für jede LV > einen Key eintippe, daher habe ich sowieso Keyfiles. Für den Laptop habe ich mir die Mühe nicht gemacht. Ein LV für / mit allem und ein separates LV für Swap, die Verschlüsselung dann unterhalb des PVs, so wie es der Debian-Installer automagisch macht. S° -- Sigmentation fault. Core dumped.
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2021-04-07 13:48 +0200 |
| Message-ID | <s4k671$ash$1@news1.tnib.de> |
| In reply to | #116517 |
Sven Hartge <sh-214@svenhartge.de> wrote: >Dennoch habe ich es beim ersten Versuch geschafft den falschen (und >einzigen) Keyslot von dem LUKS zu entfernen, in dem / liegt. Das lässt cryptsetup doch gar nicht zu? >Trotzdem für alle natürlich die Warnung: Wer mit LUKS arbeitet sollte >wissen, was er macht. Sonst sind die Daten schnell nur noch Rauschen. Ja. Auch nett: Wenn man den Key in cryptsetup luksFormat hineinpiped, entfällt die Sicherheitsabfrage, wenn man ein bereits bespieltes Laufwerk luksFormattet, die man sonst mti YES anbrüllen muss. Also besser den Devicenamen dreimal gegenprüfen, und zwar BEVOR man das Kommando wegschickt. Ja, auch das wurde durch Schmerz gelernt. >> Nur das Überhelfen eines eigenen Tastaturlayouts über den grub ist, >> äh, komplex. > >Ich behelfe mir damit, dass die Passphrase für /boot keine Zeichen >beinhaltet, die im US-Layout nicht an der gleichen Stelle bei beim >DE-Layout sind. Pragmatisch, ja. >>> Ich habe aber /boot noch zusätzlich via Keyfile freigeschaltet, damit >>> ich die Passworte beim Booten nicht drei Mal eintippen muss. > >> Ich habe sowieso die LVs einzeln verschlossen und müsste für jede LV >> einen Key eintippe, daher habe ich sowieso Keyfiles. > >Für den Laptop habe ich mir die Mühe nicht gemacht. Ein LV für / mit >allem und ein separates LV für Swap, die Verschlüsselung dann unterhalb >des PVs, so wie es der Debian-Installer automagisch macht. Ich hab halt noch eine LV mit der Buchhaltung, dann diverse VMs verschiedener Geheimhaltungsstufen etc bla. 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 | Sven Hartge <sh-214@svenhartge.de> |
|---|---|
| Date | 2021-04-07 13:57 +0200 |
| Message-ID | <7h5mr8c3g00lv8@mids.svenhartge.de> |
| In reply to | #116518 |
Marc Haber <mh+usenetspam1118@zugschl.us> wrote: > Sven Hartge <sh-214@svenhartge.de> wrote: >> Dennoch habe ich es beim ersten Versuch geschafft den falschen (und >> einzigen) Keyslot von dem LUKS zu entfernen, in dem / liegt. > Das lässt cryptsetup doch gar nicht zu? Frag mich nicht, wie. Zumindest konnte ich danach mit nichts eine Entschlüsselung mehr vornehmen. Tiefer diagnostiziert habe ich das dann aber nicht mehr, eine Neuinstallation war schneller und einfacher. >>>> Ich habe aber /boot noch zusätzlich via Keyfile freigeschaltet, >>>> damit ich die Passworte beim Booten nicht drei Mal eintippen muss. >> >>> Ich habe sowieso die LVs einzeln verschlossen und müsste für jede LV >>> einen Key eintippe, daher habe ich sowieso Keyfiles. >> >> Für den Laptop habe ich mir die Mühe nicht gemacht. Ein LV für / mit >> allem und ein separates LV für Swap, die Verschlüsselung dann >> unterhalb des PVs, so wie es der Debian-Installer automagisch macht. > Ich hab halt noch eine LV mit der Buchhaltung, dann diverse VMs > verschiedener Geheimhaltungsstufen etc bla. Die liegen in meinem Fall in "meinem" Datacenter (also, nicht die Buchhaltung)), der Laptop ist praktisch nur ein Terminal mit Notlaufeigenschaften für den Rest der IT. Aber andere Personen, andere Aufgaben, andere Vorgaben. S° -- Sigmentation fault. Core dumped.
[toc] | [prev] | [next] | [standalone]
| From | Frank Schletz <frank.schletz@web.de> |
|---|---|
| Date | 2021-04-05 13:34 +0200 |
| Message-ID | <o69rjh-2q6.ln1@bechenservnew.suchdirwasaus.de> |
| In reply to | #116351 |
On Sun, 04 Apr 2021 21:58:04 +0200, Sven Hartge wrote: > Martin Vaeth <martin@mvath.de> wrote: >> Sven Hartge <sh-214@svenhartge.de> schrieb: > >>> Aber es zeigt, dass es leider nicht immer alles so offensichtlich >>> ist, wie es scheint, selbst bei eigentlich sehr einfachen >>> Mechanismen. > >> Vor allem zeigt es, dass man Komplexität möglichst meiden sollte. Und >> UEFI ist da gerade ein Schritt in die gegenteilige Richtung, und eben >> obendrein anscheinend nur durch den Source-Code selbst dokumentiert. > > Mißverstehe mich nicht, ich sage nicht, das bei UEFI alles Sonnenschein > ist, z.B. ist es, im Gegensatz zu Legacy-BIOS, extrem nervig einen > redundaten Bootloader zu haben, weil man die ESP nicht wirklich einfach > verRAIDen kann. > ver-LUKS-en wohl auch nicht? > Ich sage nur, das es in allen Varianten Fußangeln gibt, die man kennen > muss, wenn man nicht im unpassendsten Moment reinfallen will und das hat > mit Komplexität oder dem Fehlen der solchen nicht immer etwas zu tun. > Na, wenn es mal möglich ist, eine Platte als *eine* Partition, vollverschlüsselt mit UEFI aufzumachen und davon zu booten. Dann werde ich UEFI-Fanboi :D Ansonsten sehe ich da auch kaum unterschied. Naja, mein UEFI-System wollte 3 Partitionen (UEFI, Boot, Luks) und der "alte" Bios-Rechner nur 2 (Boot, Luks). Ich steh gar nicht auf dieses "viele Partitionen", wie manche hier. Oder bin ich blond und habe da was überlesen und UEFI kann Luks aufsperren? Frank
[toc] | [prev] | [next] | [standalone]
| From | "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> |
|---|---|
| Date | 2021-04-05 20:34 +0000 |
| Message-ID | <161765487324.64712.3345187270137709337.XPN@ID-37099.user.uni-berlin.de> |
| In reply to | #116331 |
Ulli Horlacher schrieb am 5/4/2021 19:30: > Juergen Ilse <news@usenet-verwaltung.de> wrote: > >> Das klassische PC-BIOS bootet immer den ersten Sektor der ersten Platte >> (erste Platte laut BIOS-Numerierung). Furchtbar einfach und furchtbar >> unflexibel. > > Bei den BIOSe von Dell und Fujitsu kann man die Boot-Platte auswaehlen. Diese Platte wird dabei zur ersten Platte und deren erster Sektor wird ausgeführt. Das Ganze wurde wohl für DOS eingeführt, weil DOS selbst als Windoof 98 zu blöd war, um von der zweiten Platte zu booten. -- Gerald
[toc] | [prev] | [next] | [standalone]
| From | Juergen Ilse <news@usenet-verwaltung.de> |
|---|---|
| Date | 2021-04-05 17:20 +0000 |
| Message-ID | <606b46cf$0$32756$7b62cf90@news1.net.de> |
| In reply to | #116331 |
Hallo, Sven Hartge <sh-214@svenhartge.de> wrote: > Martin Vaeth <martin@mvath.de> wrote: >> Marc Haber <mh+usenetspam1118@zugschl.us> wrote: >>> Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote: > >>>> ==> UEFI ist horrend kompliziert und schlecht dokumentiert! > >>> Einen rechner über BIOS-Emulation bootfähig zu machen und ihn dann zu >>> booten ist NICHT einfacher. > >> Doch ist es: Bei BIOS ist ganz klar, welcher Code aus welchem Sektor >> als Erstes ausgeführt wird, weil das überall dokumentiert ist. > > Solange man nur eine Festplatte hat. Das klassische PC-BIOS bootet immer den ersten Sektor der ersten Platte (erste Platte laut BIOS-Numerierung). Furchtbar einfach und furchtbar unflexibel. Dieser erste Sektor laedt dann den naechsten Bootloader- Stage nach und fuehrt ihn aus. Tschuess, Juergen Ilse (juergen@usenet-verwaltung.de)
[toc] | [prev] | [next] | [standalone]
| From | Ulli Horlacher <framstag@rus.uni-stuttgart.de> |
|---|---|
| Date | 2021-04-05 17:30 +0000 |
| Message-ID | <s4fhge$u11$1@news2.informatik.uni-stuttgart.de> |
| In reply to | #116442 |
Juergen Ilse <news@usenet-verwaltung.de> wrote: > Das klassische PC-BIOS bootet immer den ersten Sektor der ersten Platte > (erste Platte laut BIOS-Numerierung). Furchtbar einfach und furchtbar > unflexibel. Bei den BIOSe von Dell und Fujitsu kann man die Boot-Platte auswaehlen. Nur HP kann das (wieder mal) nicht. -- Ullrich Horlacher Server und Virtualisierung Rechenzentrum TIK Universitaet Stuttgart E-Mail: horlacher@tik.uni-stuttgart.de Allmandring 30a Tel: ++49-711-68565868 70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
[toc] | [prev] | [next] | [standalone]
| From | Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> |
|---|---|
| Date | 2021-04-04 21:21 +0200 |
| Message-ID | <20210404212156.57cdd3b3@Achmuehle.WOR> |
| In reply to | #116322 |
Hallo Martin, Du schriebst am Sun, 4 Apr 2021 15:18:48 +0000 (UTC): > > Einen rechner über BIOS-Emulation bootfähig zu machen und ihn dann zu > > booten ist NICHT einfacher. > > Doch ist es: Bei BIOS ist ganz klar, welcher Code aus welchem Sektor > als Erstes ausgeführt wird, weil das überall dokumentiert ist. Und wie Und das ist _einfach_? Und daß unter EFI dafür ein EFI-ausführbarer System-Kernel in einem bestimmten Verzeichnis auf der dafür extra eingerichteten EFI-Partition benutzt wird, der überdies noch aus einer Tabelle entweder aus den Einstellungs-Dialogen oder separat aus einer Liste der bootbaren System ausgewählt werden kann, ist so kompliziert, daß es sogar die hier versammelten Systemspezialisten nicht hinkriegen? > grub selbst von diesem Sektor aus weitermacht, ist ebenfalls (in grub) > klar dokumentiert. Die einzige "Dokumentation" bei UEFI scheint jedoch So wie es auch (in grub) dokumentiert ist, wie _der_ vom UEFI gestartet wird - nämlich exakt genauso wie jedes andere System, aus seinem dafür eingerichteten Verzeichnis in der EFI-Patition als EFI-ausführbares Programm, meist namens "grub.efi". > zu sein, irgendwelche riesigen Skripte auszuführen, von denen niemand > genau zu wissen scheint, was sie im Detail machen, die 'zig > verschiedene Binaries ausführen, die wiederum in UEFI selbst irgendwo > rumfuhrwerken (was anscheinend nur dann geht, wenn man vom richtigen > Medium bei Mondschein gebootet hat und Saltz hinter sich wirft), und > im Problemfall sitzt man dann da und hat mangels Dokumentation keinen > Anhaltspunkt, was schief gelaufen sein könnte. Das ist offenbar ein Debianisches Spezialproblem. -- -- (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 | Martin Vaeth <martin@mvath.de> |
|---|---|
| Date | 2021-04-05 05:41 +0000 |
| Message-ID | <slrns6l8pi.ktoj.martin@clover.invalid> |
| In reply to | #116353 |
Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> schrieb: >> >> Doch ist es: Bei BIOS ist ganz klar, welcher Code aus welchem Sektor >> als Erstes ausgeführt wird, weil das überall dokumentiert ist. Und wie > > Und das ist _einfach_? Einfach, weil dokumentiert und weil es so funktioniert, wie dokumentiert. > Und daß unter EFI dafür ein EFI-ausführbarer System-Kernel in einem > bestimmten Verzeichnis auf der dafür extra eingerichteten EFI-Partition > benutzt wird, der überdies noch aus einer Tabelle entweder aus den > Einstellungs-Dialogen oder separat aus einer Liste der bootbaren System > ausgewählt werden kann, ist so kompliziert, daß es sogar die hier > versammelten Systemspezialisten nicht hinkriegen? Weil dem offensichtlich nicht so ist: ja. Wie gesagt: Ich habe 2 volle Tage verschiedenste Dateien unter verschiedensten Namen auf diese EFI-Partition kopiert, und *niemals* wurde irgendetwas davon als startbar entdeckt, und kein Experte konnte mir helfen. Offensichtlich liegt es aber nicht am System, denn einmaliges Ausführen des Ubuntu-Installers tut es. > So wie es auch (in grub) dokumentiert ist, wie _der_ vom UEFI gestartet > wird - nämlich exakt genauso wie jedes andere System, aus seinem dafür > eingerichteten Verzeichnis in der EFI-Patition als EFI-ausführbares > Programm, meist namens "grub.efi". Dokumentiert, aber offensichtlich deutlcih unvollständig: Ansonsten wäre es ja kein Problem, ein UEFI-System aus dem BIOS-Modus heraus zu installieren - es heißt aber überall nur lapidar, dass das nicht möglich sei. >> zu sein, irgendwelche riesigen Skripte auszuführen, von denen niemand >> genau zu wissen scheint, was sie im Detail machen, die 'zig >> verschiedene Binaries ausführen, die wiederum in UEFI selbst irgendwo >> rumfuhrwerken (was anscheinend nur dann geht, wenn man vom richtigen >> Medium bei Mondschein gebootet hat und Saltz hinter sich wirft), und >> im Problemfall sitzt man dann da und hat mangels Dokumentation keinen >> Anhaltspunkt, was schief gelaufen sein könnte. > > Das ist offenbar ein Debianisches Spezialproblem. Das hat nichts mit Debian zu tun: Wie Du an dem Ratschlag vorher siehst, ist der einzige Dokumentation zur Installation von grub ein grub-install. Und wie Du dort nachlesen kannst, funktioniert das für viele bereits nicht, sondern sie brauchen zusätzlich ein dubioses grub-install recheck, von dem anscheinend schon niemend genau weiß, wieso das bei manchen hilft.
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2021-04-05 14:52 +0200 |
| Message-ID | <s4f15q$ngd$1@news1.tnib.de> |
| In reply to | #116365 |
Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> wrote: >Doch, das hat mit Debian zu tun, weil das nochmal ein Bündel Skripte um >die sowieso schon überflüssig umfangreichen Einrichtungs-Skritpe von grub >selber wickelt. Tut es? -- -------------------------------------- !! 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 | 2021-04-06 18:07 +0200 |
| Message-ID | <20210406180736.32577b43@Achmuehle.WOR> |
| In reply to | #116374 |
Hallo Marc, Du schriebst am Mon, 05 Apr 2021 14:52:10 +0200: > >Doch, das hat mit Debian zu tun, weil das nochmal ein Bündel Skripte um > >die sowieso schon überflüssig umfangreichen Einrichtungs-Skritpe von grub > >selber wickelt. > > Tut es? Zumindest gibt es anscheinend, neben der Auto-Konfiguration, die erstmal alles - nach natürlich rein benutzer-orientierten Gesichtspunkten - selbständig einrichtet, auch noch wenigstens ein eigenes Installations- Skript namens "install-grub", das der Debianer nutzen soll anstelle des grub-eigenen "grub-install" (das es dann wohl intern irgendwo doch aufruft). Aber wer's so mag, warum nicht. -- -- (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 | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2021-04-06 20:48 +0200 |
| Message-ID | <s4iad6$hgr$1@news1.tnib.de> |
| In reply to | #116499 |
Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> wrote: >noch wenigstens ein eigenes Installations- >Skript namens "install-grub", das der Debianer nutzen soll anstelle des >grub-eigenen "grub-install" (das es dann wohl intern irgendwo doch aufruft). Eine Datei namens "install-grub" ist in aktuellem Debian nicht enthalten. Ich erinnere mich an sowas doppelt gemoppeltes aus grub 0.9-Zeiten, da war der Upstream aber geradezu spartanisch. 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]
Page 7 of 12 — ← Prev page 1 … 5 6 [7] 8 9 … 12 Next page →
Back to top | Article view | de.comp.os.unix.linux.misc
csiph-web