ChromeOS logs display alternative facts |
||||
Issue descriptionChrome Version: <From about:version: Google Chrome 55.0.2883.103> Chrome OS Version: <From about:version: Platform "Indy"> Chrome OS Platform: "Chrome OS" sp="8872.73.0_armv7l" <b>Network info: <network, encryption type, router model (if known)></b> Please specify Cr-* of the system to which this bug/feature applies (add the label below). Some log files in ChromeOS are recording errors, which upon presenting to developers are told to be not errors and so, can be ignored. I think, if in code it is treated as an error - then it should be accordingly treated and so, fixed as a bug. Otherwise, code should be revised and do not throw errors to the log files. one of the examples is below. I was told by developer that it is not actually an error: https://bugs.chromium.org/p/chromium/issues/detail?id=679426 "The error you in the dev_debug_vboot log is it deciding that the kernel on your disk is a normal kernel (where verification succeeds), not a recovery kernel (because it doesn't verify with the recovery key). Your shutdown problem has nothing to do with verified boot or its use of the TPM. Problems there *would stop your system from booting*. And verified boot *only runs at boot*, so it can't cause a shutdown afterwards." # TPM=0x00020001 this=0x00020001 # Verify /dev/mmcblk0p4 with recoverykey.vbpubk: + futility vbutil_kernel --verify kern_1 --signpubkey recoverykey.vbpubk Error verifying key block. # FAILED # copying /dev/mmcblk0p6 to kern_2... + dd if=/dev/mmcblk0p6 of=kern_2 1+0 records in 1+0 records out 512 bytes (512 B) copied, 0.000755334 s, 678 kB/s # Kernel /dev/mmcblk0p6: + futility vbutil_keyblock --unpack kern_2 Invalid key block file: kern_2 vbutil_keyblock: Error reading key block. # FAILED + od -Ax -tx1 kern_2 | head 000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 000200 Steps To Reproduce: (1) create tgz file on the chromebook (2) cat debug_vboot_noisy.log (and some other logs) (3) observe the message above Expected Result: logs should provide correct and truthful information, as it is a source of information tech support relies on. Actual Result: logs are providing alternative facts. How frequently does this problem reproduce? (Always, sometimes, hard to reproduce?) always What is the impact to the user, and is there a workaround? If so, what is it? it is very difficult sometimes to find out the root cause of the problem as it is unclear how to judge information in the log files Please provide any additional information below. Attach a screen shot or log if possible. For graphics-related bugs, please copy/paste the contents of the about:gpu page at the end of this report.
,
Feb 23 2017
Reporter: if you are suggesting that the log should be clearer about the consequences of this error, I agree and sympathize with you. Unfortunately we don't have strict logging standards for this situations, and it is common that some layer of code reports errors that can be safely ignored by the layer above. These bugs tend to get low priority. Randall, can/should this message be improved? Is this the right component? Thanks!
,
Feb 24 2017
It sounds like what you're looking for is a utility targeted at the tech support use case which will verify that the system would boot as intended (returns success), or provide a specific error report otherwise. The problem is really that this is a shell script calling a tool, rather than a monolithic test program. And it was written for us developers, not as a tool for tech support. (That's why it's called dev_debug_vboot.) So it does something like: - Execute futility to try verifying the kernel with recovery key - Execute futility to try verifying the kernel with the key from RW firmware A - Execute futility to try verifying the kernel with the key from RW firmware B At least one of those will fail. Depending on what you're trying to do, hopefully one succeeds. But which one succeeds depends on what you're trying to do. And it's possible to see a success which is not helpful for what you're trying to do. That is, if you're trying to boot from firmware B, but the kernel only verifies with firmware A, that's an error to you. But if you were trying to boot from firmware A, it's just fine. And without more input parameters, the script doesn't know what you're trying to do. On top of that, what you're looking at is the noisy log, which one would expect to have lots of extraneous information (it's like running anything else with --debug). It's a problem akin to grepping one of our Chrome OS builds logs for 'error' (hint: be prepared for scrolling, even if the build succeeded). It might be possible to write a tool which would examine the system and make its best guess if things are working as intended. Or to extend dev_debug_vboot with a --concise option which would do that. I'd be happy to code review that change.
,
Mar 31 2017
,
Apr 3 2018
semenzato@ Is this something you can take a look at? |
||||
►
Sign in to add a comment |
||||
Comment 1 by ketakid@google.com
, Feb 23 2017