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
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...)
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 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_...
again, please let me know of any problems you see with this change :) Thanks everyone!
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_...
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.
On Tue, 2016-10-04 at 04:30 -0400, Kamil Paral wrote:
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.
This is basically the alley I was chasing down this morning in the shower, but more important stuff took over.
I don't quite see why you claim that Workstation live is the only case where we should test optical media any more. Why is Workstation live special? Why not the KDE live? Why not the Server DVD? I just don't get the grounds for the distinction.
It sucks, but I'd say in an ideal world we would actually be testing all supported boot methods - VM 'optical disc', real optical disc, each supported USB write method - for each image, for both x86_64 and UEFI. Given that we have six release-blocking ISO images, if we only tested one USB write method, that'd be 36 tests. Fun for all the family! Add another 12 for each support USB write method we decide to test independently...
We could do this either as three tables, or as one table with six result columns. Not really sure which is best.
I don't quite see why you claim that Workstation live is the only case where we should test optical media any more. Why is Workstation live special? Why not the KDE live? Why not the Server DVD? I just don't get the grounds for the distinction.
I was thinking about real world scenarios, and Workstation Live is the only one that is probably going to be given away on optical discs (at conferences, university events, etc). KDE Live would probably also fit in this. I don't think we're ever giving out Server discs, or Cloud (ha ha).
As for personal downloads, again Workstation Live is the most commonly downloaded image for standard users, so if the machine can't boot from USB, this is likely the image that is going to get burned to a DVD. I don't think people install servers from optical media too much, but I might be wrong. But for Server, sysadmins are probably able to leverage a different method of installation anyway (pxeboot).
Ideally we should of course test all combinations. But that's not practical. So this was all about covering the most commonly used methods.
It sucks, but I'd say in an ideal world we would actually be testing all supported boot methods - VM 'optical disc', real optical disc, each supported USB write method - for each image, for both x86_64 and UEFI. Given that we have six release-blocking ISO images, if we only tested one USB write method, that'd be 36 tests. Fun for all the family! Add another 12 for each support USB write method we decide to test independently...
Right. We clearly need to pick a "reasonable subset".
On Tue, 2016-10-04 at 10:30 -0400, Kamil Paral wrote:
I don't quite see why you claim that Workstation live is the only case where we should test optical media any more. Why is Workstation live special? Why not the KDE live? Why not the Server DVD? I just don't get the grounds for the distinction.
I was thinking about real world scenarios, and Workstation Live is the only one that is probably going to be given away on optical discs (at conferences, university events, etc). KDE Live would probably also fit in this. I don't think we're ever giving out Server discs, or Cloud (ha ha).
Well, no, but I don't think we've given up supporting people actually writing ISO images to optical discs yet. Though it might be good to run some kind of survey to find out just how many people actually do still do this rather than use USB.
Ideally we should of course test all combinations. But that's not practical. So this was all about covering the most commonly used methods.
See, I'm not totally sure I agree...
It sucks, but I'd say in an ideal world we would actually be testing all supported boot methods - VM 'optical disc', real optical disc, each supported USB write method - for each image, for both x86_64 and UEFI. Given that we have six release-blocking ISO images, if we only tested one USB write method, that'd be 36 tests. Fun for all the family! Add another 12 for each support USB write method we decide to test independently...
Right. We clearly need to pick a "reasonable subset".
I actually didn't mean that. In this case I was being sincere: I actually think we *should* test every single combination. At *least* for Final. When all's said and done, Fedora is in the business of releasing operating systems, and we're the Fedora QA team. It might be tedious, but we absolutely *should* check that every single release- blocking image we ship actually boots when written in every one of our officially-supported ways. It's not as if we haven't had weird bugs in this before. We've had images that booted fine in VMs but not when written to actual optical media. We've had cases where just one image didn't get isohybrid written on it for some reason and so wouldn't work with dd (or FMW, now).
I'm OK with fudging this a bit for Alpha and Beta, but I do actually think that we should do all those 36 tests for Final at least.