It's a well-known fact in our circles that third-party USB conversion tools (like UNetbootin or Universal USB Installer) can't create Fedora Live USB correctly. Unfortunately, it is not well known among our users (I see it very often on test list, IRC, or local fedora.cz website/forums) and even journalists. This is an article that was published yesterday showcasing difficulties of Fedora installation process (translated from Czech by google translate):
https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=cs&ie=…
The purpose of that article is to highlight the fact that Linux has made a lot of progress in the last years, but the results are still a bit like a Russian roulette. Fedora, in this case, is shown as the negative example. The website itself is not known for high quality articles here in CZ, but they are quite popular and have a large reader base. They are mainly Windows-focused, but with the recent advancement of Linux on all fronts (mainly in gaming), they're clearly willing to provide more Linux coverage - and they picked Fedora as their second option right after Ubuntu, which is great. Provided they're able to install it in the first place...
The result of Live USB boot attempt is often this (from the article):
http://www.zive.cz/uploadedfiles/38598240.png
I wonder, is there something we can do to improve the situation?
* We have no control over third-party USB conversion tools.
* Even if we file bug reports, they are often ignored (Adam Williamson said he tried to communicate with UNetbootin, unsuccessfully).
* Third-party USB installers fail for many distributions, like OpenSUSE <http://en.opensuse.org/SDB:Live_USB_stick> or Arch <https://wiki.archlinux.org/index.php/USB_Flash_Installation_Media#Using_UNe…>.
* Still, they are hugely popular, because Ubuntu and its derivatives dominate the market and those tools usually work fine for them.
* The users simply don't know that those tools shouldn't be used, and some others should be used instead.
I don't known the technical details about USB conversion process, but maybe we could collectively think of some changes that would improve the current state at least a bit?
Some ideas:
1. First and foremost, we should obviously consider whether we can make some compose changes that would make the image more compatible with third-party USB installers. That's very technical, but I hope relevant people could provide some comments here.
2. Second, we could make USB conversion instructions more visible on our pages. If you look at http://fedoraproject.org/, there's a big Download Now! button, which gives you the ISO, but you'll never encounter any suggestions what to do with it. That's only available at http://fedoraproject.org/en/get-fedora#desktops in the right column (which is nice and quite visible, I think). Could we provide the same information on the front page?
3. Third, if everything goes wrong and you end up in a dracut shell, could we at least advise our users what went wrong and what to do with it? Because the current output is very scary and very hard to decipher by a general user:
http://www.zive.cz/uploadedfiles/38598240.png
So what if we detected that we failed to find a partition having "Fedora-Live" in its name (thus most probably an incorrectly created LiveUSB), and in that case printed out something like this?
*******************************************************************************
* It seems Fedora Live image could not have been accessed. This often happens *
* when Live USB media is incorrectly created by a third-party USB installer. *
* Please refer to official documentation on fedoraproject.org for proper *
* instructions. *
*******************************************************************************
(native speakers will surely make it sound better)
This would help our users a lot to understand what's wrong and how to fix it. Also, it would be much easier to google out the problem. If we included the same text on our LiveUSB instructions page <https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB>, it could receive a very good position in online search results.
So, what do you think? From my experience, the inability to boot USB is very common and I'd even say it's one of the major problems why new users walk away from Fedora. Because, understand, they don't even know something is wrong on their end. That scary dracut error looks like a problem in Fedora, and therefore often their conclusion is "Fedora is so broken it can't even boot". If we try to mitigate the problem at least with clear explanations, we will not only discourage less users, but also decrease the number of negative reviews by journalists.
Hi all,
I'm unable to contact Russell Cattelan (cattelan{at}xfs[dot]org) for
almost one year[1]. I vetted his login records and found that since
2011-11-15 he hasn't logined to Fedora any more:
Last login in FAS:
cattelan 2011-11-15
As the package xxdiff needs some love(it still even depends on Qt3
whereas the latest version has ported it to Qt4), as a result I'd like
to take it over and fix it.
Thanks.
[1]---https://bugzilla.redhat.com/show_bug.cgi?id=998969
Yours sincerely,
Christopher Meng
http://cicku.me
Hello,
I'm maintaining a VPN server in fedora and I'm wondering whether
I'd need to integrate firewalld to that. After reading the information
in https://fedoraproject.org/wiki/FirewallD I don't think I'm sure what
I'm supposed to do.
There are two issues:
1. Should my service turn on the firewall ports used by the server?
As far as I understand, in order for the service to work out of the box
I'd need to call firewall-cmd --port to enable the TCP and UDP ports
used by the server, possibly from the systemd unit file (are there any
hooks for that?).
2. What zone should the server put the clients they connect. Should
there be some special vpn zone or should I use one of the existing ones?
(none of the existing looks very reasonable for that).
However, what is not apparent to me as a fedora packager is how is that
supposed to be handled. Should the package handle any requirements by
firewalld (i.e., package is plug and play), or should the package defer
the administrator to configure firewalld separately (i.e., package is
installed but doesn't work by default). I see that ssh and few other
services are enabled by default by firewalld configuration itself, but
what about the others?
regards,
Nikos
Fedora,
This is a reminder that the glibc team will be rebasing
glibc in F21 to match glibc 2.20.
The plan remains largely as was written here:
http://fedoraproject.org/wiki/Changes/GLIBC220
Only glibc 2.20 has ABI guarantees, and therefore we
will move to 2.20 before F21 goes to GA to ensure that
F21 has a strong ABI guarantee.
I expect this to be the process forever going forward:
* Rawhide tracks glibc master.
* Fedora release is branched from Rawhide.
* glibc release is made upstream.
* Fedora branch is rebased on glibc upstream release
to include ABI guarantees.
* Fedora release goes GA.
The changes in the rebase should be minor since we've
been tracking master the whole time.
Cheers,
Carlos.