Created attachment 8884 [details] report.bug from when "Use free space" was selected +++ This bug was initially created as a clone of Bug #19935 +++ "Custom disk partitioning requests BIOS boot partition on non-GPT disk" which got fixed, apart from the above remaining issue. When selecting to "Use free space" in the first partitioning screen, "* fdisk after" shows en empty partition was created, like: /dev/sda9 38514688 38525759 11072 5.4M 0 Empty See attachment Btw, when running "bug" in tty2 I saw: need_removing_empty_extended and only then putting file report.bug on sdb1 The used iso was: Mageia-6-sta2-i586-DVD.iso of Thu Jan 19 16:47:56 CET 2017
Summary: On non-GPT disk an empty partition is created when diskdrake does the partioning, because it mistakenly thinks a BIOS boot partition is needed. => On non-GPT disk an empty partition is created when diskdrake does the partitioning, because it mistakenly thinks a BIOS boot partition is needed.
I could boot into the just installed Mageia, but when starting a new install my partition table turns out to be too corrupted to read. (the error is /proc/partitions does not agree with drakx 7 != 8 for sda: /proc/partitions: sda1 (sda), sda5 ((sda), sda6 (sda), sda7 (sda), sda8 (sda) sda9 (sda), sda10 (sda), sda11 (sda))
(In reply to Marja van Waes from comment #1) > I could boot into the just installed Mageia, but when starting a new install > my partition table turns out to be too corrupted to read. > > (the error is /proc/partitions does not agree with drakx 7 != 8 for sda: > /proc/partitions: sda1 (sda), sda5 ((sda), sda6 (sda), sda7 (sda), sda8 > (sda) sda9 (sda), sda10 (sda), sda11 (sda)) Yes, I would expect this because of bug 20074. You should be able to fix this by using fdisk to delete the Empty partition (sda9).
Created attachment 8885 [details] report.bug from when "Auto-allocate" was used (In reply to Martin Whitaker from comment #2) > > You should be able to fix > this by using fdisk to delete the Empty partition (sda9). Thanks :-) I'll try that next time, now I used gparted to delete everything except my encrypted partition and the fake windows partition. I then resized the windows partition to take up all free space, because I wanted to see whether this bug also occurs when choosing to use free space on a windows partition for install. Unfortunately, I did not get that option, now. However, I did find a way to get the screen about needing to create a boot partition when custom partitioning. It's easy: don't create a / partition and try to continue. Attaching logs (it happened where I took a screenshot) After that I used Auto-allocate and, as expected, an empty parititon was created again.
(In reply to Marja van Waes from comment #3) > However, I did find a way to get the screen about needing to create a boot > partition when custom partitioning. It's easy: don't create a / partition > and try to continue. Ah yes. Copying the relevant bit from bug 20074: "This occurs because the is_boot_bios_part_needed() [subroutine] can't identify the root device until a /boot or / partition have been allocated (and defaults to assuming a GPT disk)." Auto-allocate mistakenly creates a Empty partition because it checks whether a BIOS boot partition is needed before allocating the root partition, so defaults to assuming the boot device is GPT. Custom partitioning mistakenly asks for a BIOS boot partition because again there is no root partition to allow it to determine which disk is the boot device. The easiest fix for the custom partitioning bug would be to skip the check for a BIOS boot partition if the check for a root partition fails. Of course this would make people go round the loop twice if they had forgotten to create both for a GPT disk.
(In reply to Martin Whitaker from comment #4) > > The easiest fix for the custom partitioning bug would be to skip the check > for a BIOS boot partition if the check for a root partition fails. Of course > this would make people go round the loop twice if they had forgotten to > create both for a GPT disk. Does that fix the auto-partitioning issue, too? If so, then I'm in favour of this change. If not, then I don't care, because I did deliberately avoid creating a root partition to see what would happen (I was wondering how Pete Larson could have hit this).
(In reply to Martin Whitaker from comment #2) > > Yes, I would expect this because of bug 20074. You should be able to fix > this by using fdisk to delete the Empty partition (sda9). I've put instructions in the wiki, in case someone needs them: https://wiki.mageia.org/en/How_to_delete_a_partition_with_fdisk
(In reply to Marja van Waes from comment #5) > (In reply to Martin Whitaker from comment #4) > > > > > The easiest fix for the custom partitioning bug would be to skip the check > > for a BIOS boot partition if the check for a root partition fails. Of course > > this would make people go round the loop twice if they had forgotten to > > create both for a GPT disk. > > Does that fix the auto-partitioning issue, too? > > If so, then I'm in favour of this change. > > If not, then I don't care, because I did deliberately avoid creating a root > partition to see what would happen (I was wondering how Pete Larson could > have hit this). (This is the first I've looked at a screen since getting ill on Saturday) I don't know how I hit that bug either and since I wasn't able to do it again, I'm wondering If I hadn't accidentally forgot to specify a / partition that time and then corrected that without thinking about it. I have to ask if no one else is seeing the message that they don't have a swap partition, with the option to continue anyway? This whole issue has branched and I'm not so sure where to put some comments. I will also ask, is there maybe a better way to detect whether a disk is MBR or GPT in the first place? Maybe looking at different disk information than the bootable partitions?
Created attachment 8896 [details] alternative scheme for auto-allocating BIOS boot partitions How about something like this (untested)? Instead of adding the BIOS boot partition to the normal list of suggestions (which, incidentally, means it could end up on a different disk to the root/boot partition, or could even end up on a LVM), add a BIOS boot partition to each physical GPT partitioned disk that doesn't already have one. If there are multiple disks, we end up with more BIOS boot partitions than we need, but we could prune the unneeded ones later. Would having them present on all disks allow the user to choose any disk when installing the bootloader? If so, it might be nice to keep them all (they are only 1MB, so not particularly wasteful). This would also fix bug 19888.
(In reply to Martin Whitaker from comment #8) > Created attachment 8896 [details] > alternative scheme for auto-allocating BIOS boot partitions > > How about something like this (untested)? Instead of adding the BIOS boot > partition to the normal list of suggestions (which, incidentally, means it > could end up on a different disk to the root/boot partition, or could even > end up on a LVM), add a BIOS boot partition to each physical GPT partitioned > disk that doesn't already have one. If there are multiple disks, we end up > with more BIOS boot partitions than we need, but we could prune the unneeded > ones later. Would having them present on all disks allow the user to choose > any disk when installing the bootloader? If so, it might be nice to keep > them all (they are only 1MB, so not particularly wasteful). > > This would also fix bug 19888. Sounds like that is asking for trouble. I thought the purpose of GPT was to be able to identify a bios_boot partition regardless of location. I know all my non-UEFI grub2 installs on either drive are having no problem finding/using mine. $ gdisk -l /dev/sda snippet follows: Number Start (sector) End (sector) Size Code Name 10 1471924224 1472983039 517.0 MiB EF02 I have had grub2 boot screwed up more than a few times and have picked installs from either drive via reinstall boot loader using the boot.iso. It also makes me wonder when in the Mageia re-install grub boot loader mode, how would it know which bios_boot partition is to be used.
(In reply to Bit Twister from comment #9) > Sounds like that is asking for trouble. I thought the purpose of GPT was to > be able to identify a bios_boot partition regardless of location. As I said on the dev ML, I don't know how the boot device is supposed to be chosen when there are multiple disks. Wouldn't grub2 look for the BIOS boot partition on the same disk as the MBR containing the stage 1 boot image? Adding Barry to CC, hoping he can provide some guidance.
CC: (none) => zen25000
(In reply to Martin Whitaker from comment #10) > (In reply to Bit Twister from comment #9) > > Sounds like that is asking for trouble. I thought the purpose of GPT was to > > be able to identify a bios_boot partition regardless of location. > > As I said on the dev ML, I don't know how the boot device is supposed to be > chosen when there are multiple disks. Wouldn't grub2 look for the BIOS boot > partition on the same disk as the MBR containing the stage 1 boot image? > > Adding Barry to CC, hoping he can provide some guidance. grub2-install only uses the bios boot partition on the target drive, or fails if there isn't one.
Created attachment 8897 [details] alternative scheme for auto-allocating BIOS boot partitions Revised to only allocate BIOS boot partitions for non-UEFI boot.
Attachment 8896 is obsolete: 0 => 1
(In reply to Martin Whitaker from comment #12) > Created attachment 8897 [details] > alternative scheme for auto-allocating BIOS boot partitions > > Revised to only allocate BIOS boot partitions for non-UEFI boot. If the above is specifically what it does then there is a problem. On a multi disk system: Sda is gpt and boots EFI Sdb is|can be either gpt or msdos but it will be booted CSM At the partitioning stage of the Sdb install the installer has to assume that it will be booting from the MBR of Sda and a bios_boot partition Has to either be present or created on Sda. If not the CSM bootloader installation will fail if done to Sda.
(In reply to Charles Edwards from comment #13) > If the above is specifically what it does then there is a problem. > > On a multi disk system: > Sda is gpt and boots EFI > Sdb is|can be either gpt or msdos but it will be booted CSM > > At the partitioning stage of the Sdb install the installer has to assume > that it will be booting from the MBR of Sda and a bios_boot partition Has to > either be present or created on Sda. > If not the CSM bootloader installation will fail if done to Sda. Remember that when using auto-partitioning, you don't get to choose which disks the partitions are allocated to - the installer does that. In the current code, a single BIOS boot partition will be created, probably on the first disk that has space for it. But at the end of the partitioning step the installer will check that a BIOS boot partition exists on the disk that contains the new root partition. So it would likely fail in your scenario if there was a small amount of space left on sda and sdb was GPT. My proposal would create a BIOS boot partition on every GPT partition that didn't already have one (providing there was free space), so (I think) would allow you to choose any disk when installing the CSM boot loader. My revision in comment 12 only stops the installer creating BIOS boot partitions when doing a UEFI install.
(In reply to Martin Whitaker from comment #14) > My proposal would create a BIOS boot partition on every GPT partition that > didn't already have one (providing there was free space), so (I think) would > allow you to choose any disk when installing the CSM boot loader. Hmmmmmm, I am curious, user is attempting a CMS GPT sda install and has two or more GPT drives installed. If the user has sdb1, deleted partition(s), sdb5, sdb6, free space, draketools would be creating bios_boot in "sdb2" space and IIRC renumber remaining partitions. Not real sure users are going to be very happy when something screws around on drives not involved with the installation. :-( If that scramble partition table bug reoccurs in the future I am pretty sure Mageia will not be getting any good press and recommendations to use Mageia will not be happy ones from that point forward.
> and IIRC renumber remaining partitions. Are you sure about that? On my UEFI/GPT laptop, I had a large 'free space' as above, and when I defined 2 new partitions in there (for Mageia-6-sta2) the new partitions were numbered with numbers (sda11,sda12) following on from the last partitions further down the drive, whose partition numbers were undisturbed. Gparted shows the drive as follows, in this order: sda1,sda2,sda3,sda4,sda5,sda6,sda7,sda11,sda12,unallocated,sda8,sda9,sda10
(In reply to Bit Twister from comment #15) > Not real sure users are going to be very happy when something screws around > on drives not involved with the installation. :-( I'll repeat; when using auto-partitioning, you don't get to choose which disks the partitions are allocated to - the installer does that. And it will use the available space on *all* drives. So all drives are involved in the installation. This isn't the place to debate the pros and cons of that. The question I'm asking is whether, once the auto-partitioner has chosen a drive for the root partition, we should only allow the boot loader to be installed on that drive, or whether we should allow the user to choose any drive for the boot loader.
I'll throw this in since I've done several mixed disk test install. Sda gpt boots EFI Sdb dos boots CSM I do not use auto-partitioning and neither disk contains a bios_boot partition. At the Configuration stage of the Sdb install the default value shown for Bootloader is grub2 on /dev/sda BUT if I select 'Configure Bootloader' the ONLY path I am allowed to select is grub2 on /dev/sdb which is correct for that type of install.
(In reply to Martin Whitaker from comment #17) > (In reply to Bit Twister from comment #15) > > Not real sure users are going to be very happy when something screws around > > on drives not involved with the installation. :-( > > I'll repeat; when using auto-partitioning, you don't get to choose which > disks the partitions are allocated to - the installer does that. And it will > use the available space on *all* drives. So all drives are involved in the > installation. This isn't the place to debate the pros and cons of that. > > The question I'm asking is whether, once the auto-partitioner has chosen a > drive for the root partition, we should only allow the boot loader to be > installed on that drive, or whether we should allow the user to choose any > drive for the boot loader. Thierry, you probably have an opinion about this?
Created attachment 8929 [details] Patch to indicate the _default_type subroutine can be used outside the partition_table module This seems to be the naming convention.
Created attachment 8930 [details] Patch to fix auto-allocation of BIOS boot partitions I had forgotten that the installer had been changed to only use the selected disk (bug 16055). Given this, it is both sensible and easy to modify my proposed fix to only allocate a BIOS boot partition on the selected disk. In the case that no disk is selected, it will still allocate a BIOS boot partition on every GPT disk, but as discussed in bug 16055, that is not a normal use case. This also fixes bug 19888.
Attachment 8897 is obsolete: 0 => 1
Created attachment 8931 [details] Patch to allow the user to choose any disk for the BIOS boot partition When doing manual partitioning, the user may choose to create a BIOS boot partition on a different disk to the one containing the root partition. This patch stops the installer insisting on the BIOS boot partition being on the same disk. It also stops the installer requesting a BIOS boot partition on a non-GPT disk when the user has forgotten to create a root partition.
I have tested the above patches myself, and have also included them in the latest sta2 Live ISO builds to allow other people to test them. The use case I've not yet tested is installing to a LVM. AFAIK, the BIOS boot partition can't be on the LVM, so the user will need to manually create it.
Keywords: (none) => PATCH
Created attachment 8932 [details] journalctl -a output from after hitting "INTERNAL ERROR: unknown device sda1" My first test went fine: * select custom partitioning * resize the (fake) windows partition * remove an ext4 + swap partition, while leaving the fake win partition + an encrypted one * select Auto-allocate Afterwords, fdisk showed no empty partition, there weren't overlapping partitions and rebooting into the new install went fine. However, 2nd test: * First delete all partitions, except the encrypted one, in Live mode. * Reboot, select install from menu * Select to use the empty space ends with an error about an unknown device sda1 Attaching the journal. fdisk -l at this point shows: Disk /dev/sda: 37,3 GiB, 40007761920 bytes, 78140160 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0xcccdcccd Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 48021119 48019072 22,9G 83 Linux /dev/sda2 48023514 78140159 30116646 14,4G 5 Extended /dev/sda5 48023552 52345439 4321888 2,1G 82 Linux swap / Solaris /dev/sda6 52348928 78140159 25791232 12,3G 83 Linux
Attachment 8885 is obsolete: 0 => 1 Attachment 8884 is obsolete: 0 => 1
(In reply to Marja van Waes from comment #24) > Created attachment 8932 [details] > journalctl -a output from after hitting "INTERNAL ERROR: unknown device sda1" > That happened there at Feb 05 17:04:15
Status comment: (none) => Fixed in the pre-release QA Live isos from February 5, not yet in CI isos
I just had the following experience doing a fresh install, and I'm wondering if it's covered by this bug or whether I should open another... This is a laptop with a 1TB disk that came formatted GPT with Win10 and the usual recovery stuff. I fired up an MGA Repair DVD, and used FDISK to write an MSDOS MBR and create the partitions I wanted. Then I tried a fresh install. When I exited diskdrake, the installer complained that I had to have a FAT32 partition mounted at /boot/UEFI, and wouldn't proceed until I created one. 1TB is well within the MSDOS limit of 2TB, so there is no requirement for GPT, and UEFI doesn't even remotely come into it. Why does the installer think I need a boot partition ?
CC: (none) => ftg
(In reply to Frank Griffin from comment #26) > I just had the following experience doing a fresh install, and I'm wondering > if it's covered by this bug or whether I should open another... > > This is a laptop with a 1TB disk that came formatted GPT with Win10 and the > usual recovery stuff. I fired up an MGA Repair DVD, and used FDISK to write > an MSDOS MBR and create the partitions I wanted. Then I tried a fresh > install. When I exited diskdrake, the installer complained that I had to > have a FAT32 partition mounted at /boot/UEFI, and wouldn't proceed until I > created one. > > 1TB is well within the MSDOS limit of 2TB, so there is no requirement for > GPT, and UEFI doesn't even remotely come into it. > > Why does the installer think I need a boot partition ? Are you sure that you booted the Mga6 install media in CSM|MBR mode and not UEFI mode? I've seen the installer require a bios_boot partition when doing a CSM|MBR install but have never seen it require /boot/UEFI.
I could be mistaken on the UEFI part, but the mount point was decided by the diskdrake installer and the filetype was EFI something-or-other. Yes, CSM was enabled; it wouldn't boot from the CD otherwise.
That last statement makes me Really believe the cd was booting in UEFI mode. When the cd boots can you edit the boot parameters by pressing 'e' or do you have to press 'F6'?
I didn't try to edit the boot parameters at all. I got the usual MGA6 boot menu with "Install" and "Rescue".
Which grub2 rpm are installed on the system. For a CSM|MBR install it would be: grub2 grub2-common grub2-mageia-theme If instead you have grub2-efi then you did a UEFI install.
FYI: I have a GPT MBR grub2 install on mga5 and mga6 and at some point a Cauldron network install insisted on booting uefi. I had to get back into the PC BIOS and change from uefi or csm to csm only. All partitions ext4 except for swap/bios_boot .
> CSM was enabled; it wouldn't boot from the CD otherwise. I believe a Mageia installer CD/DVD can be booted on a UEFI system without CSM or Legacy set. (As can e.g. a SystemRescueCD .iso if prepared with e.g.: isohybrid --uefi ~/Download/systemrescuecd-x86-4.9.2.iso )
commit 02ba0f311a04e3fe93985bb75b6e7e99c6315b73 Author: Martin Whitaker <mageia@...> Date: Sat Feb 4 23:46:14 2017 +0000 Fix auto-allocation of BIOS boot partitions (mga#20161, mga#19888). This adds a specific subroutine, fsedit::auto_allocate_boot_bios_parts that detects if a BIOS boot partition is needed and allocates it if so. This allows us to relax the rules in fs::any::is_boot_bios_part_needed to allow the user to manually allocate the BIOS boot partition on a different device if they so wish. In the normal case that installation is confined to a single disk, this will allocate a single BIOS boot partition on that disk. In the rare case that installation is spread over multiple disks, it will allocate a BIOS boot partition on every disk. Given that the BIOS boot partitions are very small and that this is not a normal use case (see mga#16055), this seems an acceptable quirk - and does allow the user to then choose any disk when installing the boot loader. --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=02ba0f311a04e3fe93985bb75b6e7e99c6315b73 Bug links: Mageia https://bugs.mageia.org/16055 https://bugs.mageia.org/20161 https://bugs.mageia.org/19888
commit e3662f1c4b563d148b8d6e7e650e93eff89b6df1 Author: Martin Whitaker <mageia@...> Date: Sun Feb 5 00:03:41 2017 +0000 Allow a BIOS boot partition to be located on any disk (mga#20161). This relaxes the rules in fs::any::is_boot_bios_part_needed to allow the BIOS boot partition to be located on any disk, not just the disk containing the root partition. It also ensures that a BIOS boot partition is never forcibly required in a system with non-GPT disks. --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=e3662f1c4b563d148b8d6e7e650e93eff89b6df1
(In reply to Bit Twister from comment #32) > FYI: I have a GPT MBR grub2 install on mga5 and mga6 and at some point a > Cauldron network install insisted on booting uefi. I had to get back into > the PC BIOS and change from uefi or csm to csm only. All partitions ext4 > except for swap/bios_boot . The installer determines whether to do a UEFI install or a legacy install by testing whether the kernel has loaded the efivarfs module. The kernel will load this module if the BIOS indicates that the system has booted via UEFI. Of course, we all know how reliable and bug free BIOS implementations are...
Created attachment 8956 [details] Patch to fix auto-allocation of BIOS boot partitions I discovered that calling c::get_disk_type() causes the kernel to rescan the partition table. If this happens too close to writing the new partition table, the kernel doesn't rescan again. So this revised patch records the partition table type when it first reads the partition table and uses the recorded value. This is just for the record - this change is in my user/martinw/mga6 branch.
Attachment 8930 is obsolete: 0 => 1
Created attachment 8957 [details] Patch to allow the user to choose any disk for the BIOS boot partition Updated to use the recorded partition table type as above. Also just for the record.
Attachment 8931 is obsolete: 0 => 1
Hi, When installing Mageia-6-sta2 (today download) in CSM mode on 2 different computers, in manual or in automatic partitioning, i have always the same error: "Custom disk partitioning requests BIOS boot partition on non-GPT disk" the 2 hard disk are new (never partitioned) and bios is UEFI i am but booting in CSM mode.
CC: (none) => contact
(In reply to Daniel Tartavel from comment #39) > Hi, > > When installing Mageia-6-sta2 (today download) in CSM mode on 2 different > computers, in manual or in automatic partitioning, i have always the same > error: > > "Custom disk partitioning requests BIOS boot partition on non-GPT disk" Afaik, that error message doesn't exist. Wasn't the error message either the English one, or the French one below? (from http://gitweb.mageia.org/software/drakx/tree/perl-install/share/po/fr.po?h=user/ennael/mga6#n2377 ): "You must have a BIOS boot partition for non-UEFI GPT-partitioned disks. Please create one before continuing." or "Vous devez avoir une partition de démarrage BIOS sur disque GPT quand le système n'est pas en mode UEFI.Veuillez en créer une avant de continuer." > > the 2 hard disk are new (never partitioned) and bios is UEFI i am but > booting in CSM mode. Even if the disk was never partitioned, it most likely came with a filesystem and a partition table. If the latter is GPT, then you do need a BIOS boot partition. If you're either * sure it has a dos partition table or * sure the error you saw was exactly as you told, and not one I quoted then please fetch report.bug from when you hit that error https://wiki.mageia.org/en/Triage_guide#Traditional_installer and attach it to this bug report Thanks :-)
Hi, The error is effectively the one in french. "Vous devez avoir une partition de démarrage BIOS sur disque GPT quand le système n'est pas en mode UEFI.Veuillez en créer une avant de continuer." The 2 disk were bought new, not partitioned at all, neither DOS nor GPT Thanx
(In reply to Daniel Tartavel from comment #41) > Hi, > > The error is effectively the one in french. > "Vous devez avoir une partition de démarrage BIOS sur disque GPT quand le > système n'est pas en mode UEFI.Veuillez en créer une avant de continuer." > > > The 2 disk were bought new, not partitioned at all, neither DOS nor GPT > > Thanx Please reproduce the problem, then go to tty2 with "Ctrl+Alt+F2", insert a USB key, and then type "bug" report.bug will be written to the USB key. Please attach that file to this bug report.
commit daf8670c08e54ac64407f7f209aaf9b460abdcc6 Author: Martin Whitaker <mageia@...> Date: Sat Feb 4 23:46:14 2017 +0000 Fix auto-allocation of BIOS boot partitions (mga#20161, mga#19888). This adds a specific subroutine, fsedit::auto_allocate_boot_bios_parts that detects if a BIOS boot partition is needed and allocates it if so. This allows us to relax the rules in fs::any::is_boot_bios_part_needed to allow the user to manually allocate the BIOS boot partition on a different device if they so wish. In the normal case that installation is confined to a single disk, this will allocate a single BIOS boot partition on that disk. In the rare case that installation is spread over multiple disks, it will allocate a BIOS boot partition on every disk. Given that the BIOS boot partitions are very small and that this is not a normal use case (see mga#16055), this seems an acceptable quirk - and does allow the user to then choose any disk when installing the boot loader. --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=daf8670c08e54ac64407f7f209aaf9b460abdcc6 Bug links: Mageia https://bugs.mageia.org/16055 https://bugs.mageia.org/20161 https://bugs.mageia.org/19888
commit ccb41194a4e1cca2b162b8221a506a6768e52c6d Author: Martin Whitaker <mageia@...> Date: Sun Feb 5 00:03:41 2017 +0000 Allow a BIOS boot partition to be located on any disk (mga#20161). This relaxes the rules in fs::any::is_boot_bios_part_needed to allow the BIOS boot partition to be located on any disk, not just the disk containing the root partition. It also ensures that a BIOS boot partition is never forcibly required in a system with non-GPT disks. --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=ccb41194a4e1cca2b162b8221a506a6768e52c6d
Assuming fixed by Martin's patches. Please reopen if you still experience it with the soon-to-be-released sta2 ISOs (or the internal testing QA ones).
Status: NEW => RESOLVEDResolution: (none) => FIXED