> > 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.
