Comment 46 for bug 1418706
Revision history for this message
| Jason Gerard DeRose (jderose) wrote Re: Vivid: UEFI: blank drive incorrectly detected as existing BIOS-mode install | #46 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
@Paulo: no, I didn't think that ISO was the RC, I was just checking in on the latest daily.
In case booting with Upstart was the variable, I just tested with systemd (with the same daily ISO), and this EFI partitioning bug (in terms of my original scenario) seems to be fixed. Although in the systemd case, I can't really confirm this nicely as I can't reboot the VM after the install finishes (my tooling uses the plain-jane KVM Gtk window, doesn't provide UI to force a reset). All I know for sure is that I'm at least not getting the original error message dialog when booting with systemd, which I was still getting with the ISO from the day before.
Grub may or not be getting installed correctly when booting with systemd. For what it's worth, when I tried to boot from this virtual disk after killing my kvm process, it didn't work, but there are many reason why this could happen as pulling the (virtual) plug in this way could easily leave the vm disk file in an inconsistent state. Or I could have just made a goof.
But when I tested earlier booting the ISO with Upstart, things definitely worked correctly. Grub was installed correctly and I could reboot into Ubuntu after the installation completed.
If this isn't the case for everyone in their specific scenario, keep in mind that I'm testing with:
1) A truly "blank" target drive (a freshly created qcow2 disk image containing the byte 0x00 repeated)
2) An OEM-mode install these last to times around (although previously I've tested normal installs, just in case this bug was specific to OEM-mode, and found no difference)
Plus, to get things fully working without a hard-reset, I booted the ISO with init=/sbin/upstart :D
Thanks!