triage January 2010

triage@lists.stg.fedoraproject.org

1 participants
50 discussions

[Bug 483777] New: lot of undefined-non-weak-symbol with festival
by Red Hat Bugzilla 14 Mar '11

14 Mar '11

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: lot of undefined-non-weak-symbol with festival https://bugzilla.redhat.com/show_bug.cgi?id=483777 Summary: lot of undefined-non-weak-symbol with festival Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Keywords: FutureFeature Severity: medium Priority: medium Component: festival AssignedTo: davidz(a)redhat.com ReportedBy: kwizart(a)gmail.com QAContact: extras-qa(a)fedoraproject.org CC: mattdm(a)mattdm.org, skasal(a)redhat.com, thomas.moschny(a)gmx.de, tim(a)niemueller.de, mclasen(a)redhat.com, davidz(a)redhat.com, kwizart(a)gmail.com, robert.zhangle(a)gmail.com, fedora-triage-list(a)redhat.com, schiffer(a)cs.rwth-aachen.de Estimated Hours: 0.0 Classification: Fedora Clone Of: 242607 Created an attachment (id=330741) --> (https://bugzilla.redhat.com/attachment.cgi?id=330741) rpmlint on installed festival package +++ This bug was initially created as a clone of Bug #242607 +++ --- Additional comment from kwizart(a)gmail.com on 2009-01-22 11:53:33 EDT --- Created an attachment (id=329721) --> (https://bugzilla.redhat.com/attachment.cgi?id=329721) undefined-non-weak-symbol_festival-lib-1.96-7.fc10.x86_64.log There are lot of undefined-non-weak-symbol_festival in the festival-lib-1.96-7.fc10 package (running rpmlint fastival-lib on installed package). Theses symbols should be added at link time and could be the reason of runtime failures when the needed libraries aren't present at runtime. It will also prevents the linker to preload suches libraries which will degrade performances when loading. (since every symbol will be revolved at runtime). -- 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 8

[Bug 499204] New: Hardware freezes on Dell Optiplex 320 while booting
by Red Hat Bugzilla 05 Dec '10

05 Dec '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Hardware freezes on Dell Optiplex 320 while booting https://bugzilla.redhat.com/show_bug.cgi?id=499204 Summary: Hardware freezes on Dell Optiplex 320 while booting Product: Fedora Version: 10 Platform: All OS/Version: Linux Status: NEW Status Whiteboard: bzcl34nup Severity: high Priority: low Component: grub AssignedTo: pjones(a)redhat.com ReportedBy: d_preston215(a)yahoo.com QAContact: extras-qa(a)fedoraproject.org CC: pjones(a)redhat.com, tomc(a)kendeco.com, pawsa(a)theochem.kth.se, craigwhite(a)azapple.com, ajn(a)ite.gmu.edu, z(a)canteiros.org, kelsey(a)kelseyhightower.net, eric.caron(a)gmail.com, fedora-triage-list(a)redhat.com, linux-bugs(a)dell.com Estimated Hours: 0.0 Classification: Fedora Clone Of: 219715 +++ This bug was initially created as a clone of Bug #219715 +++ Description of problem: The machine, an Dell Optiplex 320, freezes while booting with grub. It seems to happen while the kernel is being loaded and before the kernel is started. Our guess is a bug in the BIOS that grub tickles. Booting with lilo works. Version-Release number of selected component (if applicable): grub-0.97-13.i386 The machine has the most recent version of the BIOS, 1.0.9. The command "blocklist /vmlinuz-2.6.18-1.2798.fc6" from the grub command-line also freezes the machine. --- Additional comment from ackistler(a)yahoo.com on 2007-01-20 20:47:13 EDT --- I have the same hardware, although I'm trying fc5 currently. Going to the grub command line, I can execute "cat /grub/menu.lst" and get the contents of the file displayed. (Of course, the menu is displayed on boot, too, so I expected cat to work.) However, on a manual attempt to boot, the kernel command freezes the machine. The Optiplex 320 has an ATI sb600 SATA controller, if that matters. I had to supply all-generic-ide to the installer to get it to run, but it ran. I'll post back here if my fc6 experience is different. --- Additional comment from pawsa(a)theochem.kth.se on 2007-03-26 13:46:12 EDT --- I see the bug on the same hardware (Dell Optiplex 320) with FC6 as well. "Uncompressing xxxx" is the last message I see. No combination of command line options that I tried (noprobe, noapic and so on) could fix it. Replacing the grub bootloader with lilo makes the problem disappear. This is seen with fc6 + all the updates installed allready in the installation phase: 2.6.20-1.2933.fc6 kernel is being booted. --- Additional comment from kelsey(a)kelseyhightower.net on 2007-07-05 11:53:37 EDT --- I have this same machine. I am running RHEL 5 Workstation. I was able to get the machine to install, passing pci=nomsi as a kernel option. Everything installs fine, but the machine will not boot with its default boot loader GRUB. I have to use a rescue disk to install LILO overwriteing GRUB. I have since added a PCI SATA controller which allows the system to install without using the pci=nomsi option. I still get errors with the GRUB booting the Linux kernel. There seems to be conflict with GRUB and the BIOS, as LILO works and GRUB does not. Is this a issue that RedHat plans to address? Will they try and patch GRUB to work on these machines? Thanks for any feedback. --- Additional comment from matt_domsch(a)dell.com on 2007-07-24 14:58:34 EDT --- Has anyone tried passing 'edd=skipmbr' as a kernel option? Just curious... -Matt --- Additional comment from pawsa-gpa(a)theochem.kth.se on 2007-08-07 06:19:52 EDT --- I have just tried edd=skipmbr instead of pci=nomsi - and the kernel hangs just after the detection of the USB keyboard. Kernel version is 2.6.18-1.8.el5. I obviously booted with lilo - grub is nonfunctional in any form. --- Additional comment from eric.caron(a)gmail.com on 2007-09-07 13:33:44 EDT --- This bug still exists in Fedora 7. Its very hard to install on a new Optiplex 320. Installing Lilo presents its own issues because of DEVMAPPER-related issues, and grub2 doesn't appear to fix it either. --- Additional comment from eric.caron(a)gmail.com on 2007-09-07 15:47:56 EDT --- Interesting revelation... When I add "vga=792" to grub.conf, and boot from the CD and then choose "Boot from local disk" (which then loads grub from sda), the system boots perfectly. Does that help in addressing the issue? --- Additional comment from lkundrak(a)redhat.com on 2007-10-15 11:19:10 EDT --- Are you confident this is a Grub issue, not a Kernel one? Are any kernel guys in CC? Could you please run dmidecode to find out what BIOS version do you have? Are there any BIOS updates available for the machine? Did you try applying them? --- Additional comment from ianburrell(a)gmail.com on 2007-10-15 17:26:54 EDT --- I am pretty sure this is a Grub problem. It hangs before it prints the first kernel message. It also hangs when doing a "blocklist" command after printing a handful of blocks. I last tried Grub with BIOS version 1.1.7. There is a more recent version (1.1.10) that I haven't tried grub with. I also tried lilo with the lba32 option, and grub with forcelba option, thinking it might be a problem with LBA32 support but lilo worked regardless and grub hung. --- Additional comment from ianburrell(a)gmail.com on 2007-10-19 13:47:21 EDT --- I upgraded the BIOS to version 1.1.10 and still has the Grub hang problem. --- Additional comment from craigwhite(a)azapple.com on 2007-11-12 18:32:52 EDT --- Nothing has changed on Fedora 8 - in fact, it's gotten worse. I could use Fedora 7 x86_64 without any special boot parameters but of course, grub never worked but lilo has indeed worked. All of my mentions here refer only to x86_64 as I gave up trying to run i386 on these systems a while back. Upgraded to Fedora 8 and simply cannot even boot from Rescue disc - it hangs with an error... PCI: MSI quirk detected. MSI deactivated pci_hotplug: PCI Hot Plug PCI Core version: 0.5 ACPI Exception (processor_core-0819): AE_NOT_FOUND, Processor Device is not present [20070126] *** last line repeats 2 more times *** Real Time Clock Driver v1.12ac Non-volatile memory driver v1.2 Linux apgart interface v0.102 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled and there it stops...never proceeds. The only way I've been able to get Fedora 8 Linux Rescue CD or CD Image from boot.iso to boot is to pass 'acpi=off' I will attach dmidecode and lspci --- Additional comment from craigwhite(a)azapple.com on 2007-11-12 18:33:46 EDT --- Created an attachment (id=256041) --> (https://bugzilla.redhat.com/attachment.cgi?id=256041) output of dmidecode on Dell Optiplex 320 --- Additional comment from craigwhite(a)azapple.com on 2007-11-12 18:34:24 EDT --- Created an attachment (id=256051) --> (https://bugzilla.redhat.com/attachment.cgi?id=256051) output of lspci -vv from Dell Optiplex 320 --- Additional comment from craigwhite(a)azapple.com on 2007-11-12 18:40:40 EDT --- I'm gonna vent a bit here... This isn't getting fixed. See bugzilla 219043 https://bugzilla.redhat.com/show_bug.cgi?id=219043 This all began on Fedora 5 (Fedora 6 for me) and continued on Fedora 7 and now has gotten worse in Fedora 8 Grub has NEVER worked on these Dell Optiplexes...as far as I can tell, for anyone ever. I am using Lilo-22.8 I could get i386 working only if I passed ridiculous kernel parameters such as pci=nomsi all-generic-ide but until Fedora 8 (2.6.23.1-49.fc8) I didn't have to sacrifice the unborn on x86_64. Now it requires both Lilo and apci=off PLEASE - PLEASE - PLEASE do something --- Additional comment from lkundrak(a)redhat.com on 2007-11-12 19:27:44 EDT --- (In reply to comment #11) > The only way I've been able to get Fedora 8 Linux Rescue CD or CD Image from > boot.iso to boot is to pass 'acpi=off' (In reply to comment #14) > I could get i386 working only if I passed ridiculous kernel parameters such as > pci=nomsi all-generic-ide but until Fedora 8 (2.6.23.1-49.fc8) I didn't have to > sacrifice the unborn on x86_64. Now it requires both Lilo and apci=off This is a kernel thing. Hopefully kernel people will be able to do more than us, bug #379201 for the kernel part. --- Additional comment from craigwhite(a)azapple.com on 2007-11-14 14:27:54 EDT --- OK - primarily concentrating on grub issues then, I have lilo installed and I can get it to boot - kernel params per kernel-tracking bugzilla are now 'pci=noacpi timesource=acpi_pm' lilo works but I have to manually run lilo command after each kernel update grub as has been widely reported never seems to work on these systems. I have updated BIOS to latest - here is latest output of dmidecode... https://bugzilla.redhat.com/attachment.cgi?id=258581 # grub-install /dev/sda Installation finished. No error reported. This is the contents of the device map /boot/grub/device.map. Check if this is correct or not. If any of the lines is incorrect, fix it and re-run the script `grub-install'. # this device map was generated by anaconda (hd0) /dev/sda # cat /boot/grub/grub.conf # grub.conf generated by anaconda # ...snip... #boot=/dev/sda default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title Fedora (2.6.23.1-49.fc8) root (hd0,0) kernel /vmlinuz-2.6.23.1-49.fc8 ro root=LABEL=/1 pci=noacpi timesource=acpi_pm initrd /initrd-2.6.23.1-49.fc8.img This will never boot and I have to reinstall lilo again. Is my process correct? --- Additional comment from craigwhite(a)azapple.com on 2007-11-21 14:08:00 EDT --- I recognize that the inability to boot on 2.6.23 kernel (Fedora 8) issue is probably more likely to be solved by bugzilla 379201 in kernel-maint but... grub still doesn't work on these systems - at least no one has reported success with getting it to boot. Lilo boots but I can't install kernel updates without manually running 'lilo -v' because grubby code is uncooperative. On fedora-list yesterday... https://www.redhat.com/archives/fedora-list/2007-November/msg03487.html poster suggests that grub2 worked for him --- Additional comment from fedora-triage-list(a)redhat.com on 2008-04-04 01:15:01 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 ianburrell(a)gmail.com on 2008-04-04 13:22:35 EDT --- This problem still occurs with Fedora 8 and the most recent version of grub, 0.97-19.i386. I am using the most recent BIOS update, 1.1.11, for the Optiplex 320. The machine still hangs while grub is booting the machine. --- Additional comment from poelstra(a)redhat.com on 2008-04-06 15:54:35 EDT --- thanks for the update. changing to ASSIGNED --- Additional comment from fedora-triage-list(a)redhat.com on 2008-11-26 02:07:26 EDT --- This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. 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 '8'. 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 8'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 8 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 fedora-triage-list(a)redhat.com on 2009-01-09 02:02:26 EDT --- Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 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. -- 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 11

[Bug 513800] New: attempt to use kdump just freezes the box
by Red Hat Bugzilla 05 Dec '10

05 Dec '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: attempt to use kdump just freezes the box https://bugzilla.redhat.com/show_bug.cgi?id=513800 Summary: attempt to use kdump just freezes the box Product: Fedora Version: 11 Platform: x86_64 OS/Version: Linux Status: NEW Severity: medium Priority: low Component: kexec-kdump AssignedTo: vgoyal(a)redhat.com ReportedBy: matt.castelein(a)rocsoft.com QAContact: lwang(a)redhat.com CC: matt.castelein(a)rocsoft.com, fedora-triage-list(a)redhat.com Estimated Hours: 0.0 Classification: Fedora Clone Of: 239244 +++ This bug was initially created as a clone of Bug #239244 +++ Description of problem: After getting some kernel problems, I finally decided to give kdump a try, but to my surprise, it does not work. Any attempt to use kdump (with sysrq-c or echo c >/proc/sysrq-trigger) leads to instant system crash. sysrq does not work anymore at this point and the only solution is hard poweroff. I see that FC7 does not ship kernel-kdump package anymore, but since FC7 kernel is built with CONFIG_RELOCATABLE, it should be fine as kdump kernel I presume. Version-Release number of selected component (if applicable): kernel-2.6.21-1.3116.fc7 How reproducible: 100% reproducible. Steps to Reproduce: boot kernel with crashkernel=128M@16M option run service kdump start run sysctl kernel.sysrq=1 press sysrq-t or echo c >/proc/sysrq-trigger Additional info: The system is DELL Latitude D620 laptop with Intel Core2 Duo T7200 CPU, 2G RAM, i686 arch. Latest FC7 stuff from development repo. --- Additional comment from green(a)linuxhacker.ru on 2007-05-14 15:24:47 EDT --- I upgraded to 2.6.21-1.3142.fc7 and the problem is still present. --- Additional comment from fedora-triage-list(a)redhat.com on 2008-04-03 20:33:50 EDT --- Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're 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. --- Additional comment from fedora-triage-list(a)redhat.com on 2008-05-06 21:41:26 EDT --- This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp --- Additional comment from matt.castelein(a)rocsoft.com on 2009-07-24 19:47:31 EDT --- I have encountered this problem on Fedora 11. I am following the instructions at: https://fedoraproject.org/wiki/Kernel/kdump.. When I get to the point where I do "echo c > /proc/sysrq-trigger" the box just freezes and no dump kernel is loaded. It just sits there until I reset it. -- 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 5

[Bug 186527] Startup hangs at "starting system message bus" if ldaps authentication enabled in firstboot
by Red Hat Bugzilla 31 Jan '10

31 Jan '10

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=186527 Maxim Molchanov <i.censo(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |i.censo(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

[Bug 207470] Need ability to handle duplicate VG names for Xen
by Red Hat Bugzilla 28 Jan '10

28 Jan '10

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=207470 --- Comment #21 from Richard W.M. Jones <rjones(a)redhat.com> 2010-01-28 16:32:19 EST --- (In reply to comment #19) > After doing a vgrename, I was able to mount it and go in and fix some files, > but on doing vgrename to set it back to VolGroup00, I ran into this problem... > Arrrggggg. Sounds complicated though. For editing stuff in your Xen disk images, use http://libguestfs.org/ -- 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 207470] Need ability to handle duplicate VG names for Xen
by Red Hat Bugzilla 28 Jan '10

28 Jan '10

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=207470 --- Comment #20 from Guymon <guy+RH(a)photografius.com> 2010-01-28 16:31:36 EST --- Ooops forgot a step. After you open the initrd img you need to vim in and edit the init file in here at the bottom you will find references to the /dev/VolGroup00/LogVol00 change to /dev/VolGroup00_WET/LogVol00 (of as needed) Sorry Kind of important. I didn't know how to edit my comment above. -- 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 207470] Need ability to handle duplicate VG names for Xen
by Red Hat Bugzilla 28 Jan '10

28 Jan '10

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=207470 Guymon <guy+RH(a)photografius.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |guy+RH(a)photografius.com --- Comment #19 from Guymon <guy+RH(a)photografius.com> 2010-01-28 16:20:50 EST --- "One potential option that is relatively easy and gets us a little further is this. Modify vgrename to have a "--force" option on it and allow renames into duplicate VG names." I'll second that! My story: After doing a vgrename, I was able to mount it and go in and fix some files, but on doing vgrename to set it back to VolGroup00, I ran into this problem... Arrrggggg. Here's my bad remedy all from Dom0, it prevented me from rebuilding from scratch. This worked for me, so do at your own risk. I'm also breezing over stuff quick as if you got yourself in this mess, you should be pretty conferable as a sysadmin. My mess up started with I had vgrename VolGroup00 to --> VolGroup00_WET To make it work again in Xen We have to change the grub.conf and the initrd.img (my case initrd-2.6.18-164.10.1.el5xen.img) along with the /etc/fstab as it will try to fsck VolGroup00 and fail on boot. 1st. We need to mount the boot partition with the initrd*.img and the grub.conf files. I used: mount -o loop,offset=32256 /dev/VolGroup_Wet/LogVol_Wet /mnt/LogVol_WET (love offset!) /mnt/LogVol_WET being my mnt space on Dom0. In here we will find /grub/grub.conf. Vim in and change the VolGroup00 to VolGroup00_WET(what my NEW VolGroup got vgrename too) Next grab the initrd*.img. My current one was called initrd-2.6.18-164.10.1.el5xen.img. I found out how to change this here [http://www.fedoraforum.org/forum/showthread.php?t=114819] Thanks!!!! heres a quick copy paste from there. --------------------------------------------------------------------------- the problem is that the intrd was indeed in the gzip format and further in the cpio format, but the cpio format is not the default "bin" format used by cpio but a "newc" format, so the extraction part was perfect, but when you put it back you change the cpio format and hence the kernel hangs (collection of files and directories) -> cpio archives -> gzip -> final initrd.img that means you can give the following commands - mkdir ~/tmp cd ~/tmp cp /boot/initrd.img ./initrd.gz gunzip initrd.gz mkdir tmp2 cd tmp2 cpio -id < ../initrd.img now you should have a lot of files in ~/tmp/tmp2 directories, including a lot of subdirectories like sbin,lib now do the required changes to the files then pack the files back into the archive using the following command cd ~/tmp/tmp2 find . | cpio --create --format='newc' > ~/tmp/newinitrd cd ~/tmp gzip newinitrd now you would have a newinitrd.gz rename this now - mv newinitrd.gz as newinitrd.img this is the new boot image now !! ---------------------------------------------------------------------------- Move this new image back to your mounted partition. I renamed the old one, just incase. Whew thats done! unmount. umount /mnt/LogVol_WET 2nd. Lets Mount root / . Unfortunately offset won't work on this. I did this like this from the Dom0. /sbin/kpartx -a /dev/VolGroup_Wet/LogVol_Wet /usr/sbin/pvscan /usr/sbin/lvscan /usr/sbin/vgchange -a y ## Mount it on /mnt/LogVol_WET mount /dev/VolGroup00_WET/LogVol00 /mnt/LogVol_WET now go in vim /mnt/LogVol_WET/etc/fstab and change VolGroup00 to VolGroup00_WET(My new volgrp) DON'T edit your Dom0 fstab.. I did that but luckily noticed and fixed my mistake!!!! phew... I think that's everything. Now unmount and clean up your kpartx stuff umount /mnt/LogVol_WET /usr/sbin/vgchange -a n /sbin/kpartx -d /dev/VolGroup_Wet/LogVol_Wet Now I can /usr/sbin/xm create WET and I'm golden! I know this seems like a lot and I learned a lot. I mostly put this here knowing I will loose my notes some time in the future. You have to love Google. I would have been hosed! Oh yea as I state before all this could have been avoided if vgrename had a "--force" option!!!!!! -- 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 247616] gnupg2: gpg-agent autostart, ssh support (RFE)
by Red Hat Bugzilla 28 Jan '10

28 Jan '10

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=247616 --- Comment #25 from Patrick C. F. Ernzer <pcfe(a)redhat.com> 2010-01-28 04:36:08 EST --- just changing the 2 directories in the spec file was not enough, will need SELinux adaptation. -- 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 215371] rngd is missing initscript, attached
by Red Hat Bugzilla 27 Jan '10

27 Jan '10

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=215371 Solomon Peachy <pizza(a)shaftnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pizza(a)shaftnet.org --- Comment #17 from Solomon Peachy <pizza(a)shaftnet.org> 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. -- 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 246325] need LANGUAGE settings for translation fallbacks
by Red Hat Bugzilla 25 Jan '10

25 Jan '10

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=246325 --- Comment #13 from fujiwara <tfujiwar(a)redhat.com> 2010-01-25 01:46:34 EST --- If you like to set $LANGUAGE besides the system locale of /etc/sysconfig/i18n, my suggestion is: 1. s-c-l exports $LANGUAGE file per locale, e.g. a new file /usr/share/system-config-language/locale/$LANG/locale_file, which includes $LANGUAGE value - The similar implementation has been done in a UNIX. 2. s-c-l is able to write $LANGUAGE in /etc/sysconfig/i18n besides $LANG Then I think GDM could implement to load the language file per locale besides i18n file. The latest GDM or 2.20 base already can load the i18n file. -- 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 January 2010