Since the list of NTH bugs is so huge right now, we're trying to prioritize the order in which we review the currently proposed NTH bugs. Instead of adding a comment to all of the proposed NTH for anaconda, I figured I would send an email to anaconda-devel-list.
If you think that any of the following bugs would be fixed in time for F18 final (currently scheduled for 2013-01-08), please add a comment to the bug or reply to this email. I'll be collecting the "most likely to be fixed in time" NTH bugs to review on Monday.
Thanks, Tim
(875944) shrinking Windows partition creates an unusable dual-boot setup - https://bugzilla.redhat.com/show_bug.cgi?id=875944
(885807) firewalld accidentally made mandatory; needs to be optional for f18 and f19 - https://bugzilla.redhat.com/show_bug.cgi?id=885807
(864470) anaconda can be closed during installation - https://bugzilla.redhat.com/show_bug.cgi?id=864470
(872826) f18 beta tc7 anaconda - no option to install bootloader to a partition - https://bugzilla.redhat.com/show_bug.cgi?id=872826
(870570) Anaconda needs to retry downloading the repo medata on a network config change - https://bugzilla.redhat.com/show_bug.cgi?id=870570
(878985) MATE entry on RC1 i386 DVD install results in an incomplete mate-desktop (openbox login only) please remove mate from DVD left list - https://bugzilla.redhat.com/show_bug.cgi?id=878985
(876916) anaconda claims I don't have enough free space when I have - https://bugzilla.redhat.com/show_bug.cgi?id=876916
(873605) corrupt NFS installation source doesn't present clear warning text - https://bugzilla.redhat.com/show_bug.cgi?id=873605
(875418) Anaconda fails if not enough memory ie (512MB) - https://bugzilla.redhat.com/show_bug.cgi?id=875418
(875430) After installing unable to boot Fedora 18 with virtio-scsi after successfully installing using virtio-scsi driver (have to use virtio-blk to boot) - https://bugzilla.redhat.com/show_bug.cgi?id=875430
Since the list of NTH bugs is so huge right now, we're trying to prioritize the order in which we review the currently proposed NTH bugs. Instead of adding a comment to all of the proposed NTH for anaconda, I figured I would send an email to anaconda-devel-list.
If you think that any of the following bugs would be fixed in time for F18 final (currently scheduled for 2013-01-08), please add a comment to the bug or reply to this email. I'll be collecting the "most likely to be fixed in time" NTH bugs to review on Monday.
I'm currently viewing NTH bugs as only gonna get done if they're easy or really bad (in which case they're going to eventually become blockers). We've got enough work with blockers that all the rest are going to get punted to F19.
(875944) shrinking Windows partition creates an unusable dual-boot setup
We're not going to be creating new shrinking UI at this point in the release cycle.
(885807) firewalld accidentally made mandatory; needs to be optional for f18 and f19
Something will have to get done. I don't know what.
(864470) anaconda can be closed during installation
Probably not.
(872826) f18 beta tc7 anaconda - no option to install bootloader to a partition
As seems to be the case with so many F18 bugs, this one is so unclear anymore that it's impossible to tell what it's about. grub2 doesn't recommend installing to a partition, so this should probably be closed from anaconda's side. But then the last couple comments go in a completely different direction, and that gets filed as other bugs. Still kind of looks like the original can go.
(870570) Anaconda needs to retry downloading the repo medata on a network config change
This could probably get done.
(878985) MATE entry on RC1 i386 DVD install results in an incomplete mate-desktop (openbox login only) please remove mate from DVD left list
Reassigned to pungi.
(876916) anaconda claims I don't have enough free space when I have
We have a couple bugs along these lines. Something will probably get done.
(873605) corrupt NFS installation source doesn't present clear warning text
Probably not.
(875418) Anaconda fails if not enough memory ie (512MB)
ON_QA.
(875430) After installing unable to boot Fedora 18 with virtio-scsi after successfully installing using virtio-scsi driver (have to use virtio-blk to boot)
Reassigned to qemu.
- Chris
On Thu, 2012-12-13 at 10:41 -0500, Chris Lumens wrote:
(875944) shrinking Windows partition creates an unusable dual-boot setup
We're not going to be creating new shrinking UI at this point in the release cycle.
Couldn't we throw some (more?) arbitrary padding at the minimum possible size for NTFS/FAT volumes? That'd fix it without changing UI, right? https://bugzilla.redhat.com/show_bug.cgi?id=885912 seems to be similar.
(872826) f18 beta tc7 anaconda - no option to install bootloader to a partition
As seems to be the case with so many F18 bugs, this one is so unclear anymore that it's impossible to tell what it's about. grub2 doesn't recommend installing to a partition, so this should probably be closed from anaconda's side. But then the last couple comments go in a completely different direction, and that gets filed as other bugs. Still kind of looks like the original can go.
Treat it as the original, and if you don't think we should offer this option any more, close it as WONTFIX. The stuff about not installing a bootloader at all is all being handled elsewhere.
(878985) MATE entry on RC1 i386 DVD install results in an incomplete mate-desktop (openbox login only) please remove mate from DVD left list
Reassigned to pungi.
I'm kinda thinking we should consider this for blocker status, as the result if you hit it is fairly crappy, and we're getting a lot of 'Fedora 18 supports MATE!' publicity, so people are going to try it...
On Thu, 2012-12-13 at 09:35 -0800, Adam Williamson wrote:
On Thu, 2012-12-13 at 10:41 -0500, Chris Lumens wrote:
(875944) shrinking Windows partition creates an unusable dual-boot setup
We're not going to be creating new shrinking UI at this point in the release cycle.
Couldn't we throw some (more?) arbitrary padding at the minimum possible size for NTFS/FAT volumes? That'd fix it without changing UI, right? https://bugzilla.redhat.com/show_bug.cgi?id=885912 seems to be similar.
Oh, no, 885912 seems to be different and more clearly a bug bug (partition being resized to a smaller size than the filesystem).
On Dec 13, 2012, at 10:35 AM, Adam Williamson awilliam@redhat.com wrote:
On Thu, 2012-12-13 at 10:41 -0500, Chris Lumens wrote:
(875944) shrinking Windows partition creates an unusable dual-boot setup
We're not going to be creating new shrinking UI at this point in the release cycle.
Couldn't we throw some (more?) arbitrary padding at the minimum possible size for NTFS/FAT volumes? That'd fix it without changing UI, right?
This is a blocker. I'm using anaconda 18.37.2-1. Setting aside the UI problems for now, 2 for 2 I end up with a broken Windows install. On booting Windows from GRUB, I'm dumped into Windows Startup Repair where it tries to fix the disk and finally says it can't be repaired automatically.
The anaconda UI in Reclaim space is very misleading. 98% means what? I can't change it either. Since giving 98% of free space to Fedora is grossly illogical to the point of sabotage, it's reasonable to assume it means 98% will remain for Windows, even though that seems to short change Fedora by way too much. Either way it's not a workable default, and the fact I can't change it also seems broken.
I will update 875944 with the details of what I experienced.
(872826) f18 beta tc7 anaconda - no option to install bootloader to a partition
As seems to be the case with so many F18 bugs, this one is so unclear anymore that it's impossible to tell what it's about. grub2 doesn't recommend installing to a partition, so this should probably be closed from anaconda's side. But then the last couple comments go in a completely different direction, and that gets filed as other bugs. Still kind of looks like the original can go.
Treat it as the original, and if you don't think we should offer this option any more, close it as WONTFIX. The stuff about not installing a bootloader at all is all being handled elsewhere.
I agree this is WONTFIX.
Chris Murphy
On Thu, 2012-12-13 at 10:41 -0500, Chris Lumens wrote:
(875944) shrinking Windows partition creates an unusable dual-boot setup
We're not going to be creating new shrinking UI at this point in the release cycle.
So I just looked at this again. It may be just me, but it may not, so in case anyone else missed it like me: the problem here is that newUI's non-custom shrink path gives the user no opportunity to decide the size of the shrunk partition. It just automatically decides to shrink it to the smallest size anaconda thinks is viable.
In oldUI, when you picked 'Shrink an existing partition' from the 'partition options' page, you got a dialog that let you pick the partition to shrink, and the size to shrink it to.
In newUI, all you can do is pick a partition and click 'Shrink', and anaconda then decides for you that it should be shrunk to the smallest possible size. You can't change this.
dlehman tells me that we take the absolute minimum possible size for the partition (as the tools report it to us) and then pad it by 'the lesser of 10% or 500MB'.
This is clearly ridiculous for probably the most common use case - shrink an existing Windows installation and install alongside it. If a regular old person with Windows installed on their entire disk grabs F18 and tries to install Fedora alongside it, following the path we 'expect' - non-custom - they will probably wind up with their Windows partition being 500MB larger than its current contents (I guess fragmentation plays with this, but more or less). That seems to be me to be patently not what they'd actually want. Hell, regular old Mysterious Windows Bloat will probably fill up that 500MB in a week or two, never mind any actual _use_ of the OS.
So, yeah, I'm pulling a tentative AWOOGA here: I don't think this shrink functionality is fit for purpose as-is. Many apologies for not catching this earlier, I somehow just never quite grokked that it'd be a big issue.
I know adding UI at this late stage is dicey, but I think partition shrinking is fundamentally not something that can be reduced to 'do it or don't do it'. It's not a binary operation. I can't see any way of fiddling with the padding numbers that will give a sensible result in all - or even most - partition resize use cases. I'm not sure we can fix this without adding back the option to set the shrink size, and I think we _do_ need to fix it. If anything, the alternative would be to drop the shrink function from the non-custom path - at least then people couldn't shoot themselves with it.
If anything, the alternative would be to drop the shrink function from the non-custom path - at least then people couldn't shoot themselves with it.
Yes, dropping shrink function from a guided mode and keeping it just in the custom mode would be much better than the current situation. And it doesn't require much effort - just removing a single button.
On Sun, 2012-12-16 at 11:23 -0500, Kamil Paral wrote:
If anything, the alternative would be to drop the shrink function from the non-custom path - at least then people couldn't shoot themselves with it.
Yes, dropping shrink function from a guided mode and keeping it just in the custom mode would be much better than the current situation. And it doesn't require much effort - just removing a single button.
Before everyone gets gung-ho on this one, I'd still much prefer if we could just _fix_ it. But if that isn't really plausible, dropping the function is an acceptable if regrettable compromise.
On Dec 17, 2012, at 2:52 PM, Adam Williamson awilliam@redhat.com wrote:
On Sun, 2012-12-16 at 11:23 -0500, Kamil Paral wrote:
If anything, the alternative would be to drop the shrink function from the non-custom path - at least then people couldn't shoot themselves with it.
Yes, dropping shrink function from a guided mode and keeping it just in the custom mode would be much better than the current situation. And it doesn't require much effort - just removing a single button.
Before everyone gets gung-ho on this one, I'd still much prefer if we could just _fix_ it. But if that isn't really plausible, dropping the function is an acceptable if regrettable compromise.
If it gets dropped, all the more I think this bug will need to be NTH'd:
Existing Windows 7 appears under 'Unknown' in Manual Partitioning https://bugzilla.redhat.com/show_bug.cgi?id=887112
Chris Murphy
anaconda-devel@lists.fedoraproject.org
-
Adam Williamson -
Chris Lumens -
Chris Murphy -
Kamil Paral -
Tim Flink