[opensuse] rpm question
I get the following to stderr when running rpm -qa error: rpmdbNextIterator: skipping h# 808 Header V3 DSA signature: BAD, key ID ddaf6454 and error: rpmdbNextIterator: skipping h# 888 Header V3 DSA signature: BAD, key ID ddaf6454 I guess some packages were either signed odd, or something else has gone kaplooey. Any suggestions on (1) how to tell which packages this is for, and (2) how to possibly repair it? Although rpm seems to be working ok, this does not look like something to ignore. TIA -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Office: Int +46 8-615 60 20 Mobile: Int +46 70-815 1696 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
A quick question - we are just looking at one of our servers now, discussing space checks & what should be checked. In this case I have the following filesystems (on the root disk): Filesystem 1K-blocks Used Available Use% Mounted on /dev/cciss/c0d0p1 5246680 2455876 2790804 47% / tmpfs 4025588 12 4025576 1% /dev/shm /dev/cciss/c0d0p5 85624 39156 46468 46% /boot /dev/cciss/c0d0p6 5246680 500452 4746228 10% /home /dev/cciss/c0d0p11 48787112 38963856 9823256 80% /opt /dev/cciss/c0d0p7 5246680 1360004 3886676 26% /usr /dev/cciss/c0d0p8 2309172 413156 1896016 18% /var Question: what happens if /boot gets full (Use% = 100%) How will this affect the server ? Dirk *** Disclaimer *** The information contained in this e-mail is confidential and legally privileged and is intended solely for the addressee and to others who have the authority to receive it. Access to this e-mail by anyone else is unauthorized and as such, any disclosure, copying, distribution or any action taken or omitted in reliance on it is unlawful. If you have received this e-mail in error, please notify the sender immediately. The views expressed in this e-mail are the views of the individual sender and should in no way be construed as the views of the Company. The Company is not liable to ensure that outgoing e-mails are virus-free. The Company is not liable, should information or data, for whatever reason, be corrupted or fail to reach its intended addressee. The Company is not liable for any loss or damage of whatsoever nature and howsoever arising resulting from the opening or the use of the information in this e-mail, including its attachments and links. The sender of this e-mail is subject to and bound by the terms and conditions of Company+IBk-s Electronic Communications Usage Policy. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, Jan 04, 2008 at 04:11:48PM +0200, Dirk Moolman wrote:
Question: what happens if /boot gets full (Use% = 100%)
How will this affect the server ?
Your next kernel update will fail. Rasmus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Rasmus Plewe wrote:
On Fri, Jan 04, 2008 at 04:11:48PM +0200, Dirk Moolman wrote:
Question: what happens if /boot gets full (Use% = 100%)
How will this affect the server ?
Your next kernel update will fail.
Rasmus
It is worth noting that nothing should typically be writing to /boot except for kernel installs/updates. -- kr -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
K.R. Foley wrote:
Rasmus Plewe wrote:
On Fri, Jan 04, 2008 at 04:11:48PM +0200, Dirk Moolman wrote:
Question: what happens if /boot gets full (Use% = 100%)
How will this affect the server ? Your next kernel update will fail.
Rasmus
It is worth noting that nothing should typically be writing to /boot except for kernel installs/updates.
Yast also puts memtest there. -- Use OpenOffice.org <http://www.openoffice.org> -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Friday 04 January 2008 15:29:54 K.R. Foley wrote:
Rasmus Plewe wrote:
On Fri, Jan 04, 2008 at 04:11:48PM +0200, Dirk Moolman wrote:
Question: what happens if /boot gets full (Use% = 100%)
How will this affect the server ?
Your next kernel update will fail.
Rasmus
It is worth noting that nothing should typically be writing to /boot except for kernel installs/updates.
bootsplash themes go there, and those are somewhat popular, I'm told Anders -- Madness takes its toll -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, Jan 04, 2008 at 05:46:35PM +0100, Anders Johansson wrote:
On Friday 04 January 2008 15:29:54 K.R. Foley wrote:
Rasmus Plewe wrote:
On Fri, Jan 04, 2008 at 04:11:48PM +0200, Dirk Moolman wrote:
Question: what happens if /boot gets full (Use% = 100%)
How will this affect the server ?
Your next kernel update will fail.
It is worth noting that nothing should typically be writing to /boot except for kernel installs/updates.
bootsplash themes go there, and those are somewhat popular, I'm told
# find /boot -print | xargs rpm -qf | grep -v owned | sort | uniq will tell you which packages installed files in /boot for your installation, and an update of these will fail. Of course, any other write operation will fail as well, as you correctly point out. Rasmus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Dirk Moolman a écrit :
/dev/cciss/c0d0p5 85624 39156 46468 46% /boot
there are no mor reason to make a separate folder for /boot (except may be on lvm systems). also any kernel update needs a reboot to be active, so on a server must be closely monitored jdd -- http://www.dodin.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2008/01/04 15:57 (GMT+0100) jdd apparently typed:
there are no mor reason to make a separate folder for /boot (except may be on lvm systems).
Reasons remain, though necessity does not. As http://en.opensuse.org/Bugs/grub spells out, a HD0 primary partition for Grub to live on (which need not normally be mounted as /boot) is preferable to needing Grub in the MBR, while the location (primary or logical, HD0 or otherwise) generally makes no matter for / or any other native partition. -- "In the beginning was the Word, and the Word was with God, and the Word was God." John 1:1 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Felix Miata a écrit :
On 2008/01/04 15:57 (GMT+0100) jdd apparently typed:
there are no mor reason to make a separate folder for /boot (except may be on lvm systems).
Reasons remain, though necessity does not. As http://en.opensuse.org/Bugs/grub spells out, a HD0 primary partition for Grub to live on (which need not normally be mounted as /boot) is preferable to needing Grub in the MBR, while the location (primary or logical, HD0 or otherwise) generally makes no matter for / or any other native partition.
this -very interesting- page say that grub should stay on a primary marked bootable, no mention of /boot. and this is not the usual Linux way, so worth to mention (I'll open an other thread) jdd -- http://www.dodin.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2008/01/04 20:02 (GMT+0100) jdd apparently typed:
Felix Miata a écrit :
On 2008/01/04 15:57 (GMT+0100) jdd apparently typed:
there are no mor reason to make a separate folder for /boot (except may be on lvm systems).
Reasons remain, though necessity does not. As http://en.opensuse.org/Bugs/grub spells out, a HD0 primary partition for Grub to live on (which need not normally be mounted as /boot) is preferable to needing Grub in the MBR, while the location (primary or logical, HD0 or otherwise) generally makes no matter for / or any other native partition.
this -very interesting- page say that grub should stay on a primary marked bootable, no mention of /boot.
There are a bunch of implications of it making no mention. Any time you have multiboot, maximizing flexibility to recover from and avoid accidents is prudent. Keeping Grub on a primary, regardless what type or how many other partitions you have, is one way to do this. A Grub on primary partition need not normally be mounted, and indeed if not normally mounted, it remains quite safe against erring installation programs, erring upgrade utilities, and erring objects located between display and chair. The primary with Grub on it need not have any kernels or initrds on it, but certainly can.
and this is not the usual Linux way, so worth to mention
The usual Linux way (boot loader on MBR) is no less rude than the common windoz installation behavior Linux multibooters so often complain about - writing as and what it pleases to the MBR. When you use a Linux native primary partition, and put Grub on it, your potential windoz writing to MBR problem disappears. You might need to reset the active partition after a doz install, but there is no damage that can't be very easily fixed very quickly with any number of commonly available tools - including with doz' FDISK. -- "In the beginning was the Word, and the Word was with God, and the Word was God." John 1:1 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Felix Miata a écrit :
The usual Linux way (boot loader on MBR) is no less rude than the common windoz installation behavior
what is really new for me is than BIOS, with a said "standard" MBR can boot GRUB on the "*" primary. What I was mostly doing was to install grub on the /root partition of any of my Linux install and then on the MBR. Seems like this last step can be avoided jdd -- http://www.dodin.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
jdd a écrit :
Felix Miata a écrit :
The usual Linux way (boot loader on MBR) is no less rude than the common windoz installation behavior
what is really new for me is than BIOS, with a said "standard" MBR can boot GRUB on the "*" primary.
What I was mostly doing was to install grub on the /root partition of any of my Linux install and then on the MBR.
Seems like this last step can be avoided
jdd
it does I didn't verify YaST work (do it later), but I found the YaST write a mbr option, in the bootloader options (not obvious), set it to ext (all my linux are extended) and activate this partition as boot one and reboot. all went well... jdd -- http://www.dodin.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2008/01/04 20:55 (GMT+0100) jdd apparently typed:
what is really new for me is than BIOS, with a said "standard" MBR can boot GRUB on the "*" primary.
What I was mostly doing was to install grub on the /root partition of any of my Linux install and then on the MBR.
Seems like this last step can be avoided
In case it hasn't yet been made clear, installing Grub only on a / partition means / cannot be booted unless (in most cases) either 1-some boot loader elsewhere chainloads to it, or 2-some boot loader elsewhere loads a kernel & initrd and the cmdline points to /,or 3-/ is a HD0 primary partition marked active and the MBR contains standard code There are some other possibilities based upon motherboard BIOS redefining or selecting the HD0 device as something other than the first HD on the first controller, or bootable USB devices. -- "In the beginning was the Word, and the Word was with God, and the Word was God." John 1:1 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2008-01-04 at 20:55 +0100, jdd wrote:
what is really new for me is than BIOS, with a said "standard" MBR can boot GRUB on the "*" primary.
The standard, plain, mbr code will boot the partition marked bootable, whatever that one contains: be it windows, lilo, grub, etc. That's the reason that only one partition should be marked bootable. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHgghXtTMYHG2NR9URApczAKCJbMCT20rlfTRiMIZ1oOhwqZE4EQCeP9h/ 6WDMLc6M8AbL+o6ELohE/44= =lqUN -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Thanks everyone - you have given me a lot of information on this one. Dirk -----Original Message----- From: Dirk Moolman [mailto:DirkM@agilitytech.co.za] Sent: 04 January 2008 04:12 PM To: opensuse@opensuse.org Subject: [opensuse] /boot A quick question - we are just looking at one of our servers now, discussing space checks & what should be checked. In this case I have the following filesystems (on the root disk): Filesystem 1K-blocks Used Available Use% Mounted on /dev/cciss/c0d0p1 5246680 2455876 2790804 47% / tmpfs 4025588 12 4025576 1% /dev/shm /dev/cciss/c0d0p5 85624 39156 46468 46% /boot /dev/cciss/c0d0p6 5246680 500452 4746228 10% /home /dev/cciss/c0d0p11 48787112 38963856 9823256 80% /opt /dev/cciss/c0d0p7 5246680 1360004 3886676 26% /usr /dev/cciss/c0d0p8 2309172 413156 1896016 18% /var Question: what happens if /boot gets full (Use% = 100%) How will this affect the server ? Dirk *** Disclaimer *** The information contained in this e-mail is confidential and legally privileged and is intended solely for the addressee and to others who have the authority to receive it. Access to this e-mail by anyone else is unauthorized and as such, any disclosure, copying, distribution or any action taken or omitted in reliance on it is unlawful. If you have received this e-mail in error, please notify the sender immediately. The views expressed in this e-mail are the views of the individual sender and should in no way be construed as the views of the Company. The Company is not liable to ensure that outgoing e-mails are virus-free. The Company is not liable, should information or data, for whatever reason, be corrupted or fail to reach its intended addressee. The Company is not liable for any loss or damage of whatsoever nature and howsoever arising resulting from the opening or the use of the information in this e-mail, including its attachments and links. The sender of this e-mail is subject to and bound by the terms and conditions of Company’s Electronic Communications Usage Policy. -- To unsubscribe, e-mail: opensuse멻윫覷@opensuse.org For additional commands, e-mail: opensuse藩@opensuse.org *** Disclaimer *** The information contained in this e-mail is confidential and legally privileged and is intended solely for the addressee and to others who have the authority to receive it. Access to this e-mail by anyone else is unauthorized and as such, any disclosure, copying, distribution or any action taken or omitted in reliance on it is unlawful. If you have received this e-mail in error, please notify the sender immediately. The views expressed in this e-mail are the views of the individual sender and should in no way be construed as the views of the Company. The Company is not liable to ensure that outgoing e-mails are virus-free. The Company is not liable, should information or data, for whatever reason, be corrupted or fail to reach its intended addressee. The Company is not liable for any loss or damage of whatsoever nature and howsoever arising resulting from the opening or the use of the information in this e-mail, including its attachments and links. The sender of this e-mail is subject to and bound by the terms and conditions of Company’s Electronic Communications Usage Policy.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2008-01-04 at 14:38 +0100, Roger Oberholtzer wrote:
I get the following to stderr when running rpm -qa
error: rpmdbNextIterator: skipping h# 808 Header V3 DSA signature: BAD, key ID ddaf6454
and
error: rpmdbNextIterator: skipping h# 888 Header V3 DSA signature: BAD, key ID ddaf6454
I guess some packages were either signed odd, or something else has gone kaplooey. Any suggestions on (1) how to tell which packages this is for, and (2) how to possibly repair it? Although rpm seems to be working ok, this does not look like something to ignore.
You might try "--rebuilddb" :-? Perhaps "--verify". - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHggj7tTMYHG2NR9URAko2AKCC4lHkQYZtCTDH2QVhp1guqAm4lACeNhJS H2fxjZxZHMjBhq+5j/HVbYQ= =dCdF -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (9)
-
Anders Johansson -
Carlos E. R. -
Dirk Moolman -
Felix Miata -
James Knott -
jdd -
K.R. Foley -
Rasmus Plewe -
Roger Oberholtzer