Firmware #1360
Firmware #1360
Conversation
Now that there are automated, consistent builds from https://github.com/ubicloud/build-edk2-firmware, it's time to begin formalizing and backporting their use to the entire service. `download-firmware` can be run independent of preparing an entire host to download this firmware.
Including architecture name is redundant: consider how we do not write `/usr/bin/ls-arm64`, and we have no use cases for architecture emulation such that an x64 binary on an arm64 system would ever help. ...nevertheless, it might help avoid severe mistakes from time to time where some Arch conditional branches are mishandled, and the wrong architecture's binary is loaded (and then crashes with illegal instructions). The tighter coupling to arch & version name together might give us a chance to notice program error first. It could be considered a low cost, and low benefit, measure.
| @@ -65,7 +65,7 @@ else | |||
| command = "#{command} < #{dir}/var/proc/#{name}.stdin" | |||
| end | |||
|
|
|||
| command = "/bin/bash -c '#{command} > #{dir}/var/log/#{name}.stdout 2> #{dir}/var/log/#{name}.stderr'" | |||
| command = "/bin/bash -c '#{command}'" | |||
There was a problem hiding this comment.
On balance, I find the journal more useful than the /var/log files that get truncated and overwritten with the latest output all the time. I was debugging something at the time. Though, I could see a combined system that retained the first invocation's stdout/stderr this way, perhaps the last one, and spooled the rest to journal. But journalctl is likely enough.
|
This is/was a prototype I was working on. the reason it's phased so oddly in the commits is to be able to two-phase the introduction of new directory structure for firmware and cloud-hypervisor binaries: in general, I think we should drop architectures from paths, much as |
No description provided.