staging.inyokaproject.org

syscon-hh schrieb:

Im Prinzip ist dieses ja auch schon immer so - die EFI-Partition muss nicht die erste sein, sollte aber in der Reihenfolge die erste mit VFAT im System sein.

Habt Ihr zu der Aussage im markierten Teil die schon irgendwelche Testreihen gemacht oder diesbezüglich anderweitig Erfahrungen gesammelt?

Ein Problem sehe ich da theoretisch - praktisch noch nicht verifiziert - bei den Datenträgern, bei denen es keine speziell markierte EFI-System-Partition gibt und bei der der EFI-Boot grundsätzlich über den Standard-Loader für externe Medien /efi/boot/bootx64.efi laufen soll.

Sobald es aber eine speziell markierte EFI-System-Partition gibt, muss die Lage der EFI-System-Partition egal sein, andernfalls wäre das IMO gegen die Spezifikation. Denn würde sich das System von vor der EFI-System-Partition liegenden FAT- oder auch NTFS-Partitionen verwirren lassen, dann würde das heißen, dass das Markieren einer FAT-Partition als EFI-System-Partition technisch gar nichts bringen würde.

Besonders auf Windows-Systemen, die ja nur Partitionen verwenden, die für das EFI lesbar sind, würde das dann permanent Probleme verursachen. Die Realität dürfte aber eher die sein, dass alles dafür getan wird, dass ein Windows-EFI sauber startet.

Gruß, Martin

Newubunti schrieb:

Ich hoffe nur, dass in 12.10 - hatte noch keine Zeit zum Forschen - nun die Erkennung von EFI-Systemen gescheit läuft. Das wäre im Moment doch dringender.

Das läuft schon mal mit der Prerelease von Windows 8 nicht. Ich ahne daher nichts gutes. Da bin ich doch einigermaßen verwundert. Was ist so schwer daran, ein EFI-Windows zu erkennen?

Was mich aber eben noch mehr geschockt hat:

Gehe ich bei der 12.10 EFI-Installation auf "etwas anderes" und klicke auf das "+", um eine Partition hinzuzufügen, dann wird mir nun auch angeboten auf einem GPT-Datenträger eine logische Partition zu erstellen. 😬 Was soll denn jetzt der Rotz? Da blickt man ja dann gar nicht mehr durch, um welche Art von Datenträger es sich gerade handelt. 😮

Soll das, das von Dir weiter vorne angesprochene LVM sein? Geht es vielleicht auch noch verwirrender?

Gruß, Martin

Newubunti schrieb:

Newubunti schrieb:

Ich hoffe nur, dass in 12.10 - hatte noch keine Zeit zum Forschen - nun die Erkennung von EFI-Systemen gescheit läuft. Das wäre im Moment doch dringender.

Das läuft schon mal mit der Prerelease von Windows 8 nicht. Ich ahne daher nichts gutes. Da bin ich doch einigermaßen verwundert. Was ist so schwer daran, ein EFI-Windows zu erkennen?

Ich bin da immer noch der Meinung, dass das so sein soll - denn:

• Auswahl anderer EFI-OS soll über das EFI-Menü erfolgen

Was mich aber eben noch mehr geschockt hat:

Gehe ich bei der 12.10 EFI-Installation auf "etwas anderes" und klicke auf das "+", um eine Partition hinzuzufügen, dann wird mir nun auch angeboten auf einem GPT-Datenträger eine logische Partition zu erstellen. 😬 Was soll denn jetzt der Rotz? Da blickt man ja dann gar nicht mehr durch, um welche Art von Datenträger es sich gerade handelt. 😮

Soll das, das von Dir weiter vorne angesprochene LVM sein? Geht es vielleicht auch noch verwirrender?

Nein - dass sehe ich jetzt auch zum ersten mal (bzw. dass hatte ich vorher noch nie registriert). Das kann auch mit LVM nicht's zu tun haben - auch dort sind alle Laufwerke innerhalb eines LVM gleichwertig und wie bei GPT als Partition zu betrachten (also weder "Primär" noch "Logisch").

gruß syscon-hh

syscon-hh schrieb:

Newubunti schrieb: Ich bin da immer noch der Meinung, dass das so sein soll - denn:

• Auswahl anderer EFI-OS soll über das EFI-Menü erfolgen

Das meinte ich mit "Erkennen" erst mal gar nicht. Es geht darum, dass der Installer sagt, es wären keine anderen Betriebssysteme auf dem Computer vorhanden. D.h. ich habe nur:

• Datenträger löschen und Ubuntu installieren.

• Ubuntu verschlüsselt installieren

• Ubuntu in LVM installieren

• etwas anderes

Hier müsste bei einem vorhanden EFI Windows einfach noch stehen:

• Ubuntu neben Windows installieren

Was Du meinst ist, dass nicht automatisch ein Eintrag im GRUB-Menü für Windows erzeugt wird und da stimme ich dann mit Dir überein, dass das wohl nicht gewollt ist und auch nicht unbedingt notwendig. Der Eintrag in Ubiquity ist aber für mich zwingend notwendig.

Nein - dass sehe ich jetzt auch zum ersten mal (bzw. dass hatte ich vorher noch nie registriert). Das kann auch mit LVM nicht's zu tun haben - auch dort sind alle Laufwerke innerhalb eines LVM gleichwertig und wie bei GPT als Partition zu betrachten (also weder "Primär" noch "Logisch").

Ich habe mal eben neben der vorhanden Windows-EFI-Installation Ubuntu laut Installer in ein logisches Laufwerk installiert. Die Folge:

• Es wird ganz normal eine GPT-(Primär)-Partition für Ubuntu angelegt. 🙄

Ich fasse es nicht!

Gruß, Martin

Newubunti schrieb:

Hier müsste bei einem vorhanden EFI Windows einfach noch stehen:

• Ubuntu neben Windows installieren

Das hatte ich ja schon früher (siehe Tabelle, Hinweis) moniert - schlimmer noch, es wird die Installation ohne weitere Zwischenabfrage gestartet - bzw. man muss sehr trickreich die Auswahl der möglichen (ganzen) Platte finden.

Ich habe mal eben neben der vorhanden Windows-EFI-Installation Ubuntu laut Installer in ein logisches Laufwerk installiert. Die Folge:

• Es wird ganz normal eine GPT-(Primär)-Partition für Ubuntu angelegt. 🙄

Ich fasse es nicht!

Das würde ich auch mal als ansehen. M.E. können bei GPT beide Knöpfe deaktiviert sein - mindestens aber sollte es der "Logische"! Dieser Zustand ist aber erst ab Quantal Quetzal drin!

syscon-hh schrieb:

Das hatte ich ja schon früher (siehe Tabelle, Hinweis) moniert - schlimmer noch, es wird die Installation ohne weitere Zwischenabfrage gestartet - bzw. man muss sehr trickreich die Auswahl der möglichen (ganzen) Platte finden.

Ja, das weiß ich schon. Ich dachte aber, dass das auf jeden Fall bis zum Final Release noch gefixt wird. Zumal ich einfach nicht verstehen kann, was daran kompliziert ist.

Na gut, sind ja noch 2 Tage.

Ich habe mal eben neben der vorhanden Windows-EFI-Installation Ubuntu laut Installer in ein logisches Laufwerk installiert. Die Folge:

• Es wird ganz normal eine GPT-(Primär)-Partition für Ubuntu angelegt. 🙄

Ich fasse es nicht!

Das würde ich auch mal als ansehen.

Aber hallo ist das ein BUG!

M.E. können bei GPT beide Knöpfe deaktiviert sein - mindestens aber sollte es der "Logische"!

Es muss einfach nur so sein, wie es in 12.04 bereits war. Ich verstehe überhaupt nicht, wie man da ein Baustelle aufmachen kann, wo es doch gar nichts zu bauen gibt. Das war doch alles in Ordnung, so wie es war.

Dieser Zustand ist aber erst ab Quantal Quetzal drin!

Genau das macht mich so fassungslos. Man macht völlig unnötig eine neue Baustelle auf, obwohl es da im Moment bei Ubiquity weit wichtigere Dinge hinsichtlich EFI zu bearbeiten gäbe.

Ich hoffe ja mal darauf, dass das nur ein Versehen der letzte Tage ist und das wieder raus fliegt bis zum Final Release.

Gruß, Martin

So ich habe mal einen 1067467-Report generiert - kannst ja mal "confirmen". Wird sicherlich nicht mehr in das Release einfließen - aber die nächste Version wartet ja schon 😊

gruß syscon-hh

Größtenteils OT:

syscon-hh schrieb:

So ich habe mal einen 1067467-Report generiert - kannst ja mal "confirmen".

Würde ich gerne machen, aber egal was ich jetzt probiert habe - Anmelden mit den vermeintlich zuletzt genutzten Daten oder Erstellen eines neuen Accounts - ich bekomme die folgende spaßige Meldung ☺ :

Ihre Seite war abgestanden.

Entschuldigung, die Seite von der Sie kamen war ein wenig alt. Vielleicht kamen Sie hier von einem anderen Browser-Fenster her als den, das Sie zur Anmeldung gebraucht haben. Wenn ja, versuchen Sie es mit den anderen Browser-Fenster. Oder versuchen Sie Ihr Handeln wieder, ausgehend von unserer Homepage. Gehen Sie zu unserer Startseite

Cookies löschen, Firefox resetten bzw. alle persönlichen Daten löschen bringt keine Abhilfe. Ich verwende Noscript - vielleicht liegt es daran, aber launchpad.net habe ich da freigegeben und alles, was ich sonst noch auf der Seite freigeben konnte.

Gruß, Martin

EDIT:
OK, habe es hinbekommen. Lag am deaktivierten http-Referer im Firefox. Weil wir gerade bei den BUGs sind, hast Du 1017880 schon confirmed?

Ich habe mir jetzt mal vor der Installation auf dem Live-Stick die /usr/lib/os-probes/20microsoft vorgeknöpft und folgende Änderung gegenüber dem original vorgenommen:

found=
# Vista (previously Longhorn)
if item_in_dir -q bootmgr "$2"; then
	# there might be different boot directories in different case as:
	# boot Boot BOOT
	for boot in $(item_in_dir boot "$2"); do
		bcd=$(item_in_dir bcd "$2/$boot")
		if [ -n "$bcd" ]; then
			if grep -qs "W.i.n.d.o.w.s. .8" "$2/$boot/$bcd"; then
				long="Windows 8 (loader)"
			elif grep -qs "W.i.n.d.o.w.s. .7" "$2/$boot/$bcd"; then
				long="Windows 7 (loader)"
			elif grep -qs "W.i.n.d.o.w.s. .V.i.s.t.a" "$2/$boot/$bcd"; then
				long="Windows Vista (loader)"
			elif grep -qs "W.i.n.d.o.w.s. .S.e.r.v.e.r. .2.0.0.8. .R.2." "$2/$boot/$bcd"; then
				long="Windows Server 2008 R2 (loader)"
			elif grep -qs "W.i.n.d.o.w.s. .S.e.r.v.e.r. .2.0.0.8." "$2/$boot/$bcd"; then
				long="Windows Server 2008 (loader)"
			elif grep -qs "W.i.n.d.o.w.s. .R.e.c.o.v.e.r.y. .E.n.v.i.r.o.n.m.e.n.t" "$2/$boot/$bcd"; then
				long="Windows Recovery Environment (loader)"
			elif grep -qs "W.i.n.d.o.w.s. .S.e.t.u.p" "$2/$boot/$bcd"; then
				long="Windows Recovery Environment (loader)"
			else
				long="Windows Vista (loader)"
			fi
			short=Windows

			found=true

			break
		fi
	done
elif item_in_dir -q efi "$2"; then
	# there might be different boot directories in different case as:
	# boot Boot BOOT
	for boot in $(item_in_dir boot "$2/EFI/Microsoft"); do
		bcd=$(item_in_dir bcd "$2/EFI/Microsoft/$boot")
		if [ -n "$bcd" ]; then
			if grep -qs "W.i.n.d.o.w.s. .8" "$2/EFI/Microsoft/$boot/$bcd"; then
				long="Windows 8 (loader)"
			elif grep -qs "W.i.n.d.o.w.s. .7" "$2/EFI/Microsoft/$boot/$bcd"; then
				long="Windows 7 (loader)"
			elif grep -qs "W.i.n.d.o.w.s. .V.i.s.t.a" "$2/EFI/Microsoft/$boot/$bcd"; then
				long="Windows Vista (loader)"
			elif grep -qs "W.i.n.d.o.w.s. .S.e.r.v.e.r. .2.0.0.8. .R.2." "$2/EFI/Microsoft/$boot/$bcd"; then
				long="Windows Server 2008 R2 (loader)"
			elif grep -qs "W.i.n.d.o.w.s. .S.e.r.v.e.r. .2.0.0.8." "$2/EFI/Microsoft/$boot/$bcd"; then
				long="Windows Server 2008 (loader)"
			elif grep -qs "W.i.n.d.o.w.s. .R.e.c.o.v.e.r.y. .E.n.v.i.r.o.n.m.e.n.t" "$2/EFI/Microsoft/$boot/$bcd"; then
				long="Windows Recovery Environment (loader)"
			elif grep -qs "W.i.n.d.o.w.s. .S.e.t.u.p" "$2/EFI/Microsoft/$boot/$bcd"; then
				long="Windows Recovery Environment (loader)"
			else
				long="Windows Vista (loader)"
			fi
			short=Windows

			found=true

			break
		fi
	done
fi

Neu ist dabei der "elif item_in_dir -q efi "$2"; then"-Teil.

Damit ist es möglich Ubuntu neben Windows-EFI zu installieren. Mir ist dabei klar, dass mein Einschub

1. keine vollständige Lösung des Problems in os-prober darstellt - os-prober macht noch ein wenig mehr.

2. Der Code-Einschub nicht gehärtet ist und Groß-Klein-Schreibungs-Problemen im Pfad /EFI/Microsoft noch nicht standhält.

3. sich das ganze für einen geübten Skripter sicher noch eleganter umsetzen ließe.

Noch ein Hinweis:

Lässt man die Installation mit meiner Änderung durchlaufen, so wird beim Ubuntu-Start nun das GRUB-Menü erst mal angezeigt, allerdings ohne Eintrag für das EFI-Windows - wie gesagt dazu müssten bei os-prober noch ein paar Änderungen vorgenommen werden.

Bei den Skripten in /usr/lib/os-probes verhält es sich wohl genau wie bei denen in /etc/grub.d, d.h. man könnte für das EFI-probing auch ein eigenes Skript erstellen, dass dann abgearbeitet wird und muss nicht - wie ich - im original Skript rumpfuschen.

Ich bin nach wie vor verwundert, dass eine solch einfache Änderung nicht schon längst eingebracht wurden. Natürlich ist das komplette Überarbeiten von os-prober noch komplexer, allerdings bin ich auch im Skripten wirklich keine Leuchte und habe für die Änderung ca. 20 Minuten gebraucht. Und das unter dem Aspekt, dass ich Code nicht schnell lesen kann, sondern eine Zeit dafür brauche.

Gruß, Martin

Ich habe mir jetzt mal vor der Installation auf dem Live-Stick die /usr/lib/os-probes/20microsoft vorgeknöpft und ...

Kann ich im Moment nicht mehr nachvollziehen - bei uns hat ein "Totalverlust" die weitere Arbeit unterbrochen und bis zur Klärung der wahren Gründe sind alle Rechner mit EFI-Boards gesperrt.

Was ist passiert → sicher verfolgbar ist, es wurden über

sudo efibootmgr -b <####> -B 

diverse Einträge im NVRAM von überflüssigen Balast bereinigt. Sofort nach einem Reboot, um nachzusehen, welche Erfolge das hatte, startete der Rechner nicht mehr - wir kommen nicht mal mehr ins BIOS → jetzt müssen erst einmal die Techniker das klären, ob da ein Zusammenhang besteht oder ob es ein reiner Zufall war.

Am Warnhinweis im WIKI efibootmgr scheint also was dran zu sein - mal sehen wie die Untersuchungen ausgehen. Aber Du wolltest hier ja Erfahrungen sammeln - bitte sehr!

gruß syscon-hh

syscon-hh schrieb:

Was ist passiert → sicher verfolgbar ist, es wurden über

sudo efibootmgr -b <####> -B 

diverse Einträge im NVRAM von überflüssigen Balast bereinigt. Sofort nach einem Reboot, um nachzusehen, welche Erfolge das hatte, startete der Rechner nicht mehr - wir kommen nicht mal mehr ins BIOS → jetzt müssen erst einmal die Techniker das klären, ob da ein Zusammenhang besteht oder ob es ein reiner Zufall war.

Waren die bereinigten Einträge solche, die Ihr selbst erstellt hattet und die im NVRAM hängen geblieben sind oder waren das Einträge die von Anfang an im NVRAM vom EFI "selbst erstellt" waren?

Habt Ihr einen BIOS-Resett per Jumper auf dem Board versucht oder dürft Ihr das bei Euch nicht?

Bei welchem Rechner/Board ist Euch das passiert?

Am Warnhinweis im WIKI efibootmgr scheint also was dran zu sein - mal sehen wie die Untersuchungen ausgehen. Aber Du wolltest hier ja Erfahrungen sammeln - bitte sehr!

efibootmgr ist IMO ein unwahrscheinlich schlecht dokumentiertes Werkzeug und diesbezüglich eine Frechheit. Wenn es tatsächlich so risikoreich sein sollte, mit dem Tool den NVRAM zu bearbeiten, dann sollte das peinlichst genau dokumentiert sein - vor allem was wann kritisch ist.

Der Warnhinweis in der Manpage ist ein schlechter Witz. Was soll denn "mit Bedacht einsetzen" heißen, wenn man auf einem EFI-System gezwungen ist am NVRAM zu arbeiten? Ich hasse solche Art der Dokumentation.

Für mich in der Form eine absolut schlechte Dokumentation und so gesehen untauglich Warnung.

Gruß, Martin

Newubunti schrieb:

Waren die bereinigten Einträge solche, die Ihr selbst erstellt hattet und die im NVRAM hängen geblieben sind oder waren das Einträge die von Anfang an im NVRAM vom EFI "selbst erstellt" waren?

Das waren u.a. Einträge, die aus der Installation - auf einer zusätzlich eingehängten - Festplatte mit dem Windows 8 zurückgeblieben waren. Wobei ich / wir annehmen, dass das nicht mit Windows zusammenhängt - es waren auch Einträge, die bei einem Update mit Grub-2.0 entstanden sind. Dieses deshalb, weil wir zur Rettung unser eigenen Einträge im Verzeichnis /EFI/precise den Pfad dorthin mit efibootmgr --create xyz umgeleitet hatten und dann neue ubuntu-Einträge bei den Updates generiert wurden - eigentlich auch korrekt.

Habt Ihr einen BIOS-Resett per Jumper auf dem Board versucht oder dürft Ihr das bei Euch nicht?

Bei welchem Rechner/Board ist Euch das passiert?

Mit dem "Fujitsu" Board aus dem ESPRIMO-E710 und dem "AMI-BIOS". Aber wie gesagt - wir gehen da noch von keinen direkten Zusammenhang sondern eher einem zeitlich zufälligen Ausfall aus. Welche Gegenmaßnahmen die Technik jetzt getroffen hat (außer dem Verbot) - das dauert.

Der Warnhinweis in der Manpage ist ein schlechter Witz. Was soll denn "mit Bedacht einsetzen" heißen, wenn man auf einem EFI-System gezwungen ist am NVRAM zu arbeiten? Ich hasse solche Art der Dokumentation.

Für mich in der Form eine absolut schlechte Dokumentation und so gesehen untauglich Warnung.

Volle Zustimmung - nur von einem Zwang kann man ja nicht reden - wenn man ein Werkzeug an die Hand bekommt, dann sollte man es im Rahmen der vorgegeben Parameter auch nutzen können.

gruß syscon-hh

So ich habe mal weiter an der os-prober-Geschichte gearbeitet und ein eigenes Skript für Microsoft-EFI "erstellt" - war mehr Copy & Paste. Dies verwende ich als /usr/lib/os-probes/mounted/20microsoft-efi:

#!/bin/sh
# Detects Microsoft EFI-Loader on a collection of partitions.

. /usr/share/os-prober/common.sh

partition="$1"
mpoint="$2"
type="$3"

# Weed out stuff that doesn't apply to us
case "$type" in
	ntfs|ntfs-3g) debug "$1 is a NTFS partition" ;;
	vfat) debug "$1 is a FAT32 partition" ;;
	msdos) debug "$1 is a FAT16 partition" ;;
	fat) debug "$1 is a FAT partition (mounted by GRUB)" ;;
	fuse|fuseblk) debug "$1 is a FUSE partition" ;; # might be ntfs-3g
	*) debug "$1 is not a MS partition: exiting"; exit 1 ;;
esac

found=
# Vista (previously Longhorn)
if item_in_dir -q efi "$2"; then
	if [ ! -z "`find "$2" -type f -iname "bootmgfw.efi"`" ]; then
		mspath=$(find "$2" -type d -iname "microsoft")
		# there might be different boot directories in different case as:
		# boot Boot BOOT
		for boot in $(item_in_dir boot "$mspath"); do
			bcd=$(item_in_dir bcd "$mspath/$boot")
			if [ -n "$bcd" ]; then
				if grep -qs "W.i.n.d.o.w.s. .8" "$mspath/$boot/$bcd"; then
					long="Windows 8 (EFI loader)"
				elif grep -qs "W.i.n.d.o.w.s. .7" "$mspath/$boot/$bcd"; then
					long="Windows 7 (EFI loader)"
				elif grep -qs "W.i.n.d.o.w.s. .V.i.s.t.a" "$mspath/$boot/$bcd"; then
					long="Windows Vista (EFI loader)"
				elif grep -qs "W.i.n.d.o.w.s. .S.e.r.v.e.r. .2.0.0.8. .R.2." "$mspath/$boot/$bcd"; then
					long="Windows Server 2008 R2 (EFI loader)"
				elif grep -qs "W.i.n.d.o.w.s. .S.e.r.v.e.r. .2.0.0.8." "$mspath/$boot/$bcd"; then
					long="Windows Server 2008 (EFI loader)"
				elif grep -qs "W.i.n.d.o.w.s. .R.e.c.o.v.e.r.y. .E.n.v.i.r.o.n.m.e.n.t" "$mspath/$boot/$bcd"; then
					long="Windows Recovery Environment (EFI loader)"
				elif grep -qs "W.i.n.d.o.w.s. .S.e.t.u.p" "$mspath/$boot/$bcd"; then
					long="Windows Recovery Environment (EFI loader)"
				else
					long="Windows Vista (EFI loader)"
				fi
				short=Windows

				found=true

				break
			fi
		done
	fi
fi


if [ -z "$found" ]; then
	exit 1
fi

label="$(count_next_label "$short")"
result "${partition}:${long}:${label}:chain"
# We want to allow other os-probes to probe the EFI-System-Partition:
exit 1

Man könnte jetzt noch eigene solche os-probes-Skripte pro Distribution schreiben oder auch für den generischen Loader in /EFI/Boot. Möglich wäre auch, dass man in der result-Zeile am Ende, vielleicht das "chain" gegen "efi-chain" austauscht, um von den Bootloader-Skripten das besser auswerten zu können. Das habe ich mir aber noch nicht angeschaut.

Ich denke, das Skript ist jetzt soweit abgesichert, was unterschiedliche Verzeichnis-Schreibweisen anbelangt. Zu bemängeln wäre noch - das ist aber auch beim klassischen 20microsoft so - dass eigentlich nur nach dem Boot-Loader von Windows gesucht wird. Theoretisch wäre denkbar - insbesondere dann bei EFI - dass der Bootloader noch existiert, aber die eigentliche Haupt-Windows-Partition gelöscht wurde. Das mit dem proben der Windows-Hauptpartition steht aber schon als "Remaining" im changelog zu os-prober.

Was mir in diesem Zusammenhang noch aufgefallen ist - möglicherweise ist das schon immer so und ich habe es nur noch nicht bemerkt:

Wenn auf dem Rechner mehr als eine Partition frei ist, die verkleinert werden könnte, um darauf Ubuntu zu installieren, dann bietet der Installationsart-Dialog nur an, Windows durch Ubuntu zu ersetzen. Die Möglichkeit es Ubuntu neben Windows zu installieren, steht dann nicht mehr zur Auswahl. Das sieht auch nach einem BUG aus.

Gruß, Martin

EDIT:
Bereits umfangreichere und bessere Änderung bezüglich des os-prober-Problems findet man

• hier

• in Verbindung mit hier

Gruß, Martin

Newubunti schrieb:

EDIT:
Bereits umfangreichere und bessere Änderung bezüglich des os-prober-Problems findet man

• hier

• in Verbindung mit hier

Was hoffen lässt, dass das bald in die offiziellen Skripte einfließt. Ich bleibe bis dahin mal beim manuellen Einbringen als Kurzskript.

Unser Problem hat sich als "zeitlich zufälliger" Hardwarefehler herausgestellt - wir haben aber alle Beteiligten angewiesen, ein aufmerksames Auge bei den relevanten Boards auf deren Verhalten zu werfen. Zumal die Techniker ein Problem zwischen "schnellen" CPU's und "langsamer" Abarbeitung im NVRAM sehen.

gruß syscon-hh

Ich arbeite die letzten Tage am Patch für die Pakete os-prober und grud-common. Die Patches aus den beiden Links aus meinem letzten Post haben bei mir nicht direkt mit Ubuntu funktioniert. Ich habe da einige Modifikationen vornehmen müssen, um das ans Laufen zu bringen - wenn auch nicht viele.

Dabei ist mir aber auch aufgefallen, dass die Patches noch nicht vollends durchdacht sind - IMO.

Außerdem krankt os-prober für die modernen Windows-System an der Tatsache, dass er Partitionen sequentiel mounted und überprüft. Das ist bei der Zweiteilung bei Windows von Bootpartition und Systempartition aber nicht sehr vorteilhaft. os-prober bestimmt im Moment im Prinzip bei Windows nur, ob es eine Partition mit Bootdateien gibt. Gibt es eine solche, dann wird Windows von os-prober "erkannt".

Das gleiche gilt für die EFI-Integration in os-prober - auch aus den verlinkten Patches. Ob neben dem EFI-Loader überhaupt eine Windows-Partition besteht wird gar nicht geprüft.

Also soweit es nur darum geht, dass man die EFI-Loader auf der EFI-System-Partition entdecken will, ist das relativ leicht zu bewerkstelligen. Das habe ich jetzt im Prinzip fast fertig und das ist auch Bestandteil der verlinkten Patches.

Allerdings bin ich mit dem Posten von Patches auf launchpad überhaupt nicht vertraut. Da werde ich dann noch mal nachfragen müssen.

Meine Patches kann ich wahrscheinlich morgen auch hier mal online stellen.

Gruß, Martin