| Age | Commit message (Collapse) | Author |
|---|
|
While not verbose the status line is built as we go, so save errors from
signify until after we've finished the status line. This should exit and print
the error immediately, since this happens when fetching the SHA256.sig and
fw_update exits early in that case.
|
|
OpenBSD::PackageInfo::lock_db will send messages to STDERR if we ended up
waiting for a lock, if that happens, it stomped over the "fw_update:" prefix on
the status line so tidy up and print it out again.
|
|
Trap STDERR to post-process it looking for 404 errors to handle them differently.
The fetch method now also returns different error codes for errors that can
continue on. Currently only 404 is special and everything else should cause
fw_update to exit early without trying all the files.
Exit early if the SHA256.sig gets a 404 because that is required to figure out
what valid firmware are.
|
|
Mostly some setup for the future, by separating out the filehandles we use for
the status and errors more specifically, we can trap the things we know about
without hiding surprises.
|
|
Signify is happy to overwite the file with the signature stripped off.
However, if we do that, when downloading firmware we lose the ability
to check the signature before verifying checksums on the downloaded files.
Noticed by Thomas <exnihilo () fastmail ! org>
Right deraadt@
|
|
If installing firmware with `make install` from a port, it doesn't register
properly by adding "@option firmware" to the packing list, this means we ignore
that it is installed and reinstall it over and over with the registration
ending up in a tmpdir named directory inside the existing directory in
/var/db/pkg.
Unfortunately I don't know of a good way to automatically clean up from that,
so we just print a message after installing the actual firmware.
Reported by job@
No complaints about the patch on tech@ for several weeks.
|
|
Otherwise the exit status depends on whether we kept any firmware.
Reported by Brian Conway <bconway () rcesoftware ! com>
The clean solution suggested by guenther@
|
|
Previously if you did: fw_update otus-firmware-1.0p1.tgz
and that firmware didn't exist in the current directory,
we would download that firmware into the current directory.
Which is not the expected outcome.
|
|
|
|
If fw_update exits unexpectedly the package database would never unlock.
select solution from millert@
|
|
Show status as we go with spinner rather than printing only at the end.
Suggestions from deraadt@
Most of this has been in snapshots for a while
|
|
ok deraadt@
|
|
ok kettenis@
|
|
Intel(R) does not appear in
cpu0: Intel Atom(R) x6425RE Processor @ 1.90GHz, 1895.90 MHz, 06-96-01
reported by patrick@ ok deraadt@
|
|
For recent devices amdgpu matches via the hardware ip discovery table,
not with a table of pci vendor and product ids.
So amdgpu_devlist.h and pcidevs do not cover all devices that amdgpu
may match.
in dmesg amdgpu with an unknown product takes the form:
ramdisk kernel, bios/mbr:
vga1 at pci12 dev 0 function 0 vendor "ATI", unknown product 0x687f rev 0xc3
ramdisk kernel, efi or non-x86 arch:
vendor "ATI", unknown product 0x687f (class display subclass VGA, rev 0x03) at pci12 dev 0 function 0 not configured
non-ramdisk kernel:
amdgpu0 at pci12 dev 0 function 0 vendor "ATI", unknown product 0x687f rev 0xc3
ok deraadt@ on an earlier version
|
|
From Rob Whitlock <rwhitlock22 () gmail ! com>
|
|
ok phessler@ sthen@ tobhe@
|
|
The pattern matches the printed CPU_IMPL_APPLE name as in:
cpu0 at mainbus0 mpidr 0: Apple Icestorm Pro r2p0
cpu0 at mainbus0 mpidr 0: Apple Blizzard r1p0
ok deraadt@ afresh@ kettenis@
|
|
Intel CPUs mostly used to have processor name strings of the form
cpu0: Intel(R) Pentium(R) M processor 1.60GHz ("GenuineIntel" 686-class) 1.60 GHz, 06-0d-06
cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.61 MHz, 06-3d-04
recent CPUs use
cpu0: 11th Gen Intel(R) Core(TM) i5-1130G7 @ 1.10GHz, 30009.37 MHz, 06-8c-01
cpu0: 12th Gen Intel(R) Core(TM) i5-12400, 4390.71 MHz, 06-97-02
cpu0: 12th Gen Intel(R) Core(TM) i7-1260P, 1995.55 MHz, 06-9a-03
change pattern used to handle this
also covers oddities such as
cpu0: Genuine Intel(R) CPU @ 600MHz, 600.10 MHz
cpu0: Genuine Intel(R) CPU @ 1.00GHz, 1000.13 MHz, 06-26-01
cpu0: Genuine Intel(R) CPU L2400 @ 1.66GHz ("GenuineIntel" 686-class) 1.67 GHz, 06-0e-08
test chips use "Genuine Intel(R) CPU 0000"
|
|
Up to two wildcards, since we have to work around the way ksh does things.
Tweaks and suggestions from kn@ and halex@
|
|
ok jsg@
|
|
ok afresh1@
|
|
Not during release, -stable, or -beta.
This diverges from how packages work and how things were done in the past
where -beta also looked in /snapshots.
Discussed in icb.
OK deraadt@
|
|
Without the "noclobber" setting we would have overwitten with an empty
file and best not to leave a failed file around.
Noticed by florian@
|
|
OK florian@
|
|
All base tools should be doing that and I forgot.
While here remove the no longer necessary TERM handler,
it was only needed so a TERM signal would still trigger the END block.
|
|
okay afresh1@
|
|
At least when not running in the installer.
Suggestions from espie@
Works for me sthen@
fine deraadt@
|
|
Also avoid trying to download it multiple times if it fails,
which makes error reporting much nicer.
Noticed by and OK semarie@
|
|
Somehow I missed some
|
|
Being different didn't help me figure out what was going wrong anyway.
Suggested by deraadt@
|
|
|
|
We assume in this case that the firmware's license was improved and
it moved to be distributed in the base system. If we find that situation
remove the package registration but leave the firmware files.
|
|
|
|
There are now four levels of verbosity:
0. Prints only the summary
1. Prints a line when installing/removing
2. Uses the ftp(1) progress bar
3. Provides more details for debugging
With some excellent ksh knowledge provided by kn@
|
|
Plus improving usage to match the man page
fine deraadt@
|
|
requested by deraadt@
|
|
This allows installing local files without network.
it *might* work now deraadt@
|
|
|
|
|
|
The perl version of fw_update used -D for something else and although
the mneumonic isn't as good, the conflict was worse.
Requested by deraadt@
|
|
checked out anywhere.
While here, tidy up the Makefile a bit.
ok deraadt@
|
|
Sigh.
|
|
This allows installing firmware from the installer without having
to wait to boot into a live system.
commit deraadt@
|
|
way that the install script can also run it. This allows earlier retrieval
of downloaded firmwares, based upon patterns found in dmesg.
many iterations of this in snaps for about a month.
|
|
friends. So long and thanks for all the fish.
ok deraadt@
|
|
firmware packages
- reword 'firmware files' to 'firmware'
- pick some style and whitespace nits
ok deraadt@
|
|
the upcoming -p <path> flag
|
|
some firmware retrieval issues I discovered.
ok espie halex
|
|
|
