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.
