Beiträge von Alpha

Hast du eigentlich ein 64-Bit oder 32-Bit Windows?

Zitat von DosAmp

Aber in dem Falle wohl die einzige Lösung, wenn man sowohl Linux als auch Windows mit Secure Boot parallel booten möchte?

Warum?
UEFI ist dein Boot Manager. Dort hinterlegst du den "Windows Boot Manager" (bzw. macht das Windows-Setup) und deinen "Linux Kernel" (mittels efibootmgr) als Booteinträge, welche gestartet werden.
So handhabe ich es hier. Mit F12 kann ich beim Starten vom PC mein Bootmenu vom UEFI aufrufen und Linux alternativ starten, da Windows als erstes eingetragen ist.

GRUB ist absolut nicht notwendig, bzw. braucht man im Prinzip mit UEFI überhaupt nicht mehr..

[EDIT]
Ubuntu ist ein Sonderfall. Deren siginierter GRUB2 ist gepatched! Wenn der GRUB2 keinen signierten Kernel von Canonical bekommt, kann er nichts booten! Damit wird Secure Boot sogesehen nicht ausgebelt.. Das könnte man sicher patchen, dass eigene Schlüssel siginiert werden.

Zitat von gandro

On-Topic: Wie machst du das mit der Initramdisk?

Wie genau meinst du das? Ich habe eine initramfs im Einsatz, weil LUKS. Gibt zwei Optionen. Entweder direkt in den Kernel miteinkompilieren oder im UEFI mitübergeben. Ich mache ersteres.. zweiteres sollte aber kein Problem sein. Mit efibootmgr einfach diese angeben:

efibootmgr --create --disk sda --part 1 --label "Gentoo Linux" --loader '\efi\gentoo\boot\kernel.efi' -u initrd='\efi\gentoo\boot\initramfs.img'

Oder worauf willst du hinaus?

Zitat von gandro

Off-Topic: Ich finde, Microsoft verdient hier eher Lob. Es ist Microsoft zu verdanken, dass man auf ausnahmsweise jedem UEFI die Microsoft-Schlüssel löschen und eigene einbauen kann. Damit man Geräte mit Windows-Aufkleber verkaufen darf, muss man dem User erlauben, seine eigenen Secureboot-Zertifikate zu installieren.

Jede Wette, dass wenn Microsoft diese Klausel nicht hätte, dass viele Hersteller solche Funktionen selber gar nicht einbauen würden. Und würde Microsoft Secureboot nicht erzwingen, glaube ich hätten wir das auch nicht.

Kurzum: Würde Microsoft die Secureboot-Regeln den Herstellern überlassen, wäre die Situation vermutlich noch viel schlimmer.

Leider (nicht mehr) so ganz richtig Bis Windows 8.1 stand das genauso drin, wie du es schreibst. Mit Windows 10 ist es nur noch optional seitens Microsoft und damit ist man vom Hersteller abhängig..

Zitat von mrshadowtux

Zum Glück kann man das noch im BIOS abschalten, die Frage ist halt wie lange noch. Wenn es die Abschaltoption in Zukunft nicht mehr gibt, kann dieses Tutorial durchaus nützlich sein.

Entscheidend ist, ob man Secure Boot in den Setup-Mode kriegt. Wenn das nicht geht und Secure Boot nicht abschaltbar ist, hat man verloren.
Worst Case Szenario wäre sonst, dass man sich den signierten GRUB von Ubuntu klaut, der ist mit einem Microsoft Key signiert.. aber das ist ziemlich unschön, finde ich..

Sofern es jemanden interessiert, hier ein kleines Howto, um Secure Boot einzurichten.
Ich gehe davon aus, dass euer System bereits mit UEFI lauffähig ist.

Vorbereitungen
Ihr müsst die efitools und efibootmgr installieren.
Im Regelfall sollte eure Distribution diese mitbringen oder als Paket anbieten.

Sicherung
Im ersten Schritt sollten die aktuellen Keys gesichert werden.

mkdir -p /etc/efi
chmod 700 /etc/efi
efi-readvar -v PK -o /etc/efi/old_PK.esl
efi-readvar -v KEK -o /etc/efi/old_KEK.esl
efi-readvar -v db -o /etc/efi/old_db.esl
efi-readvar -v dbx -o /etc/efi/old_dbx.esl
chmod 400 /etc/efi/*.key

Eigene Schlüssel erzeugen
Im nächsten Schritt erzeugen wir unsere eigenen Schlüssel. Der Text innerhalb subj für CN kann frei angepasst werden.

openssl req -new -x509 -newkey rsa:4096 -subj "/CN=My New Platform Key/" -keyout /etc/efi/PK.key -out /etc/efi/PK.crt -days 3650 -nodes -sha512
openssl req -new -x509 -newkey rsa:4096 -subj "/CN=My New Key-Exchange-Key/" -keyout /etc/efi/KEK.key -out /etc/efi/KEK.crt -days 3650 -nodes -sha512
openssl req -new -x509 -newkey rsa:4096 -subj "/CN=My New Kernel-Signing Key/" -keyout /etc/efi/db.key -out /etc/efi/db.crt -days 3650 -nodes -sha512

Secure Boot Schlüssel löschen
Jetzt müsst ihr den Rechner neustarten und im UEFI-Setup die Einstellungen für Secure Boot aufrufen.
Dort sollte es eine Option geben, mit welcher die vorhandenen Schlüssel gelöscht werden.
Bei mir hieß die Option Clear Secure Boot Keys, Secure Boot ist dannach automatisch deaktiviert und sollte sich im Setup-Mode befinden.

Eigene Secure Boot Schlüssel importieren
Startet wieder euere Linux-Distribution und beginnt mit dem Import der alten Schlüssel.

efi-updatevar -e -f /etc/efi/old_KEK.esl KEK
efi-updatevar -e -f /etc/efi/old_db.esl db
efi-updatevar -e -f /etc/efi/old_dbx.esl dbx

Danach kommen die eigenen Schlüssel:

cert-to-efi-sig-list -g "$(uuidgen)" /etc/efi/PK.crt /etc/efi/PK.esl
sign-efi-sig-list -k /etc/efi/PK.key -c /etc/efi/PK.crt PK /etc/efi/PK.esl /etc/efi/PK.auth
efi-updatevar -a -c /etc/efi/KEK.crt KEK
efi-updatevar -a -c /etc/efi/db.crt db
efi-updatevar -f /etc/efi/PK.auth PK

Wenn Ihr efi-readvar ohne weitere Argumente aufruft, solltet Ihr eine Auflistung aller Schlüssel bekommen. Dort muss jetzt auch der neue Schlüssel sichtbar sein.
Nach dem Einspielen der Schlüssel ist Secure Boot wieder im User-Modus und automatisch aktiv!

Kernel signieren
Im letzten Schritt wird jetzt der Kernel mit eurem Schlüssel signiert, damit dieser bei aktivierten Secure Boot validiert werden kann.
sbsign --key /etc/efi/db.key --cert /etc/efi/db.crt --output /Pfad/zum/signierten/bzImage.signed /Pfad/zum/aktuellen/nicht/siginierten/bzImage

Prüft mit efibootmgr -v, wo aktuell eurer Kernel-Eintrag liegt (Die *.efi-Datei). Die *.efi-Datei wird durch das neue bzImage.signed ersetzt.
Nach einem Reboot sollte mit aktivierten Secure Boot der Kernel starten.

Backup
Es wäre ratsam, wenn Ihr nach dem erfolgreichen Test ein Dump der neuen Schlüssel zieht, sollte im Falle eines Bios-Updates oder Mainboard-Schadens das Wiederherstellen dieser Schlüssel nötig sein.

efi-readvar -v PK -o /etc/efi/new_PK.esl
efi-readvar -v KEK -o /etc/efi/new_KEK.esl
efi-readvar -v db -o /etc/efi/new_db.esl
efi-readvar -v dbx -o /etc/efi/new_dbx.esl

Wie ich schon geschrieben habe, wird man nicht drum herum kommen, dass man PHP4 neu kompilieren muss. Ich tippe aber stark, dass das reine Kompilieren nicht reichen wird, weil man auch den Quellcode anpassen werden muss, damit es mit aktuellen System lauffähig ist.

Du kannst nicht erwarten, dass wir dir jetzt hier für dich den Quellcode modifizieren und alles anpassen. Das ist deine Aufgabe.

Zitat von Michael_

Wenn der Domain anbieter aber keine Nameserver hat wie es bei einigen wenigen speziellen endungen der fall ist wenn man sie direkt bei der vergabestelle registriert sondern also lediglich 2 felder für nameserver da sind?

Also ich weiß grad garnicht ob ich da diese möglichkeiten habe, ich habe schonmal ne domain von united domains gehabt da ging sowas natürlich alles

In Prinzip müsstest du dann dort die IP von deinem Server angeben, welche dann beim Registrar als zuständiger Server eingetragen wird. Je nach Stelle ist aber ein DNS-Server nicht erlaubt und es müssen mehrere sein.

Aber nun ja.. mach was du willst. DNS betreiben, freue mich schon, wenn dein Server missbraucht wird..

Jetzt sag nicht, der DNS ist nach außen erreichbar o_O

Zitat von mrshadowtux

Bitte kein FTP mehr verwenden, das überträgt Passwörter im Klartext und hat damit das "Sicherhetisniveau" von Telnet!

Implementier lieber SFTP, das verschlüsselt dann auch sicher per SSH. Läßt sich auch unter Windows problemlos einrichten.

FTP mit SSL überträgt auch nix im Klartext..

Da das Binary wohl gegen andere Versionen kompiliert ist, wird das nix.. es sei denn, du kompilierst selbst PHP4 aus den Quellen für Windows..

PHP4? Ernsthaft? ...

Also mit der Aktivierung von simplefb bekomme ich eine Ausgabe schon mal.. dann werde ich mal schauen, was da so los ist mit nouveau.
Wobei mir noch nicht so ganz klar ist, wieso ohne Framebuffer es keine Ausgabe gibt. Eigentlich wäre meine Erwartung, dass es dann vga text 80x25 gibt.. oder geht das nur mit CSM/BIOS und UEFI braucht zwangsweise einen framebuffer?

Zitat von thosch97

Du hast doch sicher einen USB-UART-Adapter zum Konsole da ausgeben?

Ne Mein Mainboard kann kein Seriell. Hab zwar ein USB-RS232 Adapter, aber kein Anschlusskabel grad da.. das braucht ein paar Tage noch, bis ich mir das organisiert habe..

Hallo,
ich versuche neben meinem Windows 10 ein Gentoo auf meiner Kiste mittels UEFI zu installieren.

Das Basissystem ist drauf, alles soweit kompiliert und dazu einen Kernel, welcher Stub-Mode kann, damit mein UEFI diesen direkt booten kann. Nur klappt das nicht so ganz.

Jedenfalls wird etwas gebootet, ich bleibe aber im Bootscreen vom UEFI und das wars.
Ich bin mir aber ziemlich sicher, dass der Kernel bootet. Weil das System mit LUKS verschlüsselt ist, brauche ich meine initrd, damit das Rootdevice entschlüsselt wird.

Wenn ich gezielt ohne initrd boote, kann ich sehen, dass nach 2-3 Sekunden die Tastatur LEDs blinken, was darauf hindeutet, dass ein kernel panic stattgefunden hat. Das macht Sinn, weil ohne initrd das System nicht entschlüsselt werden kann. Nach genau 15 Sekunden rebootet der PC, was passt, weil das der genaue Timeout ist, welchen ich im Kernel konfiguriert habe. Ergo muss der Kernel erfolgreich booten.

Daher gehe ich davon aus, dass selbst mit der initrd der Kernel booten muss, und dort dann auf meine Passworteingabe wartet.

Allerdings habe ich gar keine Ausgabe auf der Grafikkarte, daher fehlt mir so die Idee, was jetzt falsch ist. Ich kann nichts debuggen so.. Vorschläge?

Kernelparamter nomodeset oder FB_CONFIG komplett zu deaktivieren helfen leider nicht.

Wenn ich zuerst GRUB boote, bekomme ich eine Ausgabe von GRUB. Sobald GRUB meinen Kernel bootet, bleibt die Ausgabe von GRUB, aber der Kernel wird auch gebootet, da das Verhalten gleich ist, wie oben beschrieben, wenn ich einen Stub-Kernel boote..

Kernelconfig: https://www.bl4ckb0x.de/files/config-4.4.1-gentoo
Ich sehe nicht so wirklich, was da noch fehlen könnte.. vorallem, weil ich garkeine Ausgabe kriege. Ich kenne das eher so, wenn z.B. KMS Probleme macht, dass zumindest anfang eine Kernelausgabe kommt und es dann im Verlauf hängt..

Danke!

Zitat von Der Doktor

Welche Desktopumgebung eignet sich am besten für HiDPI?

Hab so ein paar Probleme mit meinen VMs, die haben einfach eine sehr kleine UI auf dem Surface. Gnome scheint da nicht so toll zu sein, hab zwar mit dem Tweaking Tool rumhantiert, aber das Window Scaling ließ sich auch per Konsolenbefehl nicht auf was ungerades (aka 1.2 oder so) umstellen. Konnte nur auf 1 oder 2 stellen und 2 war viel viel zu groß. Oder ich habe irgendetwas ziemlich falsch gemacht. System ist Debian 8 mit Gnome 3.
Hab gehört das Xfce ein HiDPI Setting hat. Hat da einer Erfahrung oder sieht was ich vielleicht bei Gnome falsch mache?

https://wiki.archlinux.org/index.php/HiDPI

Native Spiele, wie wärs mit Holiday Island?

Ich sehe das Problem hier nicht. Man kann das Angebot annehmen oder auch nicht.
Da er hier speziell für den Libretto was angepasst hat, ist das okay

Ich kenne aber zu wenig rloew, um es ein schätzen zu können. Meine Erfahrungen waren halt positiv.

Zitat von freaked

Dh damit kann ich ne 80gb win98 und ne 80gb daten partition machn, ohne Fehler?

Nein und Ja Bis 137GB! Also z.B. 80GB Win98 und dann noch max. 57GB für Datenpartition.

Oberhalb von 137GB braucht man Treiber, die Windows 98 nicht hat. Aber auch hierfür gibt es einen Patch. Sag ihm das, dann kriegst du dafür einen Patch, damit Windows 95B/95C/98/98SE auch oberhalb von 137GB arbeiten kann. Dazu brauchst du in jedem Fall DISKBIOS, da das Libretto Bios >= 137GB definitiv nicht ansprechen kann.

Dies ist der Patch dafür: http://rloew.x10host.com/Programs/Patch137.htm
Frag Ihn einfach, er wird dir genau sagen, was du dafür brauchst.

Schreibt ihm eine Mail: http://rloew.x10host.com/

Zitat

Tell them to order BOOTMAN and add a Note to include BOOTMAN8 and PATCHLBA.

Für Libretto reicht dies aus, da eigentlich nur PATCHLBA nötig ist. BOOTMAN ist ein DDO, was von Floppy oder HDD im MBR geladen werden kann. Hilft aber, wenn man dann die Platte im Libretto einrichten will, damit mehr als 8GB partitionierbar ist
Wenn ihr einen Bootmanager eurer Wahl nutzt, sollte es das tun. Ich hab aktuell mein BootIt Bare Metal im Einsatz, weil hier kein DDO umbedingt notwendig ist..
Ich tippe mal, der Windows-Boot-Manager tut es auch.

PATCHLBA muss, wenn man Windows 98B/95C/98/98SE installiert, nach dem ersten Reboot der Installation direkt von Floppy ausgeführt werden, da sonst irgendwann Setup hängt, wenn der IDE-Treiber geladen wird! (Betrifft Installation oberhalb der ersten 8GB)

Zitat

If they order RFDISK, also add a note to include DISKBIOS.OVL.

Das ist der Multi-Boot-Manager, welcher das DISKBIOS auch laden kann, was vor dem Start eines OS geladen wird, damit mehr als 8GB gehen.
Das Trifft aber auf Rechner zu, welche keine erweiterten INT13 haben. Libretto hat es, daher nicht notwendig.

Zitat von Pain

Magst du ihn teilen?

Leider nein. Darf ich nicht
Das liegt daran, weil der Patch im Rahmen für mich speziell entwickelt worden ist.
Ich hatte nämlich dazu auch noch nen speziellen Bootmanger besorgt, welcher ein DDO dazu bekommen hat, damit auf Rechnern ohne erweiterten INT13 auch bis zu 137GB trotzdem möglich sind, ohne dass man Schrott wie Ontrack/EZ-Drive einsetzen muss, welche kein Multiboot können. Waren etwa 20$ für alles zusammen. Das kannst du dir auch dort besorgen, sofern du interesse hast.