Re: Discussion: what would not blocking on btrfs look like?
On Wed, 2019-08-28 at 15:59 -0600, Chris Murphy wrote: > > On one hand I understand all of the consternation around making btrfs bugs > > blockers for Fedora, but on the other hand it seems a bit silly to be having > > this conversation at all based on hitting a bug that went into the merge > > window > > and then was fixed before rc1 was even cut. Thanks, > > It is silly, if it's really safe to say that Btrfs won't be the > default file system in any release blocking deliverable. Having > blocker status was always a means to that end. But right now it's > maybe three (?) automated tests that depend on Btrfs working. If > Fedora Workstation defaulted to Btrfs, that's dozens or even hundreds > of tests? Adam? Well, yeah, but they all use the same filesystem layout. So either they all work or they're all broken, so far as any filesystem bug is concerned. But anyway, I've said this once already, but just to say it again: this discussion isn't happening because of any specific concern related to the bug that was linked in the original mail. The bug simply alerted the kernel team to the fact that we currently block on btrfs, which is something they thought we shouldn't do *anyway*. It's nothing to do with that particular bug at all. They just hadn't yelled about it before because, until an actual blocker bug showed up, they weren't aware of it. > And another question for QA. If it were Btrfs by default for > Workstation, would you just convert all the tests that rely only on > ext4 now to Btrfs? Or duplicate those tests so you can run them in > parallel? How much more testing is that and what's the impact on time > and resources? I mean, there wouldn't be any 'conversion'. That's just sort of not how the tests work. The tests work by running the installer and clicking stuff (talking about the openQA tests, here). If the default filesystem is different most of the tests will run the same - they'll just happen to be using a different default filesystem. I wouldn't duplicate all the tests and run them all on different filesystems, no, there isn't really much justification for that. We already theoretically block on about eight different filesystems, we don't re-run every single blocking test on each of those filesystems. If you start trying to do that kind of combinatorial testing you're going to blow up quite rapidly - do we do every single test on each blocking desktop on each blocking arch with each blocking filesystem on both BIOS and UEFI with three different graphics cards? By the time you multiply all those factors by each other you're probably already looking at several billion tests, and I haven't even thrown in another half-dozen factors I easily could throw in. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: Discussion: what would not blocking on btrfs look like?
; The installer team rejecting btrfs patches is going to be based on their > resources to support the functionality. But then why not think about whether those resources are available outside just the people Red Hat pay to work on anaconda? If there are other folks banging on our door and telling us they really want to work on supporting btrfs, wouldn't it be cool to at least try and see how that could work? > I would say "btrfs in Fedora" > needs a FESCo decision to set expectations and policy for the project. > Is it something that Fedora wants to offer and if so, what does that > look like? I agree, but I also think this discussion is kind of an input to that decision. I don't know that FESCo can simply make it in a vacuum. > If it's a best effort thing, then that makes it easier for > projects and contributors. Going back to Adam's original list, I would > suggest a FESCo decision like this should require explicit opt-in by the > user to enable btrfs functionality in the application in question. For > example, in the installer that could be enabled via a boot parameter (we > did this initially when btrfs functionality was first enabled in anaconda). That's exactly the kind of thing that would be helpful to the community, indeed. If everyone can agree on this, that gives them an entry point. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: Discussion: what would not blocking on btrfs look like?
On Tue, 2019-08-27 at 08:57 -0400, Josh Boyer wrote: > > > There *was* a PR submitted. It was even a one-liner because the > > contributor fixed the underlying problem elsewhere. It's been in limbo > > for over a year: https://github.com/rhinstaller/anaconda/pull/1375 > > > > You seem to think that I'm just shouting without any effort to back it > > up. There was originally four of us working on this two years ago. > > It's dwindled over time as the roadblocks were thrown up time and time > > again. > > No, I don't think that at all. I think you've taken that PR, which > was rejected because the project doesn't want to do more btrfs > enablement, and generalized it to "nobody can contribute to anaconda". > That's my point. You're using hyperbole as an argument for something > specific. > > If you have other PRs that were general bug fixes or unrelated to > btrfs which were rejected, I think it would be refreshing for all > involved to look at why again. That would indicate a contribution > model problem to me. Not a single feature/PR the project doesn't want > to include. Josh, to be fair, I can see Neal's point here. In a way you seem to be kinda sending him in circles here: "anaconda team doesn't have the time/resources to invest in btrfs development, but you can help by sending them pull requests. Oh, you sent them a pull request and they rejected it? Well, it's because they don't have time/resources for btrfs development..." You're right that one rejected PR doesn't necessarily indicate a contribution model problem, but putting the wider issue aside, a very simple one-liner with a major impact on btrfs functionality being rejected *does* seem to say a lot about the prospects of any btrfs-related work being accepted. Putting myself in Neal's shoes, given my experience with that PR and other attempts to help out with btrfs in anaconda, why would I invest my time and effort to write another one when it seems extremely likely it would be rejected? I think we at least owe it to people to be clear about whether there is any point in them investing time and effort *trying* to contribute to btrfs support in anaconda, and if the answer is currently "no", whether there would realistically be any prospect of there being any way to change this. I also think there are other perspectives that might at least potentially be useful here. Right now we've mainly heard from a couple of community folks who are very passionate about btrfs, and Red Hat folks from anaconda/kernel development and RHEL management who essentially see it as a burden that is not aligned with their priorities. Is that all the perspectives we have to make a decision with? I think we should at least talk to the Facebook team that apparently uses btrfs on Fedora extensively about whether they'd be sad to see installer btrfs support die and, if so, whether they'd perhaps be interested in helping support it. And more broadly, community folks on all the lists this is going to: are there more people who actually are interested in this functionality and would be sad to see it go? If btrfs isn't a part of Red Hat's product roadmaps but is important to lots of folks in the wider Fedora community, maybe that's another indicator we can useor indeed, if it turns out not many folks actually care. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: Discussion: what would not blocking on btrfs look like?
On Mon, 2019-08-26 at 19:33 +0200, Frantisek Zatloukal wrote: > On Mon, Aug 26, 2019 at 4:53 PM Kamil Paral wrote: > > > On Mon, Aug 26, 2019 at 2:42 PM Justin Forbes > > wrote: > > > > > From my standpoint, ext4 and xfs are the primary supported root > > > filesystems. I don't think that anything else should be release > > > blocking. > > > > If this is the case, we can explicitly list the supported file systems in > > criteria. The list would need to be extended with at least vfat, which is > > used for ESP, though. > > > > If we go this route, it would be nice to communicate this somehow to the > > end user, directly in anaconda interface. Either by showing a warning when > > a "not officially supported" filesystem is selected, or by hiding those > > filesystems in dialogs when creating a new partition (with a documented > > override). > > > > Hmm, I don't see this as necessary. I think changing criterions on what > file systems are blocking doesn't mean we need to hide things or add some > ugly warnings. Anybody who uses advanced partitioning should know what is > doing, we can just update criterions so not everything visible in advanced > partitioning must work and is supported. I mean, I don't see that there's necessarily an equivalence between "knowing what you're doing" and "expecting it to be broken". That's the reason I quite like the current criterion: it commits us to not just throwing a bunch of hand grenades at the user in the installer. If we're going to do that it should at least be communicated *somehow* outside of just being in the release criteria. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: Discussion: what would not blocking on btrfs look like?
On Fri, 2019-08-23 at 19:00 -0600, Chris Murphy wrote: > On Fri, Aug 23, 2019 at 1:17 PM Adam Williamson > wrote: > > > So, there was recently a Thing where btrfs installs were broken, and > > this got accepted as a release blocker: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1733388 > > Summary: This bug was introduced and discovered in linux-next, it > started to affect Fedora 5.3.0-rc0 kernels in openqa tests, patch > appeared during rc1, and the patch was merged into 5.3.0-rc2. The bug > resulted in a somewhat transient deadlock which caused installs to > hang, but no corruption. The fix, 2 files changed, 12 insertions, 8 > deletions (1/2 the insertions are comments). > > How remarkable or interesting is this bug? And in particular, exactly > how much faster should it have been fixed in order to avoid worrying > about it being a blocker bug? > > 7/25 14:27 utc bug patch was submitted to linux-btrfs@ > 7/25 22:33 utc bug was first reported in Fedora bugzilla > 7/26 19:20 utc I confirmed upstream's patch related to this bug with > upstream and updated the Fedora bug > 7/26 22:50 utc I confirmed it was merged into rc2, and updated the Fedora bug > > So in the context of status quo, where Btrfs is presented as an option > in the installer and if there are bugs they Beta blocking, how could > or should this have been fixed sooner? What about the handling should > have been different? Nothing. The kernel team's concern is not related to this bug or the handling of this bug in any way. The only relevance of the bug is that it alerted the kernel team to the fact that we currently block on btrfs, which they think we should not. > I note here that ext2 and ext3 are offered as file systems in > Custom/Advanced partitioning and in this sense have parity with Btrfs. > If this same bug occurred in ext2 or ext3 would or should that cause > discussion to drop them from the installer, You're misunderstanding here. It's not the fact that a bug showed up which caused the concern. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Discussion: what would not blocking on btrfs look like?
Hey folks! So, there was recently a Thing where btrfs installs were broken, and this got accepted as a release blocker: https://bugzilla.redhat.com/show_bug.cgi?id=1733388 The bug was fixed, so that's fine, but along the way, Laura said this: "I'm strongly against anything with btrfs being a blocker. If that's in the criteria I think we should see about removing btrfs simply because we don't have the resources to actually deal with btrfs besides reporting bugs upstream." and Justin followed up with: "Agreed, btrfs has been a gamble pretty much always. See previous discussion around proposals to make btrfs default. Ext4 and xfs should be the only release blocking." So, that's the whole kernel team 'strongly against' blocking on btrfs. Which means we should talk about not doing that any more! This is a bit complicated, though, because of how the Final criteria are phrased. Basic does not include btrfs at all, and Beta includes a laundry list we can just remove btrfs from: "When using both the installer-native and the blivet-gui-based custom partitioning flow, the installer must be able to: * Correctly interpret, and modify as described below, any disk with a valid ms-dos or gpt disk label and partition table containing ext4 partitions, LVM and/or btrfs volumes, and/or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions * Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions ..." so those two are easy. However, the Final criterion is not laundry list-style. The relevant Final criterion is this: "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration." with a somewhat apologetic explanatory footnote: "Wait, what? Yeah, we know. This is a huge catch-all criterion and it's subject to a lot of on-the-fly interpretation. Broadly what it's 'meant to mean' is that you should be able to do anything sane that the Installation Destination spoke attempts to let you do, without the installer exploding or failing. We are trying to write more specific criteria covering this area, but it's not easy. Patches welcome, as the kids say..." so as the footnote says, the rule is basically "if the installer lets you do it, it ought to work". It seems a bit awkward to craft an exception for btrfs from that. I mean, technically it's easy: "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration, except btrfs." but that's odd. Why is btrfs, alone, an exception? It kinda goes against the fundamental idea of the criterion: that we stand behind everything the UI offers. So...what should we do? Here are the options as I see 'em: 1. Keep supporting btrfs 2. Just modify the criterion with a btrfs exception, even if it's weird 3. Rewrite the criterion entirely 4. Keep btrfs support in the installer (and blivet-gui) but hide it as we used to - require a special boot argument for it to be visible 5. Drop btrfs support from the installer I'm bringing this to anaconda, kernel and test teams initially to kick around; if we agree on an approach we should then probably loop in devel@ for wider review, unless the choice is 1). Thanks for any thoughts, folks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: anaconda crashes on Rawhide since December
On Mon, 2018-02-05 at 00:52 -0700, Chris Murphy wrote: > Bug 1524700 - AttributeError: 'NoneType' object has no attribute 'name' (edit) > https://bugzilla.redhat.com/show_bug.cgi?id=1524700 > > > This is still a bug in > Fedora-Workstation-Live-x86_64-Rawhide-20180204.n.0.iso, and every ISO > I've tested for over a month; and this bug was filed back in December. > Near as I can tell, no one's been able to do live installations of > Rawhide in about two months. This part isn't strictly true, though. This only happens if the medium is considered 'removable', I believe. Installs using an actual optical disc or in a VM with the ISO attached as an optical disc (not a USB stick) should work fine, and do work fine in openQA: https://openqa.stg.fedoraproject.org/tests/236240 -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: anaconda crashes on Rawhide since December
On Mon, 2018-02-05 at 00:52 -0700, Chris Murphy wrote: > Bug 1524700 - AttributeError: 'NoneType' object has no attribute 'name' (edit) > https://bugzilla.redhat.com/show_bug.cgi?id=1524700 > > > This is still a bug in > Fedora-Workstation-Live-x86_64-Rawhide-20180204.n.0.iso, and every ISO > I've tested for over a month; and this bug was filed back in December. > Near as I can tell, no one's been able to do live installations of > Rawhide in about two months. I can reproduce it in a clean > virt-manager VM, and on baremetal. > > Does this bug need info to get it fixed? I'm unclear what the hold up is. No, it doesn't need any information. https://bugzilla.redhat.com/show_bug.cgi?id=1524700#c21 is the current status, AFAIK. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: logging mount assembly and bootloader install, chroot missing?
On Tue, 2017-08-08 at 12:22 -0600, Chris Murphy wrote: > The program.log shows mount commands for assembly, followed by > installation itself copying files to a path prefix /mnt/sysimage, and > then bootloader setup. Isn't there a chroot happening before the > bootloader setup? It's not in the log so I'm having some difficulty > exactly replicating an installation environment while troubleshooting > this bug: > > So the questions are: > Is there a chroot? > Is there a way to discover the command being used? > And if there is a chroot, is there a way to log this command in the future? > > > https://bugzilla.redhat.com/show_bug.cgi?id=1289752 Use the source, Luke: https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/bootloader.py and then search for 'root='. You'll find that most of the bootloader installation-related commands run via iutil.execWithRedirect, with root set to iutil.getSysroot() . Of course, you can look in iutil.py to see what these do. If you *do* look there, you'll see that indeed the relevant functions don't *currently* log the root argument. I think a PR to add this wouldn't be unreasonable. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Running kickstart-tests in openQA: should we?
. In scenario 1), kickstart-tests would be pretty much unmodified and we'd have to keep working on the converter to keep its behaviour in line with the official stuff. We *could* invent some kind of intermediate format for specifying test requirements which would be interpreted differently by the openQA and 'native' runners, but I suspect that would sound like a lot of engineering. ## What other choices are there besides using openQA? 1) Forget the whole damn thing and just keep on with our separate approaches. I'm sending this email now because I'm still at the point where I'd be fine with this decision; I've only burned 3 days on this work and I learned a lot about the kickstart-tests while doing it. 2) Keep the separate testing approaches, but possibly look at harmonizing test image generation and test triggering and maybe result storage somehow. 2) Look at running the kickstart-tests in Taskotron (possibly along with Beaker?) instead of openQA. tflink is quite interested in this, I think, and I *may* give it a shot. No promises. 3) Wait for the possibly-inevitable introduction of some sort of 'Central CI'-ish Jenkins thing into Fedora and then see if maybe we want to use that for running these tests. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: Blocker status of RHBZ #1033778 (shrinking unknown volumes)
On Wed, 2016-03-02 at 22:28 -0700, Chris Murphy wrote: > As for whether it's a blocker bug: In three blocker meetings everyone > was prepared to make it a blocker on the merits of the bug. My > educated guess is no one wanted to fight with you about it when you > dole out derision like Kleenex, and also added further duress by > saying: This tone is really not warranted. We agreed the bug would have violated the criterion as written, but we also observed that this isn't a situation that was actually envisaged when writing the criterion; the criterion was written thinking about the case where anaconda incorrectly tried to resize a partition it understood, it was not intended to prescribe anaconda's behaviour with regard to partitions it does not understand. I can tell you that, as I wrote it. > > 18:38:23 lol > 18:38:23 I might go so far as to get myself kicked > out of the fedora project before "fixing" that > https://meetbot.fedoraproject.org/fedora-blocker-review/2016-02-22/f24-blocker-review.2016-02-22-17.00.log.html The quote out of context is maybe misleading, and I think quoting it at two removes (from #anaconda IRC to the blocker meeting to here) is a little unfair. I believe that, in context, dlehman was referring to the idea of "fixing" detection of Apple Core partitions, not the possibility of tightening down on resize of unknown partitions. > This is untenable for QA to make the bug a blocker when the upstream > announces in advance they won't fix it. How does that play out? Your > (circular) logic here is, it's not a blocker because you say it's not > a blocker. You've simply bugged out of participating in a neutral 3rd > party process established to arrive at a minimum quality releasable > product. QA folks went with the pragmatic path of least resistance, > didn't they? I see no where that they agreed with your reasoning, > because you didn't provide any reasoning. We discussed it in this very thread, the reasoning is available in dlehman's earlier posts to it. Personally I think his position is entirely reasonable. The blocker process is not one where "QA make[s] the bug a blocker". The blocker process, as designed, is a collaboration between QA, devel, releng, and product management (FPL and FPM). Note the inclusion of devel there. The criteria were initially written in close collaboration with the development teams, and are frequently adjusted to reflect their conception of what's practical and reasonable, and development teams absolutely are expected and intended to have input into the blocker process. > This sounds pretty close to perfect as a conditional blocker, a.k.a. > it's a "local configuration dependent issue" since it mainly affects > OS X users with the default partitioning layout now in use on that OS, > and then the user proceeds with resizing this unknown partition for > whatever reason. Fix it whenever you want. Maybe someone beats you to > it. And consider trusting QA to make it a blocker at some point if > more users hit it. I don't really see a problem with that method of > making it not an immediate blocker for this release. > https://fedoraproject.org/wiki/Blocker_Bug_FAQ I'm not quite sure what you're suggesting here; are you suggesting that we could have rejected it as a blocker on the basis that it's a conditional violation of the criterion and we declare that the impact is not broad enough? We could have done that, sure, but in the end we went a different way as we wanted to clarify the question of whether the criterion was intended to dictate anaconda's behaviour with regard to unknown partitions. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: Blocker status of RHBZ #1033778 (shrinking unknown volumes)
On Mon, 2016-02-29 at 09:29 -0500, David Lehman wrote: > On Fri, 2016-02-26 at 14:03 -0800, Adam Williamson wrote: > > > > On Wed, 2016-02-24 at 09:40 -0500, David Lehman wrote: > > > > > > > > > > > > > > "This means that if the installer offers mechanisms for resizing > > > > storage volumes, then it must run the appropriate resizing tool > > > > with > > > > the appropriate parameters for the resize the user chooses. The > > > > reason > > > > > > What is the appropriate tool (and parameters) for resizing the > > > formatting on a device with unrecognized/unknown formatting? > > I don't believe we explicitly considered that question at the time of > > writing the criterion. However, my interpretation as the person who > > drafted it (IIRC) would be that the "appropriate tool" for any > > partition with data on it is a tool which is at least *intended* to > > preserve the data. > > > > In an ideal world, with no specific technical concerns, it would be > > my > > expectation that we would not offer an operation named "resize" in > > the > > case where we have no idea how to preserve any contents of the > > volume. > > We would only offer an operation named "resize" in cases where we do > > actually have some idea how to perform a non-destructive resize. I'm > > entirely open to there being technical reasons why this is not > > possible, though. > It is not possible to distinguish between a lack of meaningful data and > meaningful data that the OS has no means of recognizing. A partition > type flag or GUID is not generally sufficient for this purpose. > > We do have the option to prevent resize of devices with no formatting > or unrecognized formatting. You could certainly argue that it makes > more sense to remove such a device than to resize it if you need more > space. I'll just explain that it's in the name of protecting careless > users when the bugs start coming in. So basically it's another shoot-yourself-in-the-foot conundrum, with the standard choices? Leave the safety off, put a dumbass "Are you sure you want to do that?" message in front of it, or disallow it and annoy some partition pokemon with an implausible use case for it? Well hey, life sucks. I *think* my preference, if you asked my opinion, would be to disallow it and just say "if it's an empty partition you really want to make smaller, just do it in another tool or delete it and recreate it smaller". But if you think the balance here should be in favour of letting people shoot themselves in the foot, I'm not gonna argue it, and we'll just have to rewrite the criterion somehow. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: anaconda design mockups
On Thu, 2016-02-25 at 17:46 +0100, Garrett LeSage wrote: > One kind of funny example I encountered: A quite-technical co-worker who > routinely installs Fedora for work told me that he originally thought > his hard drive was "bad". He eventually even bought a new hard drive — > and after thinking that one was marked as being bad too. Of course, > after a little bit of questioning, it turned out that it's just how > Anaconda flags a necessary step — even when it should not be necessary > (as in the case of a blank drive). IIRC, in the initial iterations of the current anaconda (i.e. in F18), INSTALLATION DESTINATION was not mandatory and would auto-configure itself when possible. We explicitly chose to move away from that and require the user to at least visit it and confirm the defaults. I don't entirely recall why, but presumably we had a reason. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: Blocker status of RHBZ #1033778 (shrinking unknown volumes)
On Wed, 2016-02-24 at 09:40 -0500, David Lehman wrote: > > > "This means that if the installer offers mechanisms for resizing > > storage volumes, then it must run the appropriate resizing tool with > > the appropriate parameters for the resize the user chooses. The > > reason > What is the appropriate tool (and parameters) for resizing the > formatting on a device with unrecognized/unknown formatting? I don't believe we explicitly considered that question at the time of writing the criterion. However, my interpretation as the person who drafted it (IIRC) would be that the "appropriate tool" for any partition with data on it is a tool which is at least *intended* to preserve the data. In an ideal world, with no specific technical concerns, it would be my expectation that we would not offer an operation named "resize" in the case where we have no idea how to preserve any contents of the volume. We would only offer an operation named "resize" in cases where we do actually have some idea how to perform a non-destructive resize. I'm entirely open to there being technical reasons why this is not possible, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
