> So I want to inject a note of caution on this one. A few of us who deal > with boot stuff - me for QA purposes, mjg59 and pjones who actually know > what's going on, and lmacken who maintains luc right now - talked this > over a few months back, and what would like to do with luc is kill it, > or at least radically revise it. It's kind of a bad tool. > > We have this problem where we do the same work (make a USB stick > bootable on BIOS, UEFI and Macs, basically) three times: well when > generating the images (which is why 'dd' works reliably), pretty well in > livecd-iso-to-disk so long as you pass the right options (which is why > that tool's the best second choice), and really pretty badly in luc > (it's better than it used to be, but still not great; I don't believe it > writes Mac-bootable images, and it's easy to use an existing stick and > wind up with something non-bootable because of filesystem or MBR > issues). We need to do that work just once, ideally. > > luc doesn't have anywhere near enough development resources; I think it > comes like five or six items down lmacken's priority list, and he's the > sole person working on it. I don't think that's enough support to lean > on too strongly for 'official distribution' purposes. This is why I > revised the USB instructions on the wiki to prioritize dd-style apps for > Windows and de-emphasize luc. > > I think what we'd have in an ideal world is a Windows tool that distros > which ship dd-friendly images (ourselves, Arch, SUSE, Mageia...) could > share and possibly customize, but which shared the core 'dd this image > to this stick' code and maybe had a standard API you could provide a > list of your distro's images to or whatever. You can do persistent > storage with a dd-style tool, potentially; all it needs to do is dd the > image and then create empty partition(s) in the remaining spare space on > the stick and use *those* for persistence. The only thing you can't do > with dd-style writing is a non-destructive write, but that's far less > important than it used to be now you get 16GB USB sticks free with > breakfast cereal (more or less). Thanks for behind-the-scenes story, I couldn't agree more here. > > If we can't manage that, I'm a fan of making it more obvious from the > download pages how to get a USB stick *somehow* - some better > integration of the download page and the USB writing instructions and > existing tools - but I'm not sure the current luc is good enough and > supported enough to promote as a primary delivery mechanism. Even though luc has so many issues, and even though our Fedora wiki guide [1] no longer lists is as the first option, I had the notion that it was already *the tool* recommended by default. Because fedoraproject.org only links to our docs page [2], where it is the first tool mentioned for both Linux and Windows users. Unfortunately I don't see fp.o linking to [1] anywhere. So maybe this is something we could easily improve on? Let's make those USB writing instructions a bit more visible (because nowadays, USB booting really concerns at least every other person). And if we're sure we don't want to recommend luc, let's put there the "quick start" method from [1] at least for Windows, i.e. recommending dd-alternatives like "SUSE Studio ImageWriter or Rawrite32". Could we do something about duplication of [1] and [2]? Maybe link to [1] instead of [2] from fp.o? [1] https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB [2] http://docs.fedoraproject.org/en-US/Fedora/20/html/Installation_Guide/Making_USB_Media.html Of course, I still see a lot of value in printing a reasonable dracut message in case the boot fails (a safety net of some kind), so that would be a second thing where we can improve things easily. I can request it in the Bugzilla, or maybe there is some volunteer to create the patch? -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
