triage October 2011

triage@lists.stg.fedoraproject.org

1 participants
14 discussions

[Bug 743020] New: rngd is missing initscript, attached
by Red Hat Bugzilla 12 Jan '12

12 Jan '12

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: rngd is missing initscript, attached https://bugzilla.redhat.com/show_bug.cgi?id=743020 Summary: rngd is missing initscript, attached Product: Fedora Version: 15 Platform: All OS/Version: Linux Status: NEW Status Whiteboard: bzcl34nup Severity: high Priority: unspecified Component: rng-tools AssignedTo: jgarzik(a)redhat.com ReportedBy: juan.oropeza(a)oracle.com QAContact: extras-qa(a)fedoraproject.org CC: cra(a)wpi.edu, mattdm(a)mattdm.org, jgarzik(a)redhat.com, ianburrell(a)gmail.com, pizza(a)shaftnet.org, paul(a)xelerance.com, triage(a)lists.fedoraproject.org, avagarwa(a)redhat.com, juan.oropeza(a)oracle.com Estimated Hours: 0.0 Classification: Fedora Story Points: --- Clone Of: 215371 Type: --- +++ This bug was initially created as a clone of Bug #215371 +++ rngd should always be started in platforms with hardware random support, but package provides no initscript to start the rngd. --- Additional comment from paul(a)xelerance.com on 2006-11-13 13:21:28 EST --- Created attachment 141082 rngd initscript --- Additional comment from paul(a)xelerance.com on 2007-01-25 21:49:16 EST --- Please try to get the init script for rngd into the package before FC7test1 feature freeze. I can't make it easier then I already did by supplying the init script. --- Additional comment from paul(a)xelerance.com on 2007-01-30 12:58:47 EST --- Still an issue for rng-utils-2.0-1.14.1.fc6 --- Additional comment from paul(a)xelerance.com on 2007-01-30 13:03:47 EST --- Created attachment 146934 Updated version of rngd.init supporting 2.6.19 style rng kernel modules Updated version of rngd.init supporting 2.6.19 style rng kernel modules --- Additional comment from paul(a)xelerance.com on 2007-01-30 13:12:16 EST --- Created attachment 146935 Fix to previous version for properly modprobing hwrng sorry about that. previous version is broken. --- Additional comment from cra(a)wpi.edu on 2007-02-12 19:44:41 EST --- You should change version to devel. There is a commented out invocation of rngd in /etc/rc.d/rc.sysinit: # Use the hardware RNG to seed the entropy pool, if available #[ -x /sbin/rngd -a -c /dev/hw_random ] && rngd if [ -f /etc/crypttab ]; then s=$"Starting disk encryption using the RNG:" Not sure why this is commented out, but it may be necessary for starting disk encryption that follows it. --- Additional comment from triage(a)lists.fedoraproject.org on 2008-04-04 00:39:59 EDT --- Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers --- Additional comment from paul(a)xelerance.com on 2008-04-07 17:54:03 EDT --- >From Fedora 9 beta 1: /etc/rc.d/rc.sysinit:#[ -x /sbin/rngd -a -c /dev/hw_random ] && rngd It is still not using rngd on system start. This means crypto software like Openswan cannot use any P4/AMD hardware random. --- Additional comment from mike(a)miketc.net on 2008-05-02 23:25:00 EDT --- Bug has been assigned and changed to rawhide so it's up to date with latest release/development. Also, maybe you could show what version you are using currently and are you fully updated to current rawhide? --- Additional comment from triage(a)lists.fedoraproject.org on 2008-05-13 22:28:05 EDT --- Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping --- Additional comment from mattdm(a)mattdm.org on 2008-05-23 12:24:36 EDT --- See bug #130350 for discussion of why the line in rc.sysinit is commented out. Seems like a separate init script (or some fancy upstart incantation) may be the way to go, but the underlying flaw in the daemon maybe should get fixed too. (Perhaps this needs to be split into two separate bugs?) This is still an issue in fully-updated rawhide, by the way: initscripts-8.76.2-1, rng-utils-2.0-1.15.1.fc9 --- Additional comment from ianburrell(a)gmail.com on 2008-09-20 18:22:57 EDT --- Created attachment 317293 Fixed version of init script The latest version of init script has a couple of syntax errors. This script fixes the syntax errors. --- Additional comment from triage(a)lists.fedoraproject.org on 2008-11-25 20:51:16 EST --- This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping --- Additional comment from triage(a)lists.fedoraproject.org on 2009-11-18 02:44:58 EST --- This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. 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 '10'. 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 10'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 10 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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 --- Additional comment from triage(a)lists.fedoraproject.org on 2009-12-18 00:54:02 EST --- Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 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. --- Additional comment from pizza(a)shaftnet.org on 2010-01-27 15:50:11 EST --- This is still a problem with rng-utils-2.0-4 in F12; there is no init script present in the package. --- Additional comment from juan.oropeza(a)oracle.com on 2011-10-03 11:41:55 EDT --- this problem is still occurring in Fedora 15, is there a package update that includes the startup script? I get the following output with the sample script ./rngd start Probing for HRNG module FATAL: Error inserting intel_rng (/lib/modules/2.6.40.4-5.fc15.x86_64/kernel/drivers/char/hw_random/intel-rng.ko): No such device FATAL: Error inserting via_rng (/lib/modules/2.6.40.4-5.fc15.x86_64/kernel/drivers/char/hw_random/via-rng.ko): No such device FATAL: Error inserting amd_rng (/lib/modules/2.6.40.4-5.fc15.x86_64/kernel/drivers/char/hw_random/amd-rng.ko): No such device (Hardware RNG device inode not found) ./rngd: Cannot find a hardware RNG device to use. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 2

[Bug 124246] grubby fatal error: unable to find a suitable template
by Red Hat Bugzilla 31 Oct '11

31 Oct '11

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=124246 --- Comment #65 from kevin martin <kevintm(a)ameritech.net> 2011-10-31 17:44:04 EDT --- Interestingly enough, it appears that it *did*, in fact, write out a new grub2/grub.cfg for the new kernel: # # DO NOT EDIT THIS FILE # # It is automatically generated by grub2-mkconfig using templates # from /etc/grub.d and settings from /etc/default/grub # ### BEGIN /etc/grub.d/00_header ### if [ -s $prefix/grubenv ]; then load_env fi set default="1" if [ "${prev_saved_entry}" ]; then set saved_entry="${prev_saved_entry}" save_env saved_entry set prev_saved_entry= save_env prev_saved_entry set boot_once=true fi function savedefault { if [ -z "${boot_once}" ]; then saved_entry="${chosen}" save_env saved_entry fi } function load_video { true } set timeout=10 ### END /etc/grub.d/00_header ### ### BEGIN /etc/grub.d/10_linux ### menuentry 'Fedora (3.2.0-0.rc0.git1.0.fc17.x86_64.debug)' --class gnu-linux --class gnu --class os { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='(hd0,msdos5)' search --no-floppy --fs-uuid --set=root 5fa84efc-2093-49a8-a997-98bb79a345e3 echo 'Loading Fedora (3.2.0-0.rc0.git1.0.fc17.x86_64)' linux /vmlinuz-3.2.0-0.rc0.git1.0.fc17.x86_64.debug root=UUID=abf1eb35-0fe0-4e2c-8ee5-c6542ace2c85 ro nouveau.noaccel=1 nouveau.vram_pushbuf=1 nouveau.vram_notify=1 log_buf_len=16M SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us echo 'Loading initial ramdisk ...' initrd /initramfs-3.2.0-0.rc0.git1.0.fc17.x86_64.debug.img } menuentry 'Fedora (3.2.0-0.rc0.git1.0.fc17.x86_64)' --class gnu-linux --class gnu --class os { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='(hd0,msdos5)' search --no-floppy --fs-uuid --set=root 5fa84efc-2093-49a8-a997-98bb79a345e3 echo 'Loading Fedora (3.2.0-0.rc0.git1.0.fc17.x86_64)' linux /vmlinuz-3.2.0-0.rc0.git1.0.fc17.x86_64 root=UUID=abf1eb35-0fe0-4e2c-8ee5-c6542ace2c85 ro nouveau.noaccel=1 nouveau.vram_pushbuf=1 nouveau.vram_notify=1 log_buf_len=16M SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us echo 'Loading initial ramdisk ...' initrd /initramfs-3.2.0-0.rc0.git1.0.fc17.x86_64.img } menuentry 'Linux, with Linux 3.1.0-0.rc9.git0.3.fc17.x86_64' --class gnu-linux --class gnu --class os { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='(hd0,msdos5)' search --no-floppy --fs-uuid --set=root 5fa84efc-2093-49a8-a997-98bb79a345e3 echo 'Loading Linux 3.1.0-0.rc9.git0.3.fc17.x86_64 ...' linux /vmlinuz-3.1.0-0.rc9.git0.3.fc17.x86_64 root=UUID=abf1eb35-0fe0-4e2c-8ee5-c6542ace2c85 ro nouveau.noaccel=1 nouveau.vram_pushbuf=1 nouveau.vram_notify=1 log_buf_len=16M echo 'Loading initial ramdisk ...' initrd /initramfs-3.1.0-0.rc9.git0.3.fc17.x86_64.img } menuentry 'Linux, with Linux 3.1.0-0.rc9.git0.3.fc17.x86_64 (recovery mode)' --class gnu-linux --class gnu --class os { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='(hd0,msdos5)' search --no-floppy --fs-uuid --set=root 5fa84efc-2093-49a8-a997-98bb79a345e3 echo 'Loading Linux 3.1.0-0.rc9.git0.3.fc17.x86_64 ...' linux /vmlinuz-3.1.0-0.rc9.git0.3.fc17.x86_64 root=UUID=abf1eb35-0fe0-4e2c-8ee5-c6542ace2c85 ro single nouveau.noaccel=1 nouveau.vram_pushbuf=1 nouveau.vram_notify=1 log_buf_len=16M echo 'Loading initial ramdisk ...' initrd /initramfs-3.1.0-0.rc9.git0.3.fc17.x86_64.img } menuentry 'Linux, with Linux 3.1.0-0.rc10.git0.1.fc17.x86_64' --class gnu-linux --class gnu --class os { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='(hd0,msdos5)' search --no-floppy --fs-uuid --set=root 5fa84efc-2093-49a8-a997-98bb79a345e3 echo 'Loading Linux 3.1.0-0.rc10.git0.1.fc17.x86_64 ...' linux /vmlinuz-3.1.0-0.rc10.git0.1.fc17.x86_64 root=UUID=abf1eb35-0fe0-4e2c-8ee5-c6542ace2c85 ro nouveau.noaccel=1 nouveau.vram_pushbuf=1 nouveau.vram_notify=1 log_buf_len=16M echo 'Loading initial ramdisk ...' initrd /initramfs-3.1.0-0.rc10.git0.1.fc17.x86_64.img } menuentry 'Linux, with Linux 3.1.0-0.rc10.git0.1.fc17.x86_64 (recovery mode)' --class gnu-linux --class gnu --class os { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='(hd0,msdos5)' search --no-floppy --fs-uuid --set=root 5fa84efc-2093-49a8-a997-98bb79a345e3 echo 'Loading Linux 3.1.0-0.rc10.git0.1.fc17.x86_64 ...' linux /vmlinuz-3.1.0-0.rc10.git0.1.fc17.x86_64 root=UUID=abf1eb35-0fe0-4e2c-8ee5-c6542ace2c85 ro single nouveau.noaccel=1 nouveau.vram_pushbuf=1 nouveau.vram_notify=1 log_buf_len=16M echo 'Loading initial ramdisk ...' initrd /initramfs-3.1.0-0.rc10.git0.1.fc17.x86_64.img } ### END /etc/grub.d/10_linux ### ### BEGIN /etc/grub.d/20_linux_xen ### ### END /etc/grub.d/20_linux_xen ### ### BEGIN /etc/grub.d/30_os-prober ### menuentry "Windows 7 (loader) (on /dev/sda1)" --class windows --class os { insmod part_msdos insmod ntfs set root='(hd0,msdos1)' search --no-floppy --fs-uuid --set=root 0A889E4D889E36E3 chainloader +1 } menuentry "Windows 7 (loader) (on /dev/sda2)" --class windows --class os { insmod part_msdos insmod ntfs set root='(hd0,msdos2)' search --no-floppy --fs-uuid --set=root B020C5A420C571C0 chainloader +1 } menuentry "Windows Recovery Environment (loader) (on /dev/sda3)" --class windows --class os { insmod part_msdos insmod ntfs set root='(hd0,msdos3)' search --no-floppy --fs-uuid --set=root F43CED0D3CECCBA4 drivemap -s (hd0) ${root} chainloader +1 } ### END /etc/grub.d/30_os-prober ### ### BEGIN /etc/grub.d/40_custom ### # This file provides an easy way to add custom menu entries. Simply type the # menu entries you want to add after this comment. Be careful not to change # the 'exec tail' line above. ### END /etc/grub.d/40_custom ### ### BEGIN /etc/grub.d/41_custom ### if [ -f $prefix/custom.cfg ]; then source $prefix/custom.cfg; fi ### END /etc/grub.d/41_custom ### ### BEGIN /etc/grub.d/90_persistent ### ### END /etc/grub.d/90_persistent ### -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 0

[Bug 124246] grubby fatal error: unable to find a suitable template
by Red Hat Bugzilla 31 Oct '11

31 Oct '11

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=124246 kevin martin <kevintm(a)ameritech.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kevintm(a)ameritech.net --- Comment #64 from kevin martin <kevintm(a)ameritech.net> 2011-10-31 17:41:52 EDT --- Still happens with latest rawhide and grub2: Running Transaction Updating : kernel-debuginfo-common-x86_64-3.2.0-0.rc0.git1.0.fc17.x86_64 1/19 Updating : kernel-tools-3.2.0-0.rc0.git1.0.fc17.x86_64 2/19 Updating : kernel-tools-devel-3.2.0-0.rc0.git1.0.fc17.x86_64 3/19 Updating : kernel-debuginfo-3.2.0-0.rc0.git1.0.fc17.x86_64 4/19 Installing : kernel-debug-debuginfo-3.2.0-0.rc0.git1.0.fc17.x86_64 5/19 Updating : kernel-tools-debuginfo-3.2.0-0.rc0.git1.0.fc17.x86_64 6/19 Installing : kernel-debug-devel-3.2.0-0.rc0.git1.0.fc17.x86_64 7/19 Updating : kernel-headers-3.2.0-0.rc0.git1.0.fc17.x86_64 8/19 Installing : kernel-devel-3.2.0-0.rc0.git1.0.fc17.x86_64 9/19 Installing : kernel-3.2.0-0.rc0.git1.0.fc17.x86_64 10/19 grubby fatal error: unable to find a suitable template Installing : kernel-debug-3.2.0-0.rc0.git1.0.fc17.x86_64 11/19 grubby fatal error: unable to find a suitable template Cleanup : kernel-tools-debuginfo-3.1.0-0.rc10.git0.1.fc17.x86_64 12/19 Cleanup : kernel-tools-devel-3.1.0-0.rc10.git0.1.fc17.x86_64 13/19 Cleanup : kernel-debuginfo-3.1.0-0.rc10.git0.1.fc17.x86_64 14/19 Cleanup : kernel-debuginfo-common-x86_64-3.1.0-0.rc10.git0.1.fc17.x86_64 15/19 Cleanup : kernel-3.1.0-0.rc9.git0.1.fc17.x86_64 16/19 grubby fatal error: unable to find a suitable template grubby: doing this would leave no kernel entries. Not writing out new config. Cleanup : kernel-headers-3.1.0-0.rc10.git0.1.fc17.x86_64 17/19 Cleanup : kernel-devel-3.1.0-0.rc9.git0.1.fc17.x86_64 18/19 Cleanup : kernel-tools-3.1.0-0.rc10.git0.1.fc17.x86_64 19/19 Verifying : kernel-tools-debuginfo-3.1.0-0.rc10.git0.1.fc17.x86_64 19/19 VerifyTransaction time: 2.557 Transaction time: 598.320 Removed: kernel.x86_64 0:3.1.0-0.rc9.git0.1.fc17 kernel-devel.x86_64 0:3.1.0-0.rc9.git0.1.fc17 Installed: kernel.x86_64 0:3.2.0-0.rc0.git1.0.fc17 kernel-debug.x86_64 0:3.2.0-0.rc0.git1.0.fc17 kernel-debug-debuginfo.x86_64 0:3.2.0-0.rc0.git1.0.fc17 kernel-debug-devel.x86_64 0:3.2.0-0.rc0.git1.0.fc17 kernel-devel.x86_64 0:3.2.0-0.rc0.git1.0.fc17 Updated: kernel-debuginfo.x86_64 0:3.2.0-0.rc0.git1.0.fc17 kernel-debuginfo-common-x86_64.x86_64 0:3.2.0-0.rc0.git1.0.fc17 kernel-headers.x86_64 0:3.2.0-0.rc0.git1.0.fc17 kernel-tools.x86_64 0:3.2.0-0.rc0.git1.0.fc17 kernel-tools-debuginfo.x86_64 0:3.2.0-0.rc0.git1.0.fc17 kernel-tools-devel.x86_64 0:3.2.0-0.rc0.git1.0.fc17 This happens to be a home compiled kernel (to get rid of the debug code so I could install akmod-nvidia driver (since there's an unresolved error with nouveau) so this was a "yum localinstall kernel*rpm". This bug has been open since 2004? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 0

[Bug 246872] Initscript Review
by Red Hat Bugzilla 20 Oct '11

20 Oct '11

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=246872 Harald Hoyer <harald(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |CURRENTRELEASE Last Closed| |2011-10-20 04:47:24 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 0

[Bug 246879] Initscript Review (bittorrent)
by Red Hat Bugzilla 20 Oct '11

20 Oct '11

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=246879 Paul Howarth <paul(a)city-fan.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |WONTFIX Last Closed| |2011-10-20 04:37:22 --- Comment #3 from Paul Howarth <paul(a)city-fan.org> 2011-10-20 04:37:22 EDT --- bittorrent has gone closed source and has been dropped from Fedora in F16, so this isn't going to get done. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 0

needinfo canceled: [Bug 543660] Perl Archive::Zip fails writing to an unseekable file handle after calling desiredCompressionLevel()
by Red Hat Bugzilla 17 Oct '11

17 Oct '11

Product: Fedora Version: rawhide Component: perl-Archive-Zip Marcela Mašláňová <mmaslano(a)redhat.com> has canceled Bug Zapper <triage(a)lists.fedoraproject.org>'s request for needinfo: Bug 543660: Perl Archive::Zip fails writing to an unseekable file handle after calling desiredCompressionLevel() https://bugzilla.redhat.com/show_bug.cgi?id=543660 ------- Additional Comments from Marcela Mašláňová <mmaslano(a)redhat.com> I keep this bug report for tracking progress in upstream.

1 0

needinfo canceled: [Bug 592089] SELinux is preventing /usr/lib/cups/backend/mfp "getattr" access to device /dev/mfpports/probe.
by Red Hat Bugzilla 15 Oct '11

15 Oct '11

Product: Fedora Version: 12 Component: selinux-policy Simon <simon(a)conditional-fee.co.uk> has canceled Bug Zapper <triage(a)lists.fedoraproject.org>'s request for needinfo: Bug 592089: SELinux is preventing /usr/lib/cups/backend/mfp "getattr" access to device /dev/mfpports/probe. https://bugzilla.redhat.com/show_bug.cgi?id=592089 ------- Additional Comments from Simon <simon(a)conditional-fee.co.uk> Hello again, I bought a samsung CLX-6220FX which prints OK but each time I try to use the smatpanel or unified driver configurater selinux block it:- SELinux is preventing /opt/Samsung/mfp/bin/Configurator from using the execstack access on a process. ***** Plugin allow_execstack (53.1 confidence) suggests ******************** If you believe that None should not require execstack Then you should clear the execstack flag and see if /opt/Samsung/mfp/bin/Configurator works correctly. Report this as a bug on None. You can clear the exestack flag by executing: Do execstack -c None ***** Plugin catchall_boolean (42.6 confidence) suggests ******************* If you want to allow unconfined executables to make their stack executable. This should never, ever be necessary. Probably indicates a badly coded executable, but could indicate an attack. This executable should be reported in bugzilla Then you must tell SELinux about this by enabling the 'allow_execstack' boolean. Do setsebool -P allow_execstack 1 ***** Plugin catchall (5.76 confidence) suggests *************************** If you believe that Configurator should be allowed execstack access on processes labeled unconfined_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep Configurator /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 023 Target Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 023 Target Objects Unknown [ process ] Source Configurator Source Path /opt/Samsung/mfp/bin/Configurator Port <Unknown> Host www.conditional-fee.co.uk Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.9.7-44.fc14 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name www.conditional-fee.co.uk Platform Linux www.conditional-fee.co.uk 2.6.35.14-97.fc14.i686.PAE #1 SMP Sat Sep 17 00:22:29 UTC 2011 i686 i686 Alert Count 1 First Seen Sat 15 Oct 2011 17:11:32 BST Last Seen Sat 15 Oct 2011 17:11:32 BST Local ID b1f3562c-ec3e-48c8-9798-73102216119f Raw Audit Messages type=AVC msg=audit(1318695092.132:2519): avc: denied { execstack } for pid=14265 comm="Configurator" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process type=SYSCALL msg=audit(1318695092.132:2519): arch=i386 syscall=mprotect success=no exit=EACCES a0=bfb02000 a1=1000 a2=1000007 a3=bfb020ec items=0 ppid=1 pid=14265 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=268 comm=Configurator exe=/opt/Samsung/mfp/bin/Configurator subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) Hash: Configurator,unconfined_t,unconfined_t,process,execstack audit2allow #============= unconfined_t ============== #!!!! This avc can be allowed using the boolean 'allow_execstack' allow unconfined_t self:process execstack; audit2allow -R #============= unconfined_t ============== #!!!! This avc can be allowed using the boolean 'allow_execstack' I want to use the scanning capability but not if the method involves any security risk (I've got another scanner -not as good) What are the implications of using execstack -c None please?

1 0

needinfo canceled: [Bug 503149] Add features to Anaconda to aid installation on Apple computers
by Red Hat Bugzilla 15 Oct '11

15 Oct '11

Product: Fedora Version: 15 Component: anaconda Chris Murphy <bugzilla(a)colorremedies.com> has canceled Bug Zapper <triage(a)lists.fedoraproject.org>'s request for needinfo: Bug 503149: Add features to Anaconda to aid installation on Apple computers https://bugzilla.redhat.com/show_bug.cgi?id=503149 ------- Additional Comments from Chris Murphy <bugzilla(a)colorremedies.com> This might need a separate bug report but I'll stick it in here for now. Consistently I'm finding the partition type GUID is wrong in a number of cases: The first ext4 partition listed in GPT (whether it's the 2nd partition entry or the 5th) is thus far always the GUID for "EFI System Partition" GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B. This is definitely incorrect, it should be GUID 0FC63DAF-8483-4772-8E79-3D69D8477DE4 "Linux filesystem". The net result of this bug is that there are two EFI System Partitions on a dual boot system, one of which is the real EFI System partition, and the other is the partition mounting as /boot. Probably not a good idea, should be fixed. Subsequent partitions either ext4, btrfs, or xfs have partition type GUID EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 "Microsoft Windows basic data". This was done for a long time under MBR, using the same partition type hex code as Windows but linux filesystems have their own GUID which is 0FC63DAF-8483-4772-8E79-3D69D8477DE4. So it's a minor point, but ought to be fixed. "BIOS Boot" has the correct partition type GUID. "Linux LVM" partitions also have the correct partition type GUID. Last, all of my comments apply to F16 beta, so the version for this bug should be changed to 16. Now that I've inundated everyone with multiple comments, I'll remove the needinfo flag and await comments/questions on next steps.

1 0

needinfo canceled: [Bug 524458] Macbook Pro 5,5 video does not resume (with and without Nouveau KMS)
by Red Hat Bugzilla 11 Oct '11

11 Oct '11

Product: Fedora Version: 15 Component: kernel me(a)ibotty.net has canceled Bug Zapper <triage(a)lists.fedoraproject.org>'s request for needinfo: Bug 524458: Macbook Pro 5,5 video does not resume (with and without Nouveau KMS) https://bugzilla.redhat.com/show_bug.cgi?id=524458 ------- Additional Comments from me(a)ibotty.net as indicated last year, it did work with some not-so-magic kernel parameters. in f15 it works out of the box (well: using a newer kernel because of other bugs, which i can hardly reproduce (it's not my notebook) but which do not happen with the 3.1rcs.)

1 0

[Bug 253635] Inoperable short-cuts in search dialog
by Red Hat Bugzilla 07 Oct '11

07 Oct '11

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=253635 Jerry Amundson <jamundso(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|jamundso(a)gmail.com | -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

triage October 2011