Re: F21 Grub Issues
Hi,
I don't know, if my comment is useful for You. I always have an running Windows
system, XP, 8.1. To get both system with F21 in a bootlist, in my case F12
while running through bios, I have to whitelist my current F21. In my case I
think this is hardware dependency.
Kind Regards
-Ursprüngliche Mitteilung-
Von: Bidski bid...@iinet.net.au
An: test test@lists.fedoraproject.org
Verschickt: Mi, 19 Nov 2014 6:19 am
Betreff: F21 Grub Issues
Hi all,
I am having an issue getting F21 to dual boot with Windows 7 on an EFI system.
The first thing I did was to install Windows 7. This worked fine and had no
issues.
Then I installed F21 from a LiveUSB. After some hickups, which have now been
resolved, F21 works fine.
The problem I have now is that grub can not find my Windows 7 installation. I
noticed that there were no boot files for Microsoft in /boot/efi/EFI. So I
reinstalled Windows to restore the boot files and now I am back in the Live USB
trying to restore grub.
So I opened up the LVM partition that contains root, /home and swap. I mounted
everything then chroot. I also notice that in /boot/efi/EFI there are two
folders 'fedora' and 'Microsoft'. I then followed the usual default of
grub2-install /dev/sda
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
However, Windows 7 is still not detected. I found this post which says to put a
manual boot entry into /etc/grub.d/40_custom, so I added this to that file
menuentry 'Windows 7' {
insmod part_gpt
insmod chain
insmod ntfs
insmod fat
set root='hd0, gpt3'
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
boot
}
However now when I reboot I get dropped into the grub console. I know (pretty
sure) it is not the manual Windows entry as I can manually type the above
commands at the grub console and boot into Windows. Also, if I comment that
manual entry out I still wind up back in the grub console.
What is happening here? How can I generate some more diagnostic information
relating to why grub is failing?
Just to reiterate
My HDD has a GPT partition
Root, home, and swap partitions are in an LVM partition
Below is the partition structure for my HDD (this is hd0 according to grub).
/dev/sda1 Microsoft Reserved
/dev/sda2 Microsoft basic data
/dev/sda3 EFI System(/boot/efi)
/dev/sda4 /boot
/dev/sda5 LVM (root, /home, swap)
Bidski
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
rawhide report: 20141119 changes
Compose started at Wed Nov 19 05:15:02 UTC 2014 Broken deps for i386 -- [3Depict] 3Depict-0.0.16-3.fc22.i686 requires libmgl.so.7.2.0 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [audtty] audtty-0.1.12-9.fc20.i686 requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.i686 requires libjson.so.0 [cab] cab-0.1.9-12.fc22.i686 requires cabal-dev [condor] condor-plumage-8.1.4-7.a1a7df5.fc22.i686 requires libmongoclient.so [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [dnssec-check] dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc22.i686 requires libedelib.so edelib-devel-2.1-5.fc22.i686 requires libedelib.so [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc22.i686 requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc22.i686 requires libtorrent-rasterbar.so.7 [gdesklet-SlideShow] gdesklet-SlideShow-0.9-16.fc21.noarch requires gdesklets [gdesklets-citation] gdesklets-citation-2.0-3.20120702git355e2ee.fc19.noarch requires gdesklets [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.i686 requires libvala-0.24.so.0 [glances] glances-2.1.2-2.fc22.noarch requires python-psutil = 0:2.0.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) = 0:0.16.0 [iwhd] iwhd-1.6-11.fc22.i686 requires libmongoclient.so [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.i686 requires libopenobex.so.1 [ltsp] ltsp-client-5.4.5-8.fc21.i686 requires fuse-unionfs ltsp-server-5.4.5-8.fc21.i686 requires cdialog [monodevelop-vala] monodevelop-vala-2.8.8.1-6.fc21.i686 requires vala 0:0.25.0 [netdisco] netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay) [nwchem] nwchem-openmpi-6.3.2-11.fc21.i686 requires libmpi_usempi.so.1 [openslides] openslides-1.3.1-3.fc21.noarch requires python-django 0:1.5 [openvas-client] openvas-client-3.0.3-8.fc20.i686 requires libopenvas_omp.so.6 openvas-client-3.0.3-8.fc20.i686 requires libopenvas_nasl.so.6 openvas-client-3.0.3-8.fc20.i686 requires libopenvas_misc.so.6 openvas-client-3.0.3-8.fc20.i686 requires libopenvas_hg.so.6 openvas-client-3.0.3-8.fc20.i686 requires libopenvas_base.so.6 [perl-MooseX-Declare] perl-MooseX-Declare-0.40-1.fc22.noarch requires perl(MooseX::Declare::Syntax::MethodDeclaration::Parameterized) perl-MooseX-Declare-0.40-1.fc22.noarch requires perl(MooseX::Declare::StackItem) perl-MooseX-Declare-0.40-1.fc22.noarch requires perl(MooseX::Declare::Context::WithOptions) [pootle] pootle-2.1.6-8.fc21.noarch requires python-django14 [python-askbot-fedmsg] python-askbot-fedmsg-0.1.0-2.fc21.noarch requires askbot [python-coffin] python-coffin-0.3.7-3.fc21.noarch requires python-django14 [python-django-addons] python-django-addons-0.6.6-2.fc21.noarch requires python-django14 [python-django-longerusername] python-django-longerusername-0.4-5.20130204gite4e85d7d.fc21.noarch requires python-django14 [python-selenium] python3-selenium-2.43.0-1.fc22.noarch requires python3-rdflib [rubygem-qpid_proton] rubygem-qpid_proton-0.7-5.fc22.i686 requires qpid-proton-c = 0:0.7 [rubygem-rubigen] rubygem-rubigen-1.5.8-3.fc21.noarch requires rubygem(activesupport) 0:3.2.0 [shogun] shogun-doc-3.2.0.1-0.27.git20140804.96f3cf3.fc22.noarch requires shogun-data = 0:0.8.1-0.18.git20140804.48a1abb.fc22 [sugar-tamtam] sugar-tamtam-common-0-0.14.20100201git.fc22.i686 requires libcsound.so.5.2 [transifex] transifex-1.2.1-12.fc21.noarch requires python-django14 [uwsgi] uwsgi-plugin-gridfs-2.0.7-2.fc22.i686 requires libmongoclient.so uwsgi-stats-pusher-mongodb-2.0.7-2.fc22.i686 requires libmongoclient.so [valabind] valabind-0.7.4-4.fc21.i686 requires libvala-0.24.so.0 [vfrnav] vfrnav-20140510-2.fc22.i686 requires libpolyclipping.so.16 vfrnav-utils-20140510-2.fc22.i686 requires libpolyclipping.so.16 [zyGrib] zyGrib-6.1.4-3.fc20.i686 requires libnova-0.13.so.0 Broken deps for x86_64 -- [3Depict] 3Depict-0.0.16-3.fc22.x86_64 requires libmgl.so.7.2.0()(64bit) [Sprog]
F-21 Branched report: 20141119 changes
Compose started at Wed Nov 19 07:15:02 UTC 2014 Broken deps for armhfp -- [audtty] audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0 [avro] avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc21.armv7hl requires libedelib.so edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7 [gdesklet-SlideShow] gdesklet-SlideShow-0.9-16.fc21.noarch requires gdesklets [gdesklets-citation] gdesklets-citation-2.0-3.20120702git355e2ee.fc19.noarch requires gdesklets [gearbox] gearbox-10.11-8.fc21.armv7hl requires libIceUtil.so.35 gearbox-10.11-8.fc21.armv7hl requires ice gearbox-devel-10.11-8.fc21.armv7hl requires ice-devel [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires libvala-0.24.so.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) = 0:0.16.0 [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.armv7hl requires libopenobex.so.1 [ltsp] ltsp-client-5.4.5-8.fc21.armv7hl requires fuse-unionfs ltsp-server-5.4.5-8.fc21.armv7hl requires cdialog [monodevelop-vala] monodevelop-vala-2.8.8.1-6.fc21.armv7hl requires vala 0:0.25.0 [netdisco] netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay) [ocaml-pa-do] ocaml-pa-do-0.8.16-3.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [openslides] openslides-1.3.1-3.fc21.noarch requires python-django 0:1.5 [openstack-nova] openstack-nova-compute-2014.1.2-1.fc21.noarch requires libvirt-daemon-xen [openvas-client] openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_omp.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_nasl.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_misc.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_hg.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_base.so.6 [ostree] ostree-grub2-2014.11-1.fc21.armv7hl requires grub2 [pootle] pootle-2.1.6-8.fc21.noarch requires python-django14 [python-askbot-fedmsg] python-askbot-fedmsg-0.1.0-2.fc21.noarch requires askbot [python-coffin] python-coffin-0.3.7-3.fc21.noarch requires python-django14 [python-django-addons] python-django-addons-0.6.6-2.fc21.noarch requires python-django14 [python-django-longerusername] python-django-longerusername-0.4-5.20130204gite4e85d7d.fc21.noarch requires python-django14 [rubygem-rubigen] rubygem-rubigen-1.5.8-3.fc21.noarch requires rubygem(activesupport) 0:3.2.0 [spring-maps-default] spring-maps-default-0.1-12.fc21.noarch requires spring [syntastic] syntastic-d-3.5.0-1.fc21.noarch requires ldc [transifex] transifex-1.2.1-12.fc21.noarch requires python-django14 [valabind] valabind-0.7.4-4.fc21.armv7hl requires libvala-0.24.so.0 [zyGrib] zyGrib-6.1.4-3.fc20.armv7hl requires libnova-0.13.so.0 Broken deps for i386 -- [audtty] audtty-0.1.12-9.fc20.i686 requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.i686 requires libjson.so.0 [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc21.i686 requires libedelib.so edelib-devel-2.1-5.fc21.i686 requires libedelib.so [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc21.i686 requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc21.i686 requires libtorrent-rasterbar.so.7 [gdesklet-SlideShow] gdesklet-SlideShow-0.9-16.fc21.noarch requires gdesklets [gdesklets-citation] gdesklets-citation-2.0-3.20120702git355e2ee.fc19.noarch requires gdesklets [gearbox]
tracker
Well, I am sure it is not a show stopper but tracker is going to be a royal PITA for some users. In Fedora 20 we have tracker-0.16.5-1.fc20.x86_64 and in Fedora 21 it is tracker-1.2.4-3.fc21.x86_64. That difference in version/release means that the tracker developer has been very busy adding to the different files now handled by tracker. Unfortunately, either the implmenetation is bad or a lot of files are incorrect or both. After doing a fresh install of F21-TC2 workstation, I noticed a log of crap being dumped into the log (journal). This was a fresh install of Fedora 21 but keeping all my data including the existing home directories. The problem is reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1148570 and here: https://bugzilla.gnome.org/show_bug.cgi?id=735406 Since there was some mention of the F21 tracker using old data, I re-installed but with a new set of home directories. I then moved the old data a bit at a time. I used tracker-preferences to ignore a lot of files and that reduced the number of error/warning messages in the log. It may be possible to simply delete ~/.cache/tracker/* files rather than recreating the home directories. I will be testing to see if that works. At the very least, I believe that the following should be done: 1. Add something to the release notes warning of the situation. 2. If tracker is installed, then tracker-preferences should be installed too. The easiest way to do this is to add a requires in the tracker rpm for tracker-preferences. 3. Put a little pressure on upstream to address this problem with tracker. Does tracker really need to put these error/warning messages in the logs? In the end, I had to add the following Glob patterns to ignore: * *.au,*.azw, *.mobi, *.mov, *.MOV, *.mp3, *.MP3, *.mpg, *.tif, *.wavand *.xcf* Comments? Gene -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: tracker
On Wed, 2014-11-19 at 07:37 -0500, Gene Czarcinski wrote: Well, I am sure it is not a show stopper but tracker is going to be a royal PITA for some users. In Fedora 20 we have tracker-0.16.5-1.fc20.x86_64 and in Fedora 21 it is tracker-1.2.4-3.fc21.x86_64. That difference in version/release means that the tracker developer has been very busy adding to the different files now handled by tracker. Well, they actually jumped to 1.0 after 0.17: https://github.com/GNOME/tracker/releases Still quite a few releases, though, yes. Unfortunately, either the implmenetation is bad or a lot of files are incorrect or both. After doing a fresh install of F21-TC2 workstation, I noticed a log of crap being dumped into the log (journal). This was a fresh install of Fedora 21 but keeping all my data including the existing home directories. The problem is reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1148570 and here: https://bugzilla.gnome.org/show_bug.cgi?id=735406 Since there was some mention of the F21 tracker using old data, I re-installed but with a new set of home directories. I then moved the old data a bit at a time. I used tracker-preferences to ignore a lot of files and that reduced the number of error/warning messages in the log. It may be possible to simply delete ~/.cache/tracker/* files rather than recreating the home directories. I will be testing to see if that works. At the very least, I believe that the following should be done: 1. Add something to the release notes warning of the situation. 2. If tracker is installed, then tracker-preferences should be installed too. The easiest way to do this is to add a requires in the tracker rpm for tracker-preferences. 3. Put a little pressure on upstream to address this problem with tracker. Does tracker really need to put these error/warning messages in the logs? In the end, I had to add the following Glob patterns to ignore: *.au, *.azw, *.mobi, *.mov, *.MOV, *.mp3, *.MP3, *.mpg, *.tif, *.wav and *.xcf Comments? I'm using tracker on two of my systems and for most of the part, it works OK. I had do add *.cpp *.c to the globs to exclude, but this is more because I didn't want to see them in the search results, not because they were hurting tracker. We could have something added in the release notes about advanced tracker configuration - that would certainly help. I don't know if the default install will include tracker-prefs, the search settings is sort of enough for normal end users. Gnome is moving towards tracker quite a bit - photos/music/documents all use tracker so any issue should be filed upstream and fixed. I don't know how we could pressure upstream as you put it, but I do file all the bugs that I run into. -- Thanks, Regards, Ankur Sinha FranciscoD http://fedoraproject.org/wiki/User:Ankursinha signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
dracut-initqueue error
I just rebooted and the boot process stopped on this dracut error on the
newest kernel, 3.17-3-300:
dracut-initqueue[271]: Warning: Cancelling resume operation. Device not
found
I was able to boot into the older 3.17-2-300 kernel
uname -a
Linux localhost.localdomain 3.17.2-300.fc21.x86_64 #1 SMP Thu Oct 30
19:23:48 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
yum install dracut
Loaded plugins: langpacks
Package dracut-038-30.git20140903.fc21.x86_64 already installed and
latest version
Nothing to do
grep 3.17.3-300 /boot/grub2/grub.cfg
menuentry 'Fedora, with Linux 3.17.3-300.fc21.x86_64' --class fedora
--class gnu-linux --class gnu --class os --unrestricted
$menuentry_id_option
'gnulinux-3.17.3-300.fc21.x86_64-advanced-a1f0e69f-f7b4-41b3-8a88-adbc6d59d957'
{
linux16 /boot/vmlinuz-3.17.3-300.fc21.x86_64
root=UUID=a1f0e69f-f7b4-41b3-8a88-adbc6d59d957 ro rhgb quiet
initrd16 /boot/initramfs-3.17.3-300.fc21.x86_64.img
menuentry 'Fedora, with Linux 3.17.3-300.fc21.x86_64 (recovery mode)'
--class fedora --class gnu-linux --class gnu --class os --unrestricted
$menuentry_id_option
'gnulinux-3.17.3-300.fc21.x86_64-recovery-a1f0e69f-f7b4-41b3-8a88-adbc6d59d957'
{
linux16 /boot/vmlinuz-3.17.3-300.fc21.x86_64
root=UUID=a1f0e69f-f7b4-41b3-8a88-adbc6d59d957 ro single rhgb quiet
initrd16 /boot/initramfs-3.17.3-300.fc21.x86_64.img
--
Paul Cartwright
Registered Linux User #367800 and new counter #561587
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Mongodb-server fails to start with selinux enforcing
On a clean installation built from Fedora-Live-Workstation-x86_64-21_Beta-4.iso, I installed mongodb-server but it failed to start due to selinux: SELinux is preventing mongod from name_bind access on the tcp_socket port 27017. Following the selinux instructions from the journal resolves this: # grep mongod /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Should I bugzilla this, and if so, is it against mongodb or selinux-policy? NOTICE DISCLAIMER This email including attachments (this Document) is confidential and may contain legally privileged information. If you have received this Document in error please notify the sender immediately and delete this Document from your system without using, copying, disclosing or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of this Document. The information contained in this Document is provided solely for information purposes on an as is basis without warranty of any kind, either express or implied, including without limitation any implied warranty of satisfactory or merchantable quality, fitness for a particular purpose or freedom from error or infringement. The user relies on the information contained herein, and its accuracy or otherwise, entirely at their own risk. Any opinions expressed in this Document are those of the author and do not necessarily reflect the opinions of Telsis. We will not accept responsibility for any commitments made by our employees, agents or representatives outside the scope of our business. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F21-beta issues with NetworkManager and tunX
Hello all, Did a fresh install of Fedora 21 beta via boot.iso (essentially, so not a Workstation flavour). Transferred my F20 configuration over, to the best of my ability, this involved: - removing /etc/sysconfig/network-scripts/ifcfg-* and moving my networking to be controlled by NetworkManager - NetworkManager.conf: [main] plugins=keyfile no-auto-default=* ignore-carrier=* - setup my (static) wired ethernet using nmcli and place it in the home zone (connectivity works!) - the default firewall zone is public However this is where I get issues. I create openvpn tunnels manually. In Fedora 20 this meant: - a routing entry was added specifing how to route directly to the remote endpoint (to avoid a circularity where the yet to be established tunnel attempts to send it's packets over itself) - a tunX device was created - a 0/1 and 128/1 route was added to go over said tunnel as not to disturb the default route In Fedora 21 weird stuff happens. It seems that NetworkManager tries to managed the newly created tunX device, and my created routes change from under me. I mitigated this by adding a [keyfile] entry in my NetworkManger.conf to set tunX devices for small X to be unmanaged. I have no problem with this, per se, as this is not particuarly out-of-the-box setup. However, perhaps the parties involved with F21 networking can inform me as what higher level configuration I can perform to get this working more elegantly. Thank you. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Fedora 19 updates-testing report
The following Fedora 19 Security updates need testing: Age URL 389 https://admin.fedoraproject.org/updates/FEDORA-2013-19963/openstack-glance-2013.1.4-1.fc19 201 https://admin.fedoraproject.org/updates/FEDORA-2014-5896/nrpe-2.15-2.fc19 152 https://admin.fedoraproject.org/updates/FEDORA-2014-7496/readline-6.2-8.fc19 69 https://admin.fedoraproject.org/updates/FEDORA-2014-10640/libreoffice-4.1.6.2-8.fc19 54 https://admin.fedoraproject.org/updates/FEDORA-2014-11544/drupal6-6.33-1.fc19 47 https://admin.fedoraproject.org/updates/FEDORA-2014-12057/krb5-1.11.3-29.fc19 33 https://admin.fedoraproject.org/updates/FEDORA-2014-13047/libxml2-2.9.1-2.fc19 33 https://admin.fedoraproject.org/updates/FEDORA-2014-13018/deluge-1.3.10-1.fc19 23 https://admin.fedoraproject.org/updates/FEDORA-2014-13551/wpa_supplicant-2.0-12.fc19 18 https://admin.fedoraproject.org/updates/FEDORA-2014-14066/php-sabredav-Sabre_VObject-2.1.4-1.fc19,php-sabredav-Sabre_HTTP-1.7.11-1.fc19,php-sabredav-Sabre_CalDAV-1.7.9-1.fc19,php-sabredav-Sabre_DAVACL-1.7.9-1.fc19,php-sabredav-Sabre_CardDAV-1.7.9-2.fc19,php-sabredav-Sabre_DAV-1.7.13-1.fc19,owncloud-5.0.17-2.fc19 14 https://admin.fedoraproject.org/updates/FEDORA-2014-14266/python-2.7.5-15.fc19 14 https://admin.fedoraproject.org/updates/FEDORA-2014-14237/claws-mail-plugins-3.11.1-1.fc19,claws-mail-3.11.1-2.fc19,libetpan-1.6-1.fc19 12 https://admin.fedoraproject.org/updates/FEDORA-2014-14359/curl-7.29.0-25.fc19 7 https://admin.fedoraproject.org/updates/FEDORA-2014-14738/gnutls-3.1.20-6.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2014-12407/sddm-0.10.0-2.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2014-14912/polarssl-1.2.12-1.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2014-14980/python-pillow-2.0.0-16.gitd1c6db8.fc19 4 https://admin.fedoraproject.org/updates/FEDORA-2014-15079/mantis-1.2.17-4.fc19 4 https://admin.fedoraproject.org/updates/FEDORA-2014-14874/arm-none-eabi-binutils-cs-2014.05.28-3.fc19 4 https://admin.fedoraproject.org/updates/FEDORA-2014-14838/avr-binutils-2.24-3.fc19 4 https://admin.fedoraproject.org/updates/FEDORA-2014-15124/kwebkitpart-1.3.4-5.fc19 3 https://admin.fedoraproject.org/updates/FEDORA-2014-15202/kernel-3.14.24-100.fc19 1 https://admin.fedoraproject.org/updates/FEDORA-2014-15248/kde-runtime-4.11.5-3.fc19 1 https://admin.fedoraproject.org/updates/FEDORA-2014-15307/python-django14-1.4.16-1.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15373/lsyncd-2.1.4-4.fc19.1 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15378/rubygem-actionpack-3.2.13-7.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15390/nodejs-0.10.33-1.fc19,libuv-0.10.29-1.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15405/wget-1.16-3.fc19 The following Fedora 19 Critical Path updates have yet to be approved: Age URL 337 https://admin.fedoraproject.org/updates/FEDORA-2013-22326/fedora-bookmarks-15-5.fc19 263 https://admin.fedoraproject.org/updates/FEDORA-2014-3245/testdisk-6.14-2.fc19.1,ntfs-3g-2014.2.15-1.fc19 12 https://admin.fedoraproject.org/updates/FEDORA-2014-14359/curl-7.29.0-25.fc19 10 https://admin.fedoraproject.org/updates/FEDORA-2014-14516/pcre-8.32-11.fc19 10 https://admin.fedoraproject.org/updates/FEDORA-2014-14505/unzip-6.0-12.fc19 7 https://admin.fedoraproject.org/updates/FEDORA-2014-14738/gnutls-3.1.20-6.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2014-15032/man-db-2.6.3-9.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2014-15027/evolution-data-server-3.8.5-7.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2014-14807/device-mapper-persistent-data-0.4.1-2.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2014-14846/pciutils-3.3.0-1.fc19 3 https://admin.fedoraproject.org/updates/FEDORA-2014-15202/kernel-3.14.24-100.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15392/kde-workspace-4.11.14-2.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15377/gvfs-1.16.4-3.fc19 The following builds have been pushed to Fedora 19 updates-testing berusky-1.7.1-1.fc19 berusky-data-1.7-3.fc19 dmlite-0.7.2-1.fc19 git-review-1.24-2.fc19 gvfs-1.16.4-3.fc19 kde-workspace-4.11.14-2.fc19 libuv-0.10.29-1.fc19 lsyncd-2.1.4-4.fc19.1 nodejs-0.10.33-1.fc19 nomacs-2.2.0-2.fc19 python-bugzilla2fedmsg-0.2.1-1.fc19 quiterss-0.17.1-1.fc19 rubygem-actionpack-3.2.13-7.fc19 voms-2.0.12-1.fc19 wget-1.16-3.fc19 Details about builds: berusky-1.7.1-1.fc19 (FEDORA-2014-15128) Sokoban clone Update Information: Updated app file, fixed start-up crash.
Fedora 20 updates-testing report
The following Fedora 20 Security updates need testing: Age URL 55 https://admin.fedoraproject.org/updates/FEDORA-2014-11430/ca-certificates-2014.2.1-1.1.fc20 47 https://admin.fedoraproject.org/updates/FEDORA-2014-11969/krb5-1.11.5-16.fc20 38 https://admin.fedoraproject.org/updates/FEDORA-2014-12699/facter-1.7.6-1.fc20 5 https://admin.fedoraproject.org/updates/FEDORA-2014-14791/mariadb-galera-5.5.40-2.fc20 5 https://admin.fedoraproject.org/updates/FEDORA-2014-14898/polarssl-1.2.12-1.fc20 5 https://admin.fedoraproject.org/updates/FEDORA-2014-14883/python-pillow-2.2.1-7.fc20 4 https://admin.fedoraproject.org/updates/FEDORA-2014-15108/mantis-1.2.17-4.fc20 4 https://admin.fedoraproject.org/updates/FEDORA-2014-14963/avr-binutils-2.24-3.fc20 4 https://admin.fedoraproject.org/updates/FEDORA-2014-15102/moodle-2.5.9-1.fc20 4 https://admin.fedoraproject.org/updates/FEDORA-2014-14833/arm-none-eabi-binutils-cs-2014.05.28-3.fc20 4 https://admin.fedoraproject.org/updates/FEDORA-2014-15130/kwebkitpart-1.3.4-5.fc20 3 https://admin.fedoraproject.org/updates/FEDORA-2014-15200/kernel-3.17.3-200.fc20 2 https://admin.fedoraproject.org/updates/FEDORA-2014-15228/libvirt-1.1.3.8-1.fc20 1 https://admin.fedoraproject.org/updates/FEDORA-2014-15244/wireshark-1.10.11-1.fc20 1 https://admin.fedoraproject.org/updates/FEDORA-2014-15266/python-django14-1.4.16-1.fc20 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15371/rubygem-actionpack-4.0.0-5.fc20 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15393/lsyncd-2.1.4-4.fc20.1 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15379/nodejs-0.10.33-1.fc20,libuv-0.10.29-1.fc20 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15385/wget-1.16-3.fc20 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15394/erlang-R16B-03.9.fc20 The following Fedora 20 Critical Path updates have yet to be approved: Age URL 12 https://admin.fedoraproject.org/updates/FEDORA-2014-14389/colord-1.1.8-1.fc20 7 https://admin.fedoraproject.org/updates/FEDORA-2014-14728/xkeyboard-config-2.10.1-3.fc20 5 https://admin.fedoraproject.org/updates/FEDORA-2014-15054/perl-Pod-Usage-1.64-2.fc20,perl-Pod-Checker-1.60-292.fc20 5 https://admin.fedoraproject.org/updates/FEDORA-2014-14798/device-mapper-persistent-data-0.4.1-2.fc20 5 https://admin.fedoraproject.org/updates/FEDORA-2014-14964/libtdb-1.3.1-1.fc20 5 https://admin.fedoraproject.org/updates/FEDORA-2014-14861/libpipeline-1.2.4-3.fc20 4 https://admin.fedoraproject.org/updates/FEDORA-2014-15120/dosfstools-3.0.27-1.fc20 1 https://admin.fedoraproject.org/updates/FEDORA-2014-15326/pycairo-1.10.0-1.fc20 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15384/xorg-x11-drv-intel-2.21.15-9.fc20 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15376/yum-utils-1.1.31-27.fc20 0 https://admin.fedoraproject.org/updates/FEDORA-2014-15395/gvfs-1.18.4-1.fc20 The following builds have been pushed to Fedora 20 updates-testing abduco-0.2-1.fc20 berusky-1.7.1-1.fc20 berusky-data-1.7-3.fc20 certmonger-0.76.8-1.fc20 dmlite-0.7.2-1.fc20 erlang-R16B-03.9.fc20 golang-github-docker-libcontainer-1.2.0-3.git28cb5f9.fc20 greybird-1.4-3.fc20 gvfs-1.18.4-1.fc20 htmlparser-1.5-2.fc20 kde-workspace-4.11.14-2.fc20 libuv-0.10.29-1.fc20 lsyncd-2.1.4-4.fc20.1 mock-1.2.2-1.fc20 nifti2dicom-0.4.9-1.fc20 nodejs-0.10.33-1.fc20 nomacs-2.2.0-2.fc20 perl-Fsdb-2.52-2.fc20 php-horde-Horde-Browser-2.0.8-1.fc20 php-horde-Horde-Crypt-2.5.1-1.fc20 php-horde-Horde-Db-2.2.2-1.fc20 php-horde-Horde-History-2.3.3-1.fc20 php-horde-Horde-Mime-Viewer-2.0.8-1.fc20 php-horde-Horde-Test-2.4.6-1.fc20 pidgin-2.10.10-2.fc20 pki-core-10.1.2-4.fc20 python-bugzilla2fedmsg-0.2.1-1.fc20 python-flask-openid-1.2.4-1.fc20 quiterss-0.17.1-1.fc20 rubygem-actionpack-4.0.0-5.fc20 voms-2.0.12-1.fc20 voms-api-java-3.0.4-1.fc20 wget-1.16-3.fc20 xfdesktop-4.10.3-2.fc20 xorg-x11-drv-intel-2.21.15-9.fc20 yum-utils-1.1.31-27.fc20 Details about builds: abduco-0.2-1.fc20 (FEDORA-2014-15374) Session management in a clean and simple way Update Information: update to 0.2 (RHBZ #1165180) ChangeLog: * Tue Nov 18 2014 Igor Gnatenko i.gnatenko.br...@gmail.com - 0.2-1 - update to 0.2 (RHBZ #1165180) * Fri Aug 15 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.1-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild References: [ 1 ] Bug #1165180 - abduco-0.2 is available
Re: Mongodb-server fails to start with selinux enforcing
On 11/19/2014 09:16 AM, Paul Knox-Kennedy wrote: On a clean installation built from Fedora-Live-Workstation-x86_64-21_Beta-4.iso, I installed mongodb-server but it failed to start due to selinux: SELinux is preventing mongod from name_bind access on the tcp_socket port 27017. Following the selinux instructions from the journal resolves this: # grep mongod /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Should I bugzilla this, and if so, is it against mongodb or selinux-policy? Is this a standard port the mongodb should be listening on? The better solution would have been to label the port as a mysql_port_t. semanage port -a -t mysql_port_t -t tcp 27017 NOTICE DISCLAIMER This email including attachments (this Document) is confidential and may contain legally privileged information. If you have received this Document in error please notify the sender immediately and delete this Document from your system without using, copying, disclosing or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of this Document. The information contained in this Document is provided solely for information purposes on an as is basis without warranty of any kind, either express or implied, including without limitation any implied warranty of satisfactory or merchantable quality, fitness for a particular purpose or freedom from error or infringement. The user relies on the information contained herein, and its accuracy or otherwise, entirely at their own risk. Any opinions expressed in this Document are those of the author and do not necessarily reflect the opinions of Telsis. We will not accept responsibility for any commitments made by our employees, agents or representatives outside the scope of our business. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Mongodb-server fails to start with selinux enforcing
On Wed, Nov 19, 2014 at 6:19 PM, Daniel J Walsh dwa...@redhat.com wrote: On 11/19/2014 09:16 AM, Paul Knox-Kennedy wrote: On a clean installation built from Fedora-Live-Workstation-x86_64-21_Beta-4.iso, I installed mongodb-server but it failed to start due to selinux: SELinux is preventing mongod from name_bind access on the tcp_socket port 27017. Following the selinux instructions from the journal resolves this: # grep mongod /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Should I bugzilla this, and if so, is it against mongodb or selinux-policy? Is this a standard port the mongodb should be listening on? http://docs.mongodb.org/manual/reference/default-mongodb-port/ Seems like the answer is yes. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
2014-11-19 @ 1600 UTC ** Blocker Review Minutes
== #fedora-blocker-review: F21-blocker-review == Meeting started by pschindl at 16:03:55 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-blocker-review/2014-11-19/f21-blocker-review.2014-11-19-16.03.log.html . Meeting summary --- * Roll Call (pschindl, 16:04:10) * Introduction (pschindl, 16:08:01) * Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs. (pschindl, 16:08:06) * We'll be following the process outlined at: (pschindl, 16:08:08) * LINK: https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting (pschindl, 16:08:10) * The bugs up for review today are available at: (pschindl, 16:08:12) * LINK: http://qa.fedoraproject.org/blockerbugs/current (pschindl, 16:08:14) * The criteria for release blocking bugs can be found at: (pschindl, 16:08:16) * LINK: https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria (pschindl, 16:08:18) * LINK: https://fedoraproject.org/wiki/Fedora_21_Beta_Release_Criteria (pschindl, 16:08:20) * LINK: https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria (pschindl, 16:08:22) * 9 Proposed Blockers (pschindl, 16:08:28) * 6 Accepted Blockers (pschindl, 16:08:31) * 11 Proposed Freeze Exceptions (pschindl, 16:08:33) * 3 Accepted Freeze Exceptions (pschindl, 16:08:35) * (1162856) Missing high contrast icon (pschindl, 16:09:30) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1162856 (pschindl, 16:09:32) * Proposed Blocker, fedora-logos, NEW (pschindl, 16:09:34) * AGREED: - 1162856 - AcceptedBlocker - This bug is a clear violation of the Final criterion: All applications installed by default in Fedora Workstation must comply with each MUST and MUST NOT guideline in the Applications and Launchers policy. (pschindl, 16:16:14) * (1165430) Fedora-repos needs updating for f21 final (pschindl, 16:16:38) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1165430 (pschindl, 16:16:40) * Proposed Blocker, fedora-repos, ON_QA (pschindl, 16:16:42) * AGREED: - 1165430 - AcceptedBlocker - This bug violates the final criterion: A fedora-release package containing the correct names, information and repository configuration for a final Fedora release must be present on release-blocking images and the appropriately versioned generic-release package must be available in the release repository. (pschindl, 16:20:19) * (1165261) ipa-server-install fails when restarting named (pschindl, 16:20:33) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1165261 (pschindl, 16:20:35) * Proposed Blocker, freeipa, POST (pschindl, 16:20:37) * AGREED: - 1165261 - AcceptedBlocker - This bug violates the beta roles criteria: Release-blocking roles and the supported role configuration interfaces must meet the core functional Role Definition Requirements to the extent that supported roles can be successfully started, stopped, brought to a working configuration, and queried. (pschindl, 16:35:16) * (1164492) Please drop libvirt 'default' network dependency for F21 GA (pschindl, 16:35:27) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1164492 (pschindl, 16:35:30) * Proposed Blocker, gnome-boxes, NEW (pschindl, 16:35:32) * AGREED: - 1164492 - RejectedBlocker - This bug tryes to solve the same issue as bug 1146232 which is already blocker. (pschindl, 16:48:46) * (1165425) bcl accidentally pushed a diagnostic 'bcl was here' test for
Re: Mongodb-server fails to start with selinux enforcing
On 11/19/2014 12:38 PM, drago01 wrote: On Wed, Nov 19, 2014 at 6:19 PM, Daniel J Walsh dwa...@redhat.com wrote: On 11/19/2014 09:16 AM, Paul Knox-Kennedy wrote: On a clean installation built from Fedora-Live-Workstation-x86_64-21_Beta-4.iso, I installed mongodb-server but it failed to start due to selinux: SELinux is preventing mongod from name_bind access on the tcp_socket port 27017. Following the selinux instructions from the journal resolves this: # grep mongod /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Should I bugzilla this, and if so, is it against mongodb or selinux-policy? Is this a standard port the mongodb should be listening on? http://docs.mongodb.org/manual/reference/default-mongodb-port/ Seems like the answer is yes. Well I guess this is why you shouldn't fly blind. Could you actually show me the actual AVC message. It should be in the bottom of the alert. Looks like it already is labeled mongod_port_t. sepolicy network -p 27017 27017: tcp unreserved_port_t 1024-32767 27017: udp unreserved_port_t 1024-32767 27017: tcp mongod_port_t 27017-27019 Looks like I fixed a bug in git back in october Author: Dan Walsh dwa...@redhat.com Date: Mon Oct 27 19:18:21 2014 -0400 Allow mongodb to bind to the mongo port and mongos to run as mongod_t Looks like this has made it into F21 policy and Rawhide, but not in F20. /selinux-policy-3.13.1-98.fc21 Lukas could you back port this into RHEL7 and F20 policy. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F21 Grub Issues
Hi all, I am having an issue getting F21 to dual boot with Windows 7 on an EFI system. The first thing I did was to install Windows 7. This worked fine and had no issues. Then I installed F21 from a LiveUSB. After some hickups, which have now been resolved, F21 works fine. The problem I have now is that grub can not find my Windows 7 installation I noticed that there were no boot files for Microsoft in /boot/efi/EFI. You're saying after installing Fedora 21 after Windows 7, that there was no Microsoft directory in /boot/efi/EFI? Just a fedora directory? This is correct, there may have also been a /boot/efi/EFI/BOOT folder as well (not sure what this is or where it came from). So I opened up the LVM partition that contains root, /home and swap. I mounted everything then chroot. I also notice that in /boot/efi/EFI there are two folders 'fedora' and 'Microsoft'. I then followed the usual default of grub2-install /dev/sda grub2-install shouldn't be used on EFI systems. The grub2-efi package installs a prebaked grubx64.efi on the EFI System partition, which looks for grub.cfg on the ESP in /EFI/fedora/ whereas the grub2-install command creates a custom grubx64.efi, deletes the original installed one, and looks for grub.cfg in /boot/grub2/. I suggest 'dnf reinstall grub2-efi' and then deleting the grub.cfg from both locations and then creating a new one with 'grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg' and see if it has now found the Windows bootloader and correctly created an entry for it. grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg However, Windows 7 is still not detected. Sounds like this bug. If you can reproduce this after reinstalling grub (by reinstalling the package, not using grub2-install), and recreating the grubcfg, please post the grub.cfg and the results of output from 'os-prober' and confirm the existence of /boot/efi/EFI/microsoft/ https://bugzilla.redhat.com/show_bug.cgi?id=986731 From a LiveUSB, after mounting the system and changing the root. I just did find /boot/ -name grub*cfg The only result was /boot/efi/EFI/fedora/grub.cfg I deleted that, then yum reinstall grub2-efi* shim and grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg Grub still does not manage to find the Windows boot files. There are also a lot of warnings about lvmetad that get displayed (might not be lvmetad but it is LVM related). Upon rebooting, I no longer get dumped into the grub command line and the manual boot entry for Windows 7 that I mentioned previously seems to work (apart from throwing an error about not finding ntfs.mod). The Linux boot entry seems to be working fine. Once I was booted back into my system (in F21), I re-ran yum reinstall grub2-efi* shim grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg And grub was able to find the Windows 7 boot files via os-prober. So it seems that the issue is trying to do all of this from the LiveUSB? And maybe there is something happening with the installer deleting the Windows boot files in the EFI partition? Bidski -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F21 Grub Issues
On Wed, Nov 19, 2014 at 2:29 PM, Bidski bid...@iinet.net.au wrote: Hi all, I am having an issue getting F21 to dual boot with Windows 7 on an EFI system. The first thing I did was to install Windows 7. This worked fine and had no issues. Then I installed F21 from a LiveUSB. After some hickups, which have now been resolved, F21 works fine. The problem I have now is that grub can not find my Windows 7 installation. I noticed that there were no boot files for Microsoft in /boot/efi/EFI. You're saying after installing Fedora 21 after Windows 7, that there was no Microsoft directory in /boot/efi/EFI? Just a fedora directory? This is correct, there may have also been a /boot/efi/EFI/BOOT folder as well (not sure what this is or where it came from). ESP//EFI/BOOT/ is put there by the Fedora installer as a backup in case of NVRAM confusion. ESP//EFI/microsoft should be there after installing Windows, if it's not there, then it's not a UEFI installation of Windows, it's CSM-BIOS instead. If it's there after installing Windows and not there after installing Fedora, that's a new, major, blocking bug. So if you can reproduce that and file a bug it would be great. I haven't ever seen this behavior in dozens of installs. So it seems that the issue is trying to do all of this from the LiveUSB? No idea. Several people have done this on UEFI systems and gotten successful installs, including 2 recently in bug 986731. I'm not sure what to recommend other than something that's a big of a PITA, which would be to file a new bug. Document each step you're going through to install Windows 7, and Fedora. And attach the following files from the live environment: /mnt/sysimage/boot/efi/EFI/fedora/grub.cfg /tmp/program.log /tmp/storage.log The output from: # chroot /mnt/sysimage # bash -x grub2-mkconfig # os-prober The above is probably easiest done in a clean/reset Terminal window in the live environment, select all, copy, paste into a gedit document and save it, then include that as an attachment also. Also, if you can include the before Fedora 21 installation, and post-install output from the following command: # parted /dev/sda u s p That'd also be helpful, I'm assuming the drive in question is sda so replace that if needed. This will show the partition layout after Windows is freshly installed vs what anaconda does to it post Fedora. And makes it easier than trying to dig this out of the storage.log. And while you're at it make an explicit note that you checked the EFI System partition before and after installing Fedora 21, and whether /EFI/microsoft is present or not. Normally the ESP is partition 2 on Windows, if I recall correctly from a recent Windows 8.1 UEFI install. I would do this again myself but I've lost access to the test EFI computer capable of EFI booting Windows 8. And maybe there is something happening with the installer deleting the Windows boot files in the EFI partition? More likely is there's a 2nd EFI System partition being created under certain circumstances and one ESP has /EFI/microsoft and the other doesn't. Anaconda is not supposed to be creating two ESPs, but the UEFI spec doesn't prohibit it either. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F21 Grub Issues
Hi all, I am having an issue getting F21 to dual boot with Windows 7 on an EFI system. The first thing I did was to install Windows 7. This worked fine and had no issues. Then I installed F21 from a LiveUSB. After some hickups, which have now been resolved, F21 works fine. The problem I have now is that grub can not find my Windows 7 installation. I noticed that there were no boot files for Microsoft in /boot/efi/EFI. You're saying after installing Fedora 21 after Windows 7, that there was no Microsoft directory in /boot/efi/EFI? Just a fedora directory? This is correct, there may have also been a /boot/efi/EFI/BOOT folder as well (not sure what this is or where it came from). ESP//EFI/BOOT/ is put there by the Fedora installer as a backup in case of NVRAM confusion. ESP//EFI/microsoft should be there after installing Windows, if it's not there, then it's not a UEFI installation of Windows, it's CSM-BIOS instead. If it's there after installing Windows and not there after installing Fedora, that's a new, major, blocking bug. So if you can reproduce that and file a bug it would be great. I haven't ever seen this behavior in dozens of installs. So it seems that the issue is trying to do all of this from the LiveUSB? No idea. Several people have done this on UEFI systems and gotten successful installs, including 2 recently in bug 986731. I'm not sure what to recommend other than something that's a big of a PITA, which would be to file a new bug. Document each step you're going through to install Windows 7, and Fedora. And attach the following files from the live environment: /mnt/sysimage/boot/efi/EFI/fedora/grub.cfg /tmp/program.log /tmp/storage.log The output from: # chroot /mnt/sysimage # bash -x grub2-mkconfig # os-prober The above is probably easiest done in a clean/reset Terminal window in the live environment, select all, copy, paste into a gedit document and save it, then include that as an attachment also. Also, if you can include the before Fedora 21 installation, and post-install output from the following command: # parted /dev/sda u s p That'd also be helpful, I'm assuming the drive in question is sda so replace that if needed. This will show the partition layout after Windows is freshly installed vs what anaconda does to it post Fedora. And makes it easier than trying to dig this out of the storage.log. And while you're at it make an explicit note that you checked the EFI System partition before and after installing Fedora 21, and whether /EFI/microsoft is present or not. Normally the ESP is partition 2 on Windows, if I recall correctly from a recent Windows 8.1 UEFI install. I would do this again myself but I've lost access to the test EFI computer capable of EFI booting Windows 8. As much as I would love to see if the problems I am having are reproducible, I just got my system working and am kind of hesitant to rip it all apart again. Hopefully I just encountered a one-off set of circumstances and no one else will ever see these same issues again. Thank you for your help though. Bidski And maybe there is something happening with the installer deleting the Windows boot files in the EFI partition? More likely is there's a 2nd EFI System partition being created under certain circumstances and one ESP has /EFI/microsoft and the other doesn't. Anaconda is not supposed to be creating two ESPs, but the UEFI spec doesn't prohibit it either. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
[Test-Announce] Fedora Atomic Test Day
Greetings, all! Tomorrow (or today for those of you not in North America) will be the first Atomic Testday! The Fedora Atomic host is a new image designed to securely and easily run Docker containers - all based on Project Atomic [0]. Because it's new ground, testing is required for a successful release. The Atomic image utilizes rpm-ostree [1] to allow you to update and revert your installed package set just like a Git repo. This allows for easy upgrades and an easy method of reverting back to a known good state should something go wrong after an update. Come join us for a day of testing and exploration into all Atomic offers for running your containerized applications. Information on the testday can be found on the Wiki [2] or drop by the #fedora-test-day channel on Freenode if you have any questions. See you tomorrow (or later today)! [0] http://projectatomic.io [1] https://github.com/projectatomic/rpm-ostree [2] https://fedoraproject.org/wiki/Test_Day:2014-11-20_Atomic -- // Mike -- Fedora QA freenode: roshi http://roshi.fedorapeople.org ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
[Test-Announce] Fedora Atomic Test Day
Greetings, all! Tomorrow (or today for those of you not in North America) will be the first Atomic Testday! The Fedora Atomic host is a new image designed to securely and easily run Docker containers - all based on Project Atomic [0]. Because it's new ground, testing is required for a successful release. The Atomic image utilizes rpm-ostree [1] to allow you to update and revert your installed package set just like a Git repo. This allows for easy upgrades and an easy method of reverting back to a known good state should something go wrong after an update. Come join us for a day of testing and exploration into all Atomic offers for running your containerized applications. Information on the testday can be found on the Wiki [2] or drop by the #fedora-test-day channel on Freenode if you have any questions. See you tomorrow (or later today)! [0] http://projectatomic.io [1] https://github.com/projectatomic/rpm-ostree [2] https://fedoraproject.org/wiki/Test_Day:2014-11-20_Atomic -- // Mike -- Fedora QA freenode: roshi http://roshi.fedorapeople.org ___ test-announce mailing list test-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce
