who decided that it is a good idea to hide the grub-menu?
most questions on mailing-lists and boards is "how can
i boot a different kernel" and it makes really really tired
to see that no new user is realizing that Fedora has a boot
this results a) in needless questions and b) new users does
learn nothing because they see nothing as default
I was quite depressed how hard it can be for a layman to find a way to install Fedora from LiveCD environment. If you don't recognize the icon in Gnome Shell Overview mode, it can give you quite some work to find it. Since OSS philosophy is "if you don't like it, fix it", I did. In the last two days I have created a Gnome Shell extension that puts a button on the top bar that says "Install to Hard Drive". It has an icon attached, so it's very visible. The graphics and the text is taken from anaconda's .desktop file, so localization should work OOTB. When you click the button, the installation process starts the same way as if you had run it from the overview.
You can see it here:
What do you think? Better than default?
I personally think it's definitely better than default. I'm sure it can be improved in many ways, but this was my first GS extension ever and I'm really lame, so bear with me (patches welcome). The source code is here:
How to try out:
1. boot F17 Beta RC2 Live
2. extract the extension to /usr/share/gnome-shell/extensions/
3. restart gnome-shell (Alt+F2 -> r)
4. install gnome-tweak-tool and enable this extension
Future steps if people like it:
a) find out how to include this just on the livecd, but not on the installed system
b) modify gsettings to have this extension automatically enabled
c) ask anaconda team to include it into their project and maintain it
CSM-BIOS boot notes:
Apple hardware tested:
mbp41 = MacBookPro 4,1 (2008), Nvidia Geforce8600M GT.
mbp82 = MacBookPro 8,2 (2011), Intel HD Graphics 3000 and AMD Radeon HD 6750M.
All notes based on booting with the Apple-EFI option-key startup menu to choose how to boot, not rEFIt.
1. After default install using any installation type, and reboot, neither model loads GRUB2 (and thus does not boot) by default. Pre or post-install work is needed.
2. Both models CAN boot and startup Fedora to a GUI login with pre- or post-install work.
a. 'nogpt' kernel parameter for Fedora only installs produces a bootable system without post-install work.
b. In dual-boot (Mac OS + Fedora) anaconda isn't creating a hybrid MBR post-install, therefore Apple's EFI startup disk menu doesn't see the F16 installation. Further, creating the hybrid MBR in advance is useless as parted wipes out the hybrid MBR in favor of a protective MBR just prior to installation. (See 3 below for additional fallout of this behavior.)
c. Triple boot (Mac OS, Fedora, Windows) is possible, but there are more ways this won't work, than will work. And more ways that will work, but aren't good partition schemes (invitations for data loss) since there really isn't such a thing as a safe hybrid MBR + GPT. I have found one or two that I think are about as "safe" as they can get, and it means that the user needs to install Mac OS, Windows, Fedora, in that order, but located on the disk in order: Mac OS, Fedora, Windows.
3. Anaconda + parted consistently remove pre-existing hybrid MBRs, replacing them with protective MBRs. The hybrid MBR will exist in a case where Windows has already been installed (using Apple's Bootcamp application). If removed in favor of a protective MBR, Windows is no longer bootable. So not only is Fedora not bootable, a previously bootable Windows is no longer bootable. This happens with either EFI or BIOS mode installs of Fedora.
So either anaconda needs to proceed no further upon discovery of a hybrid MBR, or it needs to become pretty good at sorting out hybrid MBR and GPT schemes that are "safe".
4. gptsycnc: I don't think gptsync has such a sophisticated heuristic for creating such hybrid MBRs - I regularly see it produce very linear MBRs while suggesting huge percentages of the disk are empty. Any MBR only aware tool would see these areas as fair game - what I call an invitation for data loss and probably not a good idea.
5. If all requirements are met, Apple's startup disk menu (option-key at startup chime) will present a single "Windows" disk icon which if selected will load GRUB2 and its menu. That "Windows" label is apparently hard coded in Apple's EFI for any foreign OS requiring legacy CSM-BIOS booting.
Additional EFI boot notes:
1. By default EFI//EFI/redhat/grub.efi isn't found by Apple's EFI and install a choosable option. If it and the .conf are moved to EFI//EFI/BOOT/BOOTX64.efi and .conf, both models have an "EFI Boot" labeled disk icon in the option-key startup menu. I'm guessing like the "Windows" equivalent, that "EFI Boot" is hardwired.
This is being addressed by this:
2. GRUB-EFI (legacy) regularly just hangs are loading the kernel and initramfs, on mbp41. I don't have this problem with GRUB2-EFI but I still have other problems mentioned in the previous email.
W dniu 9 kwietnia 2012 17:46 użytkownik Michał Piotrowski
> 2012/4/5 Robyn Bergeron <rbergero(a)redhat.com>:
>> At the Go/No-Go meeting it was decided to slip the Beta by an additional
>> * Blockers (rbergeron, 15:16:41)
> If I remember correctly, those were some problems with preupgrade due to the
> Is it possible to upgrade now from F16 to F17 with preupgrade?
Has anyone tried to preupgrade from F16 to F17? Are there any problems
related to UsrMove (or anything else)?
For a while now I have been working on a proposal for some changes to
both the way we elevate packagers to sponsors and what (to a small
extent) sponsors actually do. Please note that this is not a proposal
for any changes to how people are made members of the packager group in
the first place and does not change the privileges of existing sponsors.
My proposal is at
I've run this by FESCo, whose response was favorable, so I'm sending
this to a larger audience. Please let me know what you think.
I am using the latest F16 kernel: 3.3.0-4.fc16.i686.PAE and am having
problems with a MicroSD card connected to a USB card reader. This has
been working fine until recently (at least in F14 on the same hardware).
The problem is that "umount" does not appear to be working correctly.
I have an ext3 file system on the card. I can mount it, and I can copy
files to it. However when I use the "umount ..." command it returns
instantly (should sync the files to the card). The system says the card
is unmounted (at least it is not listed with mount, df etc).
However if I run sync, there is a lot of disk activity to the card ...
Also if I try and run "mkfs" it says the device in in use ...
If I mount a blank card it lists the files present on the previous card ...
This sounds like a nasty kernel bug ...
Anyone else seen this ?
one question before decisions are nailed down
> An explicit transition is planned after Fedora 18 with dropping support for the
> static firewall with system-config-firewal/lokkit. A migration from the static
> firewall model will be needed then.
are there only the ui-interfaces meant or do someone
consider drop "iptbales.service" at all? if so please
there are many configurations which are happy with the static
firewall s routers and (distributed) iptbales-scripts
no need, for a graphical UI only a shell-script finished with
/sbin/iptables-save > /etc/sysconfig/iptables does the whole
job as long "/etc/sysconfig/iptables" is load at boot-time
i have one big and distributed "iptables.sh" for more than 20
machines where global settings made for all machines and based
on $HOSTNAME incoming server-ports opend
maybe not everybody likes this model of a 50 KB script but it
works since years has a fine documentation and the flexibility
of a shell-script gives us options which can be hardly replaced
another example: software-router like this
only the snippet with the routing-part:
echo "NAT Routing / Forwarding"
$IPTABLES -A INPUT -i eth1 -s
$IPTABLES -A OUTPUT -o eth1 -s
$WAN_RHSOFT_BROADCAST,0.0.0.0/8,127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,188.8.131.52/3,255.255.255.255 -j DROP
echo "LAN: $LAN_RHSOFT"
$IPTABLES -A FORWARD -i eth1 -o br0 -d $LAN_RHSOFT -m state --state RELATED,ESTABLISHED -j ACCEPT
$IPTABLES -A FORWARD -i br0 -o eth1 -s $LAN_RHSOFT -j ACCEPT
$IPTABLES -A POSTROUTING -o eth1 -t nat -s $LAN_RHSOFT -j MASQUERADE
echo "VPN: $LAN_LOUNGE"
$IPTABLES -A FORWARD -i tap0 -o br0 -s $LAN_LOUNGE -d $LAN_RHSOFT -j ACCEPT
$IPTABLES -A FORWARD -i br0 -o tap0 -s $LAN_RHSOFT -d $LAN_LOUNGE -j ACCEPT
$IPTABLES -A POSTROUTING -o tap0 -t nat -s $LAN_RHSOFT -j MASQUERADE
echo "VM: $LAN_VMWARE"
$IPTABLES -A FORWARD -i br0 -o vmnet8 -s $LAN_RHSOFT -d $LAN_VMWARE -j ACCEPT
$IPTABLES -A FORWARD -i vmnet8 -o br0 -s $LAN_VMWARE -d $LAN_RHSOFT -j ACCEPT
$IPTABLES -A POSTROUTING -o vmnet8 -t nat -s $LAN_RHSOFT -j MASQUERADE
echo "VOIP: $LOUNGE_VOIP"
$IPTABLES -A PREROUTING -t nat -i eth1 -s $LOUNGE_VOIP -p udp -m multiport --destination-port 5060 -j DNAT
$IPTABLES -A PREROUTING -t nat -i eth1 -s $LOUNGE_VOIP -p udp -m multiport --destination-port 50600 -j DNAT
echo "Drop all other forwardings"
$IPTABLES -A FORWARD -j DROP
I read a recent Fedora rawhide report and found that mesa is now at
8.1 (master @ upstream), but then couldn't fetch the Fedora branch
using fedpkg, as I usually do.
$ fedpkg switch-branch f17 (OK)
$ fedpkg switch-branch master (OK, still has the mesa-20120424 snapshot)
$ fedpkg switch-branch f18 (NOK, doesn't exist yet)
* Thu Apr 26 2012 Adam Jackson <ajax(a)redhat.com> 8.1-0.2
- Don't build vmware stuff on non-x86 (#815444)
Any pointers on how to get that update?
I intend to build it locally as I'm also testing Wayland master; which
now requires new symbols from gbm, such as
gbm_surface_lock_front_buffer() and gbm_bo_get_format().
I'm reposting this e-mail, slightly edited and with a much more clear
subject, highlighting the issue.
Zotero is a referencing tool that helps the user collecting,
maintaining and generating citations from research papers and so on.
Since version 3.0, Zotero has also been available as a standalone
executable (previously a Firefox plugin) based on the XULRunner
runtime; and I'm thinking about packaging it for Fedora.
The code base is licensed under AGPLv3, however the program's name
'Zotero' is a registered trademark
I asked the developers
if it was OK to use that same name (even if the source package ends up
slightly changed - mostly the build system actually), but then here I
am asking the same question in order to get more feedback from the
Fedora packaging community:
What's the position of Fedora regarding using the same trademarked
program names (even if the source code is under an open source
This case would look similar to the Firefox package and I'm interested
in understanding how this is handled in Fedora.
P.S: I'm already a Fedora packager.