| Summary: | ISO labels should be shortened to 11 characters, to allow ISO->USB conversion | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Pete Batard <pete> |
| Component: | distribution | Assignee: | Dennis Gilmore <dennis> |
| Status: | CLOSED WONTFIX | QA Contact: | Bill Nottingham <notting> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 16 | CC: | awilliam, dennis, robatino, rvokal |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-02-13 13:58:30 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Pete Batard
2012-02-17 17:52:41 UTC
Looking into the problem a bit further, Fedora isolinux/isolinux.cfg currently uses the following to set the root partition, which, along with the ISO label, is also where the problem lies: append initrd=initrd0.img root=live:CDLABEL=Fedora-16-i686-Live-Desktop.iso ... As previously indicated "Fedora-16-i686-Live-Desktop.iso" is the exact Volume ID from the ISO image, and the one used by /dev for the disk label. Independently of asking you to change your ISO Volume ID and isolinux.cfg, the current workaround ISO -> USB users of Fedora can apply is to edit /isolinux.cfg/syslinux.cfg on the USB and modify the "root=live:..." section with either "LABEL=<USB_LABEL>" or "CDLABEL=<USB_LABEL>". I have tested both, and the USB booted as expected then (with CDLABEL working regardless of whether a CD or USB was actually used). However, as more and more people are going to use USB over optical media, especially as target systems may not have any optical drive and it is much faster, I believe the better long term solution is to ensure that the ISO content can also be used for USB, by making its Volume ID FAT compliant. Simply setting the Fedora volume label to 11 uppercase characters, and updating the isolinux.cfg root section accordingly will most certainly do the trick. I'd also suggest dropping CDLABEL for LABEL, and dropping CD specific actions if possible, in order to make it more universal, but as indicated, the use of CDLABEL also seems to work with USB for now. For the record, using a FAT compliant label for ISOs, while using /dev/disk/by-label/ for mounting root is also the approach the Arch Linux distribution has taken (for instance, their latest ISO uses the label "ARCH_201108"). we do have an official method for writing USB live images from Windows which I don't believe is susceptible to this problem - https://docs.fedoraproject.org/en-US/Fedora/16/html/Installation_Guide/Making_USB_Media.html . I'm not sure it's a good road to go down to start making significant changes to this stuff to oblige arbitrary third-party tools... -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers further thought, we often get issues reported with using unetbootin to write USB sticks, and our position there is usually that unetbootin should fix it. The problem with this approach is that, the ISO -> USB tools need to be aware of the label you use for each ISO you release, and provide the appropriate option then (or try to generically identify the label in the existing isolinux.cfg, and replace it, which is the workaround I have now applied in my tool - but it's a quick and dirty one that modifies the original ISO content). For instance, and this is probably the reason for the reports you have, unetbootin or Universal USB Installer users, which are 2 tools that ask their users to select the exact distro version from a list, if you have a new release tomorrow, then, because these ISO -> USB tools need to know it, existing versions of the tool cannot be used. Basically, unetbootin and Universal USB Installer have to maintain a DB in their software that does something like: Fedora v16.0 x86 -> Fedora-16-i686-Live-Desktop.iso Fedora v15.1 x86 -> Fedora-15b-i686-Live-Desktop.iso Fedora v15.0 x86 -> Fedora-15-i686-Live-Desktop.iso These conversions are not expected to be guessable, so the day Fedora 17 is released, it is incompatible until the tools update. These tools will also install their own isolinux config files as a result, rather than modify the existing ones, which usually share the same background screen and features, for all Fedora releases. If you have a chance, I would encourage you to have a closer look at what unetbootin, Universal USB Installer actually do behind the scenes, before deciding whether you want to follow through with this request or dismiss it. Especially the "source" from Universal-USB-Installer, available at: http://www.pendrivelinux.com/downloads/Sources/USB-Installers/Universal-USB-Installer/Universal-USB-Installer-1.8.8.4-src.zip. and the fedora-syslinux.cfg that you will find in the /text/ directory may give you a better idea of how these tools have to overwrite your existing files with their own version, because of this constraint. well, they *are* guessable, the naming scheme is consistent, although admittedly I don't think it's not formally defined anywhere. We do not do .1 releases - there is no '16.0', '15.1', '15.0', there is only 15 and 16. The DVD ISO names and labels have been consistent since Fedora 8, according to a quick check at https://archives.fedoraproject.org/pub/archive/fedora/linux/releases - the Fedora Core 8 DVD ISO is named Fedora-8-x86_64-DVD.iso, exactly the same format as the most recent release, Fedora-15-x86_64-DVD.iso. The live ISOs have changed very slightly more - the arch came after the word 'Live' until Fedora Core 9, and the desktop live did not have the word 'Desktop' added to its name until Fedora 14, but since F14 all the names have stayed precisely consistent. I don't think there is any plan to change them again in the near future (unless this bug results in it happening), but it might be a good idea to solidly define the naming scheme (we could make this part of the Deliverables SOP I've had lying around my todo list for a while). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers If I wanted to argue, then I'd say one has to guess that it's supposed to be guessable... ;) The problem I see is, unless you set these labelling rules in stone, it'll be hard for application to be 100% certain that your naming will remain consistent, and while I can't speak for what the Universal USB Installer and Unetbootin will do, I suspect that they will still wait for an ISO to actually be released before they list it, as otherwise, since users are very much forced to select their Fedora version from a list, they may be quite confused about seeing Fedora 19 or 20 being listed well before they have been released. This also creates the issue of how far ahead the Universal USB Installer and Unetbootin developers should plan? If they plan too far ahead, user confusion is likely, and if too little, regular updates will still be necessary as before... Personally, I still see the Arch Linux approach, of only using ISO labels that are also FAT compatible, as the safest approach to ensure that the distribution users won't encounter issues or a requirement to upgrade, during their ISO -> USB conversion. This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |