Re: no more sudo on openbsd 5.8

[John Naggets]

Thanks to all for your feedback. I will definitely go for the option
of distributing my own site58.tgz with doas.conf. Sounds great!

On Fri, Aug 7, 2015 at 10:23 PM, Stuart Henderson  wrote:
> On 2015-08-07, John Naggets  wrote:
>> Hello,
>>
>> I just installed OpenBSD snapshot (5.8) through an automated install
>> and was surprise to login with my normal user and to find out that
>> there is no sudo command available. Is this normal?
>>
>> I have setup the autoinstall for no root password and only one user
>> account so I was wondering how do I run something as root now? Do I
>> really need to setup a root account from autoinstall?
>
> You'll need to change procedure. Here are a few alternatives:
>
> - setup a root password,
>
> - setup a root ssh key and permit root logins (e.g. "Allow root ssh =
> prohibit-password"),
>
> - provide a site58.tgz with a doas.conf(5) file that permits access
> for members of wheel.

ps: display command arguments

[Ingo Feinerer]

Hi,

when running

R --file=~/test.R --args -i -j -k

with R from math/R in ports and test.R as

commandArgs(TRUE)
Sys.sleep(10)

ps output displays

/usr/local/lib/R/bin/exec/R --file=/home/user/test.R --args --args --args --args

(Note the four --args.) However, R appears to have the right arguments
(the first --args is deliberately ignored by R):

R> commandArgs(TRUE)
[1] "-i" "-j" "-k"

Any ideas why the display of the arguments in ps differs from the
command line?

With a simple shell script I cannot reproduce this. E.g.,

./test.sh --args -i -j -k

with test.sh as

#!/bin/sh
echo $@
sleep 10

results in ps displaying

/bin/sh ./test.sh --args -i -j -k

Best regards,
Ingo

Re: radeondrm firmware archive problem?

[Eric Furman]

On Sun, Aug 9, 2015, at 01:42 PM, Theo de Raadt wrote:
> > > On Sat, Aug 08, 2015 at 10:59:15PM -0800, pstern wrote:
> > >> hello:
> > >>
> > >> I recently put a couple of Dell optiplex 7010 machiens in operation using
> > >> OpenBSD 5.6 and 5.7. Both machines have a radeon card in them.
> > >>
> > >> vga1 at pci1 dev 0 function 0 "ATI Radeon HD 7470" rev 0x00
> > >>
> > >> I ran into the video going to gray screen during the boot process when it
> > >> tried to switch to high res. I disabled the radeondrm temporarily to get 
> > >> the
> > >> machines to boot.
> > >>
> > >> I found the radeondrm-firmware-20131002p2.tgz at firmware.openbsd.org
> > >>
> > >> Trying to use pkd_add would not work because it kept reporting the 
> > >> archive
> > >> was corrupt. I believe the problem was actually the signature in the 
> > >> archive
> > >> wasn't current and could not be validated against the certificates in
> > >> /etc/ssl or /etc/signify.
> > > Nope. it's that it's signed with the firmware keys... which is why you
> > > install firmwares with fw_update and not pkg_add.
> > >
> > >> I ended up manually loading the firmware in /etc/firmware, which 
> > >> resulted in
> > >> bypassing verifying the archive, but the archive expanded without a 
> > >> problem.
> > >> The machines run fine with the contents of that archive in place.
> > >
> > >> Is there something wrong with that archive?
> > > The fact that it looks like a normal package doesn't mean it's a normal
> > > package. Since you expanded it manually, you can look at the @signer line
> > > in the contents. You'll see the signature name in all its glories.
> > >
> > > The design of signify means it's the *commands* that decide which 
> > > signatures
> > > they trust. There are three classes of keys in openbsd. Trying to verify
> > > a fw-signed archive with a pkg-checking command won't work.
> > >
> > 
> > I saw that pkg_add is discouraged at the bottom of the man page for 
> > fw_update.
> > 
> > Trying local update
> > 
> > # ls -la /etc/firmware/*.tgz
> > -rw-r--r--  1 root  wheel  1224091 Aug  8 15:08 
> > /etc/firmware/radeondrm-firmware-20131002p0.tgz
> > # fw_update -n -v -p /etc/firmware/radeondrm-firmware-20131002p0.tgz
> > fw_update: Path to firmware: /etc/firmware/radeondrm-firmware-20131002p0.tgz
> > fw_update: Installing firmware:  
> > radeondrm-firmware.file:/etc/firmware/radeondrm-firmware-20131002p0.tgz/ is 
> > empty
> > Can't find radeondrm-firmware
> > 
> > trying directly from firmware.openbsd.org
> > 
> > fw_upate -n -v -p 
> > http://firmware.openbsd.org/firmware/5.7/radeondrm-firmware-20131002p0.tgz
> > 
> > fw_update: Path to firmware: 
> > http://firmware.openbsd.org/firmware/5.6/radeondrm-firmware-20131002p0.tgz
> > fw_update: Installing firmware:  radeondrm-firmware.
> > Error from 
> > http://firmware.openbsd.org/firmware/5.7/radeondrm-firmware-20131002p0.tgz/
> > ftp: Error retrieving file: 404 Not Found
> > http://firmware.openbsd.org/firmware/5.7/radeondrm-firmware-20131002p0.tgz/ 
> > is empty
> > Can't find radeondrm-firmware
> > 
> > What is the correct way to deal with this file?
> 
> Just Wow.  The right way to use it is
> 
> # fw_update
> 
> That's it, you don't need any specific options, nor do you have to
> give it URLs to files.  It autodiscovers.
> 
> For some firmwares, you need to follow this with a reboot so that the
> kernel can find the actual firmwares early enough in boot.
> 
> You really are inventing your own difficulties.  Sometimes you have to
> step back and go "Wow, I am passing 5 arguments to the program.  Is that
> what the system developers would have intended as normal operation?"
> 
> The answer is NO.
> 

Linux trains people that kind of shit is normal.

Re: Repartitioning

[Mihai Popescu]

>And I present you my analysis and suggestions (minus words):
>

I wonder, is it for 4.9 relic, 5.8 or maybe it works on -current, too?
It seems to me this is too GENERIC.

(I had a good laugh, I remember something like this in the past on
misc, maybe I will search for it. I think it was for someone refusing
to post dmesg.)

Re: Is lack of a prompt in shell after building the kernel bad news?

[Mihai Popescu]

> The guy says "Sorry for the noise",

Well, I never got that far reading his post. Did I upset your friend,
Mr. Wanna-Fix-Anything-with-Method?
Let's drop it, please. Maybe I got too harsh because I have read some
untrue things.

Re: Is lack of a prompt in shell after building the kernel bad news?

[Steve Litt]

On Sun, 9 Aug 2015 22:13:36 +0300
Mihai Popescu  wrote:

> Joel, what the hell are you doing? Answering your own email and
> quoting your own words. For what purpose?
> Somebody told you that what you have is OUT OF SYNC, and gave you some
> clear instructions to fix this?
> 
> What are you doing? Continue with the old out of sync bulshit trying
> and hope you will fix it? Did you get it, the source is out of sync. I
> never used cvs and own compile, but i got this very clear: IT WILL NOT
> WORK if it is OUT OF SYNC.
> 

Now that's real class, Mihai. The guy says "Sorry for the noise",
ceases posting into the thread, and then you go into rant mode against
him?

SteveT

Re: Is lack of a prompt in shell after building the kernel bad news?

[Mihai Popescu]

Joel, what the hell are you doing? Answering your own email and
quoting your own words. For what purpose?
Somebody told you that what you have is OUT OF SYNC, and gave you some
clear instructions to fix this?

What are you doing? Continue with the old out of sync bulshit trying
and hope you will fix it? Did you get it, the source is out of sync. I
never used cvs and own compile, but i got this very clear: IT WILL NOT
WORK if it is OUT OF SYNC.

Re: radeondrm firmware archive problem?

[Philip Guenther]

On Sun, Aug 9, 2015 at 10:38 AM, pstern  wrote:
...
> I saw that pkg_add is discouraged at the bottom of the man page for
> fw_update.
>
> Trying local update
>
> # ls -la /etc/firmware/*.tgz
> -rw-r--r--  1 root  wheel  1224091 Aug  8 15:08
> /etc/firmware/radeondrm-firmware-20131002p0.tgz
> # fw_update -n -v -p /etc/firmware/radeondrm-firmware-20131002p0.tgz

 -p path
 Use the firmware found at path, being either a local directory or
 a URL, instead of the default location.

You gave it the path to the file, not the path to the directory where
it should look for firmware packages.  Also, putting the package file
in /etc/fireware/ is just confusing; move it elsewhere and add it from
that directory:

   # mv /etc/firmware/radeondrm-firmware-20131002p0.tgz /root
   # fw_update -n -v /root


Philip Guenther

Re: radeondrm firmware archive problem?

[Theo de Raadt]

> > On Sat, Aug 08, 2015 at 10:59:15PM -0800, pstern wrote:
> >> hello:
> >>
> >> I recently put a couple of Dell optiplex 7010 machiens in operation using
> >> OpenBSD 5.6 and 5.7. Both machines have a radeon card in them.
> >>
> >> vga1 at pci1 dev 0 function 0 "ATI Radeon HD 7470" rev 0x00
> >>
> >> I ran into the video going to gray screen during the boot process when it
> >> tried to switch to high res. I disabled the radeondrm temporarily to get 
> >> the
> >> machines to boot.
> >>
> >> I found the radeondrm-firmware-20131002p2.tgz at firmware.openbsd.org
> >>
> >> Trying to use pkd_add would not work because it kept reporting the archive
> >> was corrupt. I believe the problem was actually the signature in the 
> >> archive
> >> wasn't current and could not be validated against the certificates in
> >> /etc/ssl or /etc/signify.
> > Nope. it's that it's signed with the firmware keys... which is why you
> > install firmwares with fw_update and not pkg_add.
> >
> >> I ended up manually loading the firmware in /etc/firmware, which resulted 
> >> in
> >> bypassing verifying the archive, but the archive expanded without a 
> >> problem.
> >> The machines run fine with the contents of that archive in place.
> >
> >> Is there something wrong with that archive?
> > The fact that it looks like a normal package doesn't mean it's a normal
> > package. Since you expanded it manually, you can look at the @signer line
> > in the contents. You'll see the signature name in all its glories.
> >
> > The design of signify means it's the *commands* that decide which signatures
> > they trust. There are three classes of keys in openbsd. Trying to verify
> > a fw-signed archive with a pkg-checking command won't work.
> >
> 
> I saw that pkg_add is discouraged at the bottom of the man page for 
> fw_update.
> 
> Trying local update
> 
> # ls -la /etc/firmware/*.tgz
> -rw-r--r--  1 root  wheel  1224091 Aug  8 15:08 
> /etc/firmware/radeondrm-firmware-20131002p0.tgz
> # fw_update -n -v -p /etc/firmware/radeondrm-firmware-20131002p0.tgz
> fw_update: Path to firmware: /etc/firmware/radeondrm-firmware-20131002p0.tgz
> fw_update: Installing firmware:  
> radeondrm-firmware.file:/etc/firmware/radeondrm-firmware-20131002p0.tgz/ is 
> empty
> Can't find radeondrm-firmware
> 
> trying directly from firmware.openbsd.org
> 
> fw_upate -n -v -p 
> http://firmware.openbsd.org/firmware/5.7/radeondrm-firmware-20131002p0.tgz
> 
> fw_update: Path to firmware: 
> http://firmware.openbsd.org/firmware/5.6/radeondrm-firmware-20131002p0.tgz
> fw_update: Installing firmware:  radeondrm-firmware.
> Error from 
> http://firmware.openbsd.org/firmware/5.7/radeondrm-firmware-20131002p0.tgz/
> ftp: Error retrieving file: 404 Not Found
> http://firmware.openbsd.org/firmware/5.7/radeondrm-firmware-20131002p0.tgz/ 
> is empty
> Can't find radeondrm-firmware
> 
> What is the correct way to deal with this file?

Just Wow.  The right way to use it is

# fw_update

That's it, you don't need any specific options, nor do you have to
give it URLs to files.  It autodiscovers.

For some firmwares, you need to follow this with a reboot so that the
kernel can find the actual firmwares early enough in boot.

You really are inventing your own difficulties.  Sometimes you have to
step back and go "Wow, I am passing 5 arguments to the program.  Is that
what the system developers would have intended as normal operation?"

The answer is NO.

Re: radeondrm firmware archive problem?

[pstern]

On Sun, 9 Aug 2015, Marc Espie wrote:


On Sat, Aug 08, 2015 at 10:59:15PM -0800, pstern wrote:

hello:

I recently put a couple of Dell optiplex 7010 machiens in operation using
OpenBSD 5.6 and 5.7. Both machines have a radeon card in them.

vga1 at pci1 dev 0 function 0 "ATI Radeon HD 7470" rev 0x00

I ran into the video going to gray screen during the boot process when it
tried to switch to high res. I disabled the radeondrm temporarily to get the
machines to boot.

I found the radeondrm-firmware-20131002p2.tgz at firmware.openbsd.org

Trying to use pkd_add would not work because it kept reporting the archive
was corrupt. I believe the problem was actually the signature in the archive
wasn't current and could not be validated against the certificates in
/etc/ssl or /etc/signify.

Nope. it's that it's signed with the firmware keys... which is why you
install firmwares with fw_update and not pkg_add.


I ended up manually loading the firmware in /etc/firmware, which resulted in
bypassing verifying the archive, but the archive expanded without a problem.
The machines run fine with the contents of that archive in place.



Is there something wrong with that archive?

The fact that it looks like a normal package doesn't mean it's a normal
package. Since you expanded it manually, you can look at the @signer line
in the contents. You'll see the signature name in all its glories.

The design of signify means it's the *commands* that decide which signatures
they trust. There are three classes of keys in openbsd. Trying to verify
a fw-signed archive with a pkg-checking command won't work.



I saw that pkg_add is discouraged at the bottom of the man page for 
fw_update.


Trying local update

# ls -la /etc/firmware/*.tgz
-rw-r--r--  1 root  wheel  1224091 Aug  8 15:08 
/etc/firmware/radeondrm-firmware-20131002p0.tgz
# fw_update -n -v -p /etc/firmware/radeondrm-firmware-20131002p0.tgz
fw_update: Path to firmware: /etc/firmware/radeondrm-firmware-20131002p0.tgz
fw_update: Installing firmware:  
radeondrm-firmware.file:/etc/firmware/radeondrm-firmware-20131002p0.tgz/ is 
empty
Can't find radeondrm-firmware

trying directly from firmware.openbsd.org

fw_upate -n -v -p 
http://firmware.openbsd.org/firmware/5.7/radeondrm-firmware-20131002p0.tgz

fw_update: Path to firmware: 
http://firmware.openbsd.org/firmware/5.6/radeondrm-firmware-20131002p0.tgz
fw_update: Installing firmware:  radeondrm-firmware.
Error from 
http://firmware.openbsd.org/firmware/5.7/radeondrm-firmware-20131002p0.tgz/
ftp: Error retrieving file: 404 Not Found
http://firmware.openbsd.org/firmware/5.7/radeondrm-firmware-20131002p0.tgz/ is 
empty
Can't find radeondrm-firmware

What is the correct way to deal with this file?

Thank you

Re: cu connection trap "crash"

[Dan Becker]

On Sat, Aug 8, 2015 at 9:20 PM, Philip Guenther  wrote:

> On Sat, Aug 8, 2015 at 3:36 PM, Dan Becker  wrote:
> >> On Saturday, August 8, 2015, Dan Becker  wrote:
> >>>
> >>> When connecting to a serial port with a usb to serial adapter.
> Unplugging
> >>> the usb connection without closing the session causes my system to drop
> >>> to ddb.
> ...
> > $ cat /var/run/dmesg.boot
> > OpenBSD 5.7 (GENERIC.MP) #881: Sun Mar  8 11:04:17 MDT 2015
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> I'm 98% certain that this was fixed in April or so, and thus fixed in
> -current and will be fixed in 5.8.
>
> If not, well, it's now too late to debug and fix it before 5.8 is
> frozen.  So, you should upgrade to 5.8 soon after it comes out and
> verify whether this is resolved there.  If not, report it again then,
> with fresh dmesg and backtrace, so that it can be addressed when
> there's time in the 5.9 cycle...
>
>
> Philip Guenther
>


Will do.

-- 
--Dan

mouse Slow motion on GIMP

[Mohammad BadieZadegan]

Hi every body,
I have an issue on my GIMP.
When I open a photo image by GIMP then my mouse sign is very slow on that
photo when I move mouse on that photo!
How can I resolve this mouse slow motion?

-- 
[image: ( openbsd.pro  933k.ir )] 

Re: SNMP on 5.7/5.8

[Bret Lambert]

On Sat, Aug 08, 2015 at 08:47:21PM +0300, Kapetanakis Giannis wrote:
> sorry for top post.
> 
> I believe I had the problem with both base and netsnmpd versions.

"Believe" and "have verified that" are two functionally different
statements. I've only seen evidence that netsnmp, not snmpd from
OpenBSD base, has this issue.

Those who have reported the issue with netsnmp are encouraged to
report that to the netsnmp project in order to hopefully receive
a timely response.

If someone can replicate the issue with software included in the
base OpenBSD distribution, please do so.

> 
> On 06/08/15 00:33, Steven Surdock wrote:
> >Thanks Stuart.  It is also my understanding that the base snmpd suffers the 
> >same issue.
> >
> >http://marc.info/?l=openbsd-misc&m=143143933919367&w=2
> >
> >I will try the debug shortly.
> >
> >-Steve S.
> >
> >>-Original Message-
> >>From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
> >>Stuart Henderson
> >>Sent: Wednesday, August 5, 2015 5:58 AM
> >>To: misc@openbsd.org
> >>Subject: Re: SNMP on 5.7/5.8
> >>
> >>On 2015-08-04, Steven Surdock  wrote:
> >>>The broken SNMP on i386/5.7 is preventing me from upgrading.  I tried
> >>i386/5.8 but I'm still seeing net-snmpd crash with the following error.
> >>>NET-SNMP version 5.7.3
> >>>Error expanding HCInReceives to 64bits in ipSystemStatsTable.ipv4
> >>>Error expanding HCInDelivers to 64bits in ipSystemStatsTable.ipv4
> >>>Error expanding HCOutRequests to 64bits in ipSystemStatsTable.ipv4
> >>Oh, I wasn't aware of this, if a port is broken on some arch please let
> >>the maintainer know rather than hope they notice a report on misc@...
> >>
> >>Can you get output with debugging enabled for "c64"? Should be something
> >>like snmpd -Dc64 -f -Le
> >>
> >>Do you particularly need something from Net-SNMP or could you use snmpd
> >>from base instead? If it does what you need, the latter is always
> >>preferable.
> >>
> >>>Is amd64 the new i386?
> >>yes.
> >>
> >>>Would my energy be best spent migrating my default install to amd64?
> >>Thanks.
> >>
> >>that's up to you to decide :)

mouse Slow motion on GIMP

[Mohammad BadieZadegan]

Hi every body,
I have an issue on my GIMP.
When I open a photo image by GIMP then my mouse sign is very slow on that
photo when I move mouse on that photo!
How can I resolve this mouse slow motion?

-- 
[image: ( openbsd.pro  933k.ir )] 

Re: Repartitioning

[Alexander Hall]

On August 9, 2015 2:24:53 AM GMT+02:00, Quartz  wrote:

>That WAS the disklabel output (minus sizes and offsets).

And I present you my analysis and suggestions (minus words):

Re: radeondrm firmware archive problem?

[Marc Espie]

On Sat, Aug 08, 2015 at 10:59:15PM -0800, pstern wrote:
> hello:
> 
> I recently put a couple of Dell optiplex 7010 machiens in operation using
> OpenBSD 5.6 and 5.7. Both machines have a radeon card in them.
> 
> vga1 at pci1 dev 0 function 0 "ATI Radeon HD 7470" rev 0x00
> 
> I ran into the video going to gray screen during the boot process when it
> tried to switch to high res. I disabled the radeondrm temporarily to get the
> machines to boot.
> 
> I found the radeondrm-firmware-20131002p2.tgz at firmware.openbsd.org
> 
> Trying to use pkd_add would not work because it kept reporting the archive
> was corrupt. I believe the problem was actually the signature in the archive
> wasn't current and could not be validated against the certificates in
> /etc/ssl or /etc/signify.
Nope. it's that it's signed with the firmware keys... which is why you
install firmwares with fw_update and not pkg_add.

> I ended up manually loading the firmware in /etc/firmware, which resulted in
> bypassing verifying the archive, but the archive expanded without a problem.
> The machines run fine with the contents of that archive in place.

> Is there something wrong with that archive?
The fact that it looks like a normal package doesn't mean it's a normal
package. Since you expanded it manually, you can look at the @signer line
in the contents. You'll see the signature name in all its glories.

The design of signify means it's the *commands* that decide which signatures
they trust. There are three classes of keys in openbsd. Trying to verify
a fw-signed archive with a pkg-checking command won't work.

mouse Slow motion on GIMP

[Mohammad BadieZadegan]

Hi every body,
I have an issue on my GIMP.
When I open a photo image by GIMP then my mouse sign is very slow on that
photo when I move mouse on that photo!
How can I resolve this mouse slow motion?

-- 
[image: ( openbsd.pro  933k.ir )] 

mouse Slow motion on GIMP

[Mohammad BadieZadegan]

Hi every body,
I have an issue on my GIMP.
When I open a photo image by GIMP then my mouse sign is very slow on that
photo when I move mouse on that photo!
How can I resolve this mouse slow motion?

-- 
[image: ( openbsd.pro  933k.ir )] 

Re: Repartitioning

[Josh Grosse]

On Sun, Aug 09, 2015 at 12:10:38AM -0400, Quartz wrote:
> Also, another question: this system keeps nothing in the user's home
> directories past a few dot files. /home is using less than 1m of space.
> Would it be safe from a security/reliability standpoint to just move the
> home folders directly into / ?
 
If you aren't using /home, you can eliminate the partition, rolling it
into the root partition. 

There are implications, yes.  One of the reasons for partitioning is for
governance of security.  And /home is normally mounted with two mount
options that restrict its use:  "nodev" and "nosuid."  These security
restrictions would be eliminated if /home were located in the root 
partition.  Whether this is a problem for your use-case will depend
on who has a userid located in /home, and what authority and trust
they are intended to have.

Re: Repartitioning

[Josh Grosse]

On Sun, Aug 09, 2015 at 12:01:30AM -0400, Quartz wrote:
> >The disklabel(8) tool is used to delete and create partitions.
> 
> So part of the reason I started this thread is that I want to be clear since
> OpenBSD has two different kinds of "partitions". For what I'm doing, on an
> i386 platform, I don't need to mess with fdisk at all... Is that correct?

Correct.  On the half-dozen architectures which use MBRs, they're for boot
procedures and/or define the sectors where the OS may scribble on the drive.
For the dozen or so other architectures, they're not used at all.
 
> growfs is like other partition expanders in that can only expand "forward"
> and not "backward", right? As in, I couldn't nuke src and obj and then use
> growfs to expand home into that space.

Correct.

> Assuming that's right, I'm probably going to make a new /var partition
> rather than expand an existing one.

Recall one of my examples: deleting the partitions for /usr/obj and /usr/src,
replacing those 2GB with a new /var partition.

> >The best practice for
> >moving of FFS filesystems is through the use of dump(8)/restore(8).
> 
> I'm not sure that's what I want to be doing in my case. Especially when
> collapsing the /usr/* stuff down into just /usr, a simple cp or tar would be
> better, no?

I recommend dump/restore because it eliminates problems with linked files
and eliminates problems with file path byte length.  You may have trouble
with both, using other methods. The result will be files that are not 
copied, and links that are broken. 

Don't fear dump/restore.  They're easy to use.  Here's a quick "howto", 
though the man pages should be reviewed.  Never blindly copy/paste 
instructions you read from me -- especially when they are from memory,
as in this example.

1. Mount a freshly formatted partition.  
2. cd to the mount point.
3. Dump the old partition, piping the output to restore.  The old partition
   does not need to be mounted.  Assuming the contents of partition "f" of 
   drive "sd0" is to be moved to the working directory:

   # dump -0af - /dev/sd0f | restore -rf -

4. Since you aren't using incremental dumps, you can then delete the
   "restoresymtable" file created by restore(8).

5. Edit your fstab(5) to point to the new partition.

Re: how to know uuid

[Patrik Lundin]

On Sun, Aug 09, 2015 at 03:52:38PM +0900, joe king wrote:
> linux has blkid .
> in openbsd , what is its substitute  ?
> 

You can use disklabel(8):
===
# disklabel sd0 | grep duid
===

-- 
Patrik Lundin

radeondrm firmware archive problem?

[pstern]

hello:

I recently put a couple of Dell optiplex 7010 machiens in operation using 
OpenBSD 5.6 and 5.7. Both machines have a radeon card in them.


vga1 at pci1 dev 0 function 0 "ATI Radeon HD 7470" rev 0x00

I ran into the video going to gray screen during the boot process when it 
tried to switch to high res. I disabled the radeondrm temporarily to get 
the machines to boot.


I found the radeondrm-firmware-20131002p2.tgz at firmware.openbsd.org

Trying to use pkd_add would not work because it kept reporting the archive 
was corrupt. I believe the problem was actually the signature in the 
archive wasn't current and could not be validated against the certificates 
in /etc/ssl or /etc/signify.


I ended up manually loading the firmware in /etc/firmware, which resulted 
in bypassing verifying the archive, but the archive expanded without a 
problem. The machines run fine with the contents of that archive in 
place.


Is there something wrong with that archive?

peter