> Hey folks! Wanted to send a heads-up that I've made some fairly > significant changes to the wiki regarding writing Fedora to USB. > > I've done (yet another) revision of the main wiki instructions for > writing USB sticks: > > https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB Thanks! > > since the Fedora Media Writer tool - the rewrite (of the rewrite?) of > LiveUSB Creator - now looks to be working well in testing, and is > available on all our target platforms, the page now heavily promotes it > as the best tool to use in almost all cases. Some other methods have > been entirely removed - FMW should be a better choice for Windows and > macOS than the tools that were listed before. > > I retained sections for: > > * livecd-iso-to-disk, as it's now the only tool that supports non- > destructive write and data persistence > > * gnome-disk-utility, for non-Fedora *nix without Flatpak support > > * dd, for non-Fedora *nix without Flatpak or GNOME and people who just > like dd > > * unetbootin, because the section basically exists to explicitly state > that we don't support it (maybe we should add a similar section for > Rufus...) I'd probably create a new top-level headline called "Non-recommended tools" or "Known to be broken tools" and put unetbootin in there. Because currently if you quickly look over TOC, unetbootin looks like a viable alternative, unless you read the details in its section. A separate section would make it clearer (and we can add more tools in the future). > > Please do tell me about any problems you note, or if you think I > removed something wrongly, or anything. Note that as of right now the > best version of mediawriter for F23 and F24 is in updates-testing, so I > had the instructions to install it include `--enablerepo=updates- > testing`; I'm expecting the updates will go stable soon and we can > remove that. > > For validation testing folks, I have also revised the USB validation > test cases. I really kinda hated the way the Installation matrix was > set up with test names that didn't match the test case page names for > no good reason, and also didn't think we really needed all the > different test cases, so I've consolidated them into three > consistently-named test cases with more result columns: > > https://fedoraproject.org/wiki/QA:Testcase_USB_dd > https://fedoraproject.org/wiki/QA:Testcase_USB_fmw I propose to add a note into this testcase saying that by verifying FMW works correctly you can also mark dd testcase as passed. Because FMW is just a UI on top of dd-like approach, so this will allow more effective test coverage without any substantial risks (I believe). It's not like everyone would ever use FMW and not touch dd from this point on, I wouldn't worry that dd could get broken (that being quite unlikely by itself) without us noticing. > https://fedoraproject.org/wiki/QA:Testcase_USB_litd > > The effect is pretty much the same as before - except that we now > include the FMW test instead of the LiveUSB Creator test - we test all > three methods for both BIOS and UEFI and for both live and DVD images, > but it's just arranged a little differently (and, I hope, better). I > combined the separate 'live' and 'dvd' versions of the dd and litd test > cases (which were barely different at all) into single test cases, and > consolidated common wording between all the test cases using templates. > I've put this change live on the current Installation validation page - > https://fedoraproject.org/wiki/Test_Results:Fedora_25_Branched_20160930.n.0_Installation Shouldn't those columns be called x86_64 BIOS DVD x86_64 BIOS Live x86_64 UEFI DVD x86_64 UEFI Live ? Because currently it might be a bit confusing. Also, should we add Mac and Windows columns for FMW? (And do we block on that? I'm not even sure.) And finally, I was thinking about how to make testing more efficient. With FMW doing a dd copy, I don't think we actually need to perform a default installation for each of those methods, because the written stick should look exactly the same (it's a direct image copy in both cases). I believe doing just one default installation with dd-style-copied image would be sufficient, and in the other case we can simply just verify that the image passes verification and boots properly into the installer. Would it be too confusing to create a QA:Testcase_USB_dd-like_install row which would mark an install performed, and QA:Testcase_USB_dd and QA:Testcase_USB_fmw would just mark verified image boot? Alternatively, we could somehow connect this to the "Default boot and install" section, which is very much related, and we'll need to rethink it anyway (because currently it says "bare metal required" and we fill it with openqa...). Maybe we could have "Workstation live optical" (which is probably the only case where it still makes sense to test optical media) and the rest would be considered either USB or VM. Also, Live and DVD USB would be already present in QA:Testcase_USB_dd-like_install row. _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
