staging.inyokaproject.org

Archiv/Wubi

Status: Gelöst | Ubuntu-Version: Nicht spezifiziert
Antworten |
Dieses Thema ist die Diskussion der Artikel Archiv/Wubi, Archiv/Wubi/Konfiguration, Archiv/Wubi/Problembehebung.

hakunamatata Team-Icon

Supporter
Avatar von hakunamatata

Anmeldungsdatum:
30. Juni 2009

Beiträge: 5130

syscon-hh schrieb:

usw. hat sich nichts geändert.

Ja, genau das hatte mich verwirrt. Ich habe weder hier Hinweise auf Änderungen gefunden, noch selbst Änderungen bei meinen Test-Wubi-Installationen feststellen können.

Inzwischen denke ich, dass die Änderung, die du meinst, aus dem Paket lupin-support kommt. Da wurde das grub-install-Skript überarbeitet und die Datei wubildr mit dem GRUB2-Modul für GPT-Unterstützung erstellt. Der ganz große Durchbruch scheint es aber nur dann zu sein, wenn die Firmware bei Bedarf vom UEFI-Modus in den BIOS-Modus wechselt und das entsprechend bei der Firmware einstellbar ist.

edit:

Der Fehler im Zusammenspiel von Wubi mit den busybox-* Paketen wurde auch gefixt.

Bezieht sich das auf 1308152?

syscon-hh

Anmeldungsdatum:
8. Oktober 2005

Beiträge: 10220

hakunamatata schrieb:

Der ganz große Durchbruch scheint es aber nur dann zu sein, wenn die Firmware bei Bedarf vom UEFI-Modus in den BIOS-Modus wechselt und das entsprechend bei der Firmware einstellbar ist.

Das wiederum verstehe ich jetzt nicht?!

Ich habe hier mit Trusty Tahr eine Wubi-Installation

  • auf einem System im BIOS-Modus

    • Windows Basis 8.1 Pro 32Bit

    • Wubi als 64Bit Version

  • auf einem System im EFI-Modus

    • Windows Basis 8.1 Pro 64Bit

    • Wubi als 64Bit Version

Dieses war mit der bisherigen wubi.exe nicht realisierbar.

edit:

Der Fehler im Zusammenspiel von Wubi mit den busybox-* Paketen wurde auch gefixt.

Bezieht sich das auf 1308152?

Kann ich so nicht sagen - ich hatte nur das Problem nach einer neuen Installation erkannt und dann das über eine

  • chroot-Umgebung und als "loop-device"

korrigiert - mein 1254428-Report dazu war.

hakunamatata Team-Icon

Supporter
Avatar von hakunamatata

Anmeldungsdatum:
30. Juni 2009

Beiträge: 5130

syscon-hh schrieb:

Das wiederum verstehe ich jetzt nicht?!

Bei mir hat die neue wubi.exe auf meinem System im EFI-Modus:

  • Windows 8.1 64Bit

  • Wubi als 64Bit Version

keine Änderung bewirkt. Fehler

Datei: \ubuntu\winboot\wubildr.mbr
Status: 0xc000007b 

völlig unverändert. Nehme an, dass der Grund ist, dass in der Firmware kein Modus "UEFI & CSM" einstellbar ist. "UEFI" ohne Secureboot ist nicht ausreichend und nur "CSM" startet Windows im UEFI-Modus nicht. Funktioniert bei mir nur dann, wenn ich mir mit ähnlichen Modulen wie bei wubildr einen EFI-GRUB2-Loader erstelle. Das Modul biosdisk lasse ich dabei weg und part_gpt war bei mir immer schon dabei. Für das System mit dem MBR in einer Datei muss wahrscheinlich zwingend eine BIOS-Emulation aktivierbar sein, nachdem aber zuerst das Windows-Bootmenü im UEFI-Modus bereits gestartet wurde.

mein 1254428-Report dazu war.

Danke, der Bugfix ist ja topaktuell! Wenn das hier ebenfalls hilft (werde ich gleich testen), sollte ein Link auf den 1254428 ins Wiki rein.

edit: Ist es leider nicht, Ursache liegt aber ebenfalls in den busybox-Paketen; mit den alten Paketen von 13.10 funktioniert es. Werde ich mir noch ansehen, möchte aber hier den Diskussionsthread zum Wikiartikel Wubi damit nicht belasten.

syscon-hh

Anmeldungsdatum:
8. Oktober 2005

Beiträge: 10220

Ich habe mal das Problem mit dem Startabbruch als 1317437 gemeldet.

Hier stellt es sich jetzt so dar:

  • Änderung der »linux« Zeile in der /boot/grub/grub.cfg

Die Umstellung von ro auf rw lässt ein System auf einer Windows Installation basierend auf einer msdos-Partitions-Tabelle (also in der Regel MBR-basierte Systeme - kein EFI Bootmanagement) danach einwandfrei starten und betreiben. Alle laufenden Updates sind eingebracht - einschließlich von:

busybox-initramfs_1.21.0-1ubuntu1
busybox-static_1.21.0-1ubuntu1

Die Umstellung muss man in eine frische Wubi-Installation gleich beim ersten Start in der Grub_2-Shell einbringen / editieren und dann dauerhaft am Desktop fixieren. Danach habe ich das folgende Skript als 00_lupin lauffähig in das Verzeichnis /etc/grub.d abgelegt

1
2
3
4
#! /bin/sh
set -e
target=/etc/grub.d/10_lupin
if cat $target | grep " ro " >/dev/null; then sed  -i s/' ro '/' rw '/g $target; fi

Damit wird ein zwischenzeitliches Update ggf. ausgehebelt.

In wie weit wir diesen Sachverhalt in das WIKI verlinken - ich weiß es nicht?

  • Fehler bei einer GPT-Partitionstabelle

Hinsichtlich des Fehlers auf einem EFI Bootmanagement, wo die Basis ja GPT ist, bleibt abzuwarten, was mit diesem 1316968 passiert.

In beiden -Reports wären "Ich auch betroffen" recht hilfreich!

gruß syscon-hh

hakunamatata Team-Icon

Supporter
Avatar von hakunamatata

Anmeldungsdatum:
30. Juni 2009

Beiträge: 5130

syscon-hh schrieb:

Die Umstellung von ro auf rw lässt ein System auf einer Windows Installation basierend auf einer msdos-Partitions-Tabelle (also in der Regel MBR-basierte Systeme - kein EFI Bootmanagement) danach einwandfrei starten und betreiben.

+1 Auch bei mir reproduzierbar, betrifft hier aber eine Installation mit GPT-Partitionstabelle.

In wie weit wir diesen Sachverhalt in das WIKI verlinken - ich weiß es nicht?

Der Fehler sollte auf jeden Fall ins Wiki, da hier sicher eine größere Anzahl von User betroffen ist. Scheint auch neben deinem 1317437 sich bei 1308152 um das gleiche Problem zu handeln. Deine Lösung mit dem Skript finde ich sehr elegant und ist sicher wikitauglich.

  • Fehler bei einer GPT-Partitionstabelle

-1 Dieser Fehler ist bei mir nicht reproduzierbar. Die Originaldateien wubildr.mbr und wubildr zum Starten funktionieren aber auch bei mir generell leider nicht. So sieht bei mir der Ersatz aus:

sudo grub-mkimage -O x86_64-efi -c /host/ubuntu/winboot/wubildr-bootstrap.cfg -m /host/ubuntu/winboot/wubildr.tar part_msdos part_gpt fat ntfs ext2 ntfscomp iso9660 loopback search linux boot echo test gzio normal memdisk tar probe configfile all_video efifwsetup chain sleep linuxefi -o /boot/efi/EFI/ubuntu/wubildr.efi

syscon-hh

Anmeldungsdatum:
8. Oktober 2005

Beiträge: 10220

hakunamatata schrieb:

  • Fehler bei einer GPT-Partitionstabelle

-1 Dieser Fehler ist bei mir nicht reproduzierbar.

Das ist auch nur relevant bei einer Windows MBR Installation (C:, SSD als / auf msdos) und das Wubi getrennt auf einer 3 TiB-HD mit GPT (z.B. D:).

Diese beiden Fälle / Kombinationen haben wir bisher abgearbeitet, EFI ist erst demnächst ausführlich dran.

By the way - sollte hier und ggf. anderen Stellen jetzt das Windows XP nicht eleminiert werden?

hakunamatata Team-Icon

Supporter
Avatar von hakunamatata

Anmeldungsdatum:
30. Juni 2009

Beiträge: 5130

syscon-hh schrieb:

Das ist auch nur relevant bei einer Windows MBR Installation

Alles klar, dann habe ich das missinterpretiert.

By the way - sollte hier und ggf. anderen Stellen jetzt das Windows XP nicht eleminiert werden?

Solange Windows XP (hoffentlich nur offline) noch immer in relevanter Stückzahl eingesetzt wird, würde ich es drin lassen.

syscon-hh

Anmeldungsdatum:
8. Oktober 2005

Beiträge: 10220

Wir haben hier nach langer Diskussion folgenden Vorschlag als "Einführung" für das Wubi-WIKI erarbeitet:

Entweder wie vorhanden als "Warnbox" oder als "Experten-Info":

Achtung!

Sofern das Windows mit einem EFI Bootmanagement betrieben wird, sollte man auch das Ubuntu bzw. deren Derivate direkt im EFI-Modus installieren. Auch dabei ist wie bei einer Wubi-Installation sichergestellt, die Hardware schnell und sicher wieder in den Ausgangszustand bringen zu können.

Auf jeden Fall sollte man mit einem Live-System die Eignung der Hardware im Vorwege abklären.

Das basiert darauf, dass es in einem EFI Bootmanagement genau so einfach ist, den Rechner von einer Ubuntu Testinstallation zu befreien, ohne dass man z.B. den MBR wieder herstellen muss.

Wir werden dazu noch einen Unterartikel für das EFI Bootmanagement erarbeiten und einfügen, der sich speziell damit befasst

gruß syscon-hh

Nachtrag am 11. Mai 2014: Zur weiteren Information, folgende Ausgaben, die ein Wubi-amd64 nicht möglich machen und nach Rücksprache so gewollt sind:

root@TRUSTY-UGM:/boot/efi/EFI# uname -rm
3.13.0-24-generic x86_64
root@TRUSTY-UGM:/boot/efi/EFI# grub-install
/usr/lib/grub/i386-pc doesn't exist; GRUB cannot be installed.
root@TRUSTY-UGM:/boot/efi/EFI# grub-install.real
installing for x86_64-efi platform
installation beendet. Keine Fehler aufgetreten.
root@TRUSTY-UGM:/boot/efi/EFI# 

Es wird mit dem letzten Befehl alles in die "EFI-Partition" geschrieben - aber startet immer noch nicht! Es handelt sich um ein im Wubi-Modus gestartetes System, das mit viel Tricksereien dazu gebracht werden konnte.

root@TRUSTY-UGM:/# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc		/proc		proc	defaults	0	0
/host/ubuntu/disks/root.disk	/	ext4	loop	0	2
# /boot/efi was on /dev/sde1 during installation
UUID=3654-05AA  /boot/efi       vfat    defaults        0       0
#
/host/ubuntu/disks/swap.disk	none	swap	sw	0	0
#
root@TRUSTY-UGM:/# mount
/dev/loop0 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
/dev/sdb2 on /host type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096)
none on /sys/fs/cgroup type tmpfs (rw)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
none on /sys/firmware/efi/efivars type efivarfs (rw)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
none on /sys/fs/pstore type pstore (rw)
/dev/sdb1 on /boot/efi type vfat (rw)
systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,user=laura)
/dev/sdc3 on /media/laura/USB_HOME type btrfs (rw,nosuid,nodev,uhelper=udisks2)
/dev/sdc2 on /media/laura/USB_ROOT type btrfs (rw,nosuid,nodev,uhelper=udisks2)
root@TRUSTY-UGM:/# 

Bei den Gesprächen kam auch heraus, dass das mit dem fehlenden insmod part_gpt so gewollt ist, um eine Wubi-Installation innerhalb vom EFI-Windows zu unterbinden und dort nur MBR Systeme im BIOS-Modus zu unterstützen. Im Prinzip läuft das unter EFI auf eine Installation auf der Windows-HD hinaus, wird aber wie eine richtige EFI-Installation direkt aus dem NVRAM gestartet.

Der Fehler mit dem ro in der Kernelzeile konnte man sich im Moment noch nicht erklären.

syscon-hh

Anmeldungsdatum:
8. Oktober 2005

Beiträge: 10220

Hier noch ein paar Nachbrenner aus den letzten Versuchen bzw. Untersuchungen.

Im EFI-Verzeichnis /boot/efi/EFI/ubuntu werden ja die relevanten Dateien

  • shimx64.efi

  • grubx64.efi

  • MokManager.efi

  • grub.cfg

eingebracht, die für das Starten aus dem EFI-BIOS gebraucht werden. Dabei sind uns weitere Fehler aufgefallen, die nur bei einer Wubi-Installation entstehen. Am Beispiel der grub.cfg folgendes:

search.fs_uuid a614ada9-c9ab-402a-a06a-b4a3700e4900 root 
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

Dieses sieht im ersten Moment richtig aus, da vergleichbar mit einer normalen Installation im EFI-Modus. Nur ist diese UUID diejenige, die für das "loop-device" beim Einbinden generiert wurde (und jedes mal neu vergeben wird) - also die falsche Device-Adresse / -Identifikation. Richtig wäre die von der Host-Partition, die im konkreten Fall lautet:

19C0D8697DB9AE2F

Außerdem müsste an dieser Stelle dann erst einmal das "loop-device" eingebunden werden (untersuchen wir später - ob und wie).

Zusammen mit den obigen Dateien weist es darauf hin, dass sogar das secure-boot möglich wäre. Das wird beim

  • sudo update-grub bzw sudo grub-mkconfig

aber wieder zunichte gemacht. Es werden dabei alle Kernelmodule erkannt (Auszug aus /boot):

-rw-r--r--  1 root root  1158016 Mai  3 02:30 abi-3.13.0-24-generic
-rw-r--r--  1 root root   165510 Mai  3 02:30 config-3.13.0-24-generic
-rw-r--r--  1 root root 19403532 Mai 11 15:03 initrd.img-3.13.0-24-generic
-rw-------  1 root root  3372643 Mai  3 02:30 System.map-3.13.0-24-generic
-rw-------  1 root root  5776416 Mai  3 02:30 vmlinuz-3.13.0-24-generic
-rw-------  1 root root  5778328 Mai  6 18:21 vmlinuz-3.13.0-24-generic.efi.signed

erscheinen dann aber nicht in der /boot/grub/grub.cfg, die ja durch die obige, vorgeschaltete grub.cfg via dem Aufruf configfile-Befehl aufgerufen wird (bzw. hier sollte).

Hier die damit korrespondierende /boot/grub/grub.cfg im Auszug:

### BEGIN /etc/grub.d/10_lupin ###

menuentry 'Ubuntu-GNOME' --class ubuntu-gnome --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-a614ada9-c9ab-402a-a06a-b4a3700e4900' {
	gfxmode $linux_gfx_mode
	insmod gzio
	insmod ntfs
	set root='hd1,gpt2'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt2 --hint-efi=hd1,gpt2 --hint-baremetal=ahci1,gpt2  19C0D8697DB9AE2F
	else
	  search --no-floppy --fs-uuid --set=root 19C0D8697DB9AE2F
	fi
	loopback loop0 /ubuntu/disks/root.disk
	set root=(loop0)
	linux	/boot/vmlinuz-3.13.0-24-generic root=UUID=19C0D8697DB9AE2F loop=/ubuntu/disks/root.disk ro   quiet splash $vt_handoff
	initrd	/boot/initrd.img-3.13.0-24-generic
}

### END /etc/grub.d/10_lupin ###
  • erste Markierung → fehlt was

    • richtig wäre, Auszug normale Installation mit secure-boot

    • linux	/boot/vmlinuz-3.13.0-24-generic.efi.signed ...
  • zweite Markierung → richtige UUID der Host-Partition

Wie aus dem vorherigen Post zu ersehen ist, ist im EFI-Modus der Befehl

  • sudo grub-intall.real

ohne Angabe einer HD zu benutzen, damit die Grub-Daten richtig in der EFI-Partition abgelegt werden.

Benutzt man diesen Befehl in einem normalen Wubi, kann man durch Hinzufügen von z.b. /dev/sda auch die Wubi-Installation in den MBR dieser Festplatte setzen - mit allen Konsequenzen!

gruß syscon-hh und vom Team

hakunamatata Team-Icon

Supporter
Avatar von hakunamatata

Anmeldungsdatum:
30. Juni 2009

Beiträge: 5130

syscon-hh schrieb:

Sofern das Windows mit einem EFI Bootmanagement betrieben wird, sollte man auch das Ubuntu bzw. deren Derivate direkt im EFI-Modus installieren. Auch dabei ist wie bei einer Wubi-Installation sichergestellt, die Hardware schnell und sicher wieder in den Ausgangszustand bringen zu können.

Die Formulierung finde ich schon sehr gut. Bei direkt würde ich noch auf das Installations-Wiki für eine wubilose Installation verlinken. Sicher ist sicher. Auch, wenn der nächste Satz mit "wie bei einer Wubi-Installation" logisch ausschließt, dass eine Wubi-Installation im EFI-Modus gemeint ist.

syscon-hh schrieb:

Zusammen mit den obigen Dateien weist es darauf hin, dass sogar das secure-boot möglich wäre.

Es gibt nur das Problem, dass meines Wissens keine von Canonical signierte grubx64.efi-Datei verfügbar ist, die das Modul für ntfs-Unterstützung inkludiert hat. Ein späteres Nachladen von GRUB2-Modulen bei Bedarf wird leider von Secure-Boot verhindert.

syscon-hh

Anmeldungsdatum:
8. Oktober 2005

Beiträge: 10220

hakunamatata schrieb:

Bei direkt würde ich noch auf das Installations-Wiki für eine wubilose Installation verlinken. Sicher ist sicher. Auch, wenn der nächste Satz mit "wie bei einer Wubi-Installation" logisch ausschließt, dass eine Wubi-Installation im EFI-Modus gemeint ist.

Ist ohnehin vorgesehen - nur der relevante Artikel darf ja nicht als Baustelle dort aufgenommen werden! Das ist dann der übernächste Schritt ☺

tomtomtom Team-Icon

Supporter
Avatar von tomtomtom

Anmeldungsdatum:
22. August 2008

Beiträge: 55572

Der Absatz zu Windows XP kann imho raus, das ist seit Mai 2014 EoS.

syscon-hh

Anmeldungsdatum:
8. Oktober 2005

Beiträge: 10220

tomtomtom schrieb:

Der Absatz zu Windows XP kann imho raus, ...

Ando

Avatar von Ando

Anmeldungsdatum:
9. November 2005

Beiträge: Zähle...

Hallo zusammen,

es gibt ein WUBI-UEFI Projekt auf github (der alte Wubi-Code wird als Grundlage genutzt). Ich habe es mit Win7 (64bit) als auch mit Win10 (64bit) getestet und es funktioniert tatsächlich ohne Probleme. Der ubuntuusers-User hakuna_matata ist hier federführend tätig. (s.a. hier https://forum.ubuntuusers.de/topic/windows-ubuntu-installer-fuer-systeme-mit-uefi/)

https://github.com/hakuna-m/wubiuefi

Zur Zeit existiert hier eine recht aktive Weiterentwicklung. Das Ergebnis kann sich sehen lassen. Ich konnte neben "Ubuntu 16.10" auch "LinuxMint 17" und "ElementaryOS Freya" installieren. Es sollen wohl noch weitere Features (z.B. mehrere WUBI-Installationen nebeneinander) geplant sein.

Da der WUBI-Artikel recht kompakt geschrieben ist, will ich da aber nichts kaputt machen... Könnte man dieses Projekt zumindest als Hinweis auf eine (private) Weiterentwicklung von Wubi irgendwie integrieren?

Grüße,

Ando

noisefloor Team-Icon

Anmeldungsdatum:
6. Juni 2006

Beiträge: 29567

Hallo,

unter "Links" kannst du das auf jeden Fall aufführen.

Gruß, noisefloor