Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upqubes-dom0-update Fails with Curl Error (3) [bad/illegal character] #4090
Comments
claytoncarmineisahero
changed the title from
qubes-dom0-update Failes with Curl Error (3) [bad/illegal character]
to
qubes-dom0-update Fails with Curl Error (3) [bad/illegal character]
Jul 16, 2018
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
What do you have as updatevm? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
claytoncarmineisahero
commented
Jul 16, 2018
|
At this moment, updatevm is configured to be sys-firewall. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Try changing |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
claytoncarmineisahero
Jul 16, 2018
That seems to have resolved the curl error issue. However, the qubes-dom0-update script now hangs indefinitely after downloading the necessary packages. Here's a snippet of the tail end of the output:
[..snip..]
Complete!
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
[..hangs..]
claytoncarmineisahero
commented
Jul 16, 2018
|
That seems to have resolved the curl error issue. However, the |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Jul 16, 2018
Member
How long have you waited? Do you see any dom0 CPU activity (top in dom0)? This is the time when packages are copied to dom0 and it can take some time if there were many.
|
How long have you waited? Do you see any dom0 CPU activity (top in dom0)? This is the time when packages are copied to dom0 and it can take some time if there were many. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
claytoncarmineisahero
Jul 16, 2018
The total download size was 136M. Running top in dom0 doesn't reveal any processes consuming CPU resources (only top itself and Xorg for a total of 2% CPU). I've been waiting for about 20 minutes now, but I don't believe the copy to dom0 from updatevm would take this long?
claytoncarmineisahero
commented
Jul 16, 2018
|
The total download size was 136M. Running |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Jul 16, 2018
Member
No, 20min is indeed way too long. Check also journalctl in dom0 - maybe there is error message from ReceiveUpdates service.
|
No, 20min is indeed way too long. Check also |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
claytoncarmineisahero
Jul 16, 2018
I was able to dig up the following traceback from journalctl in dom0:
Jul 16 17:06:26 dom0 qubes.ReceiveUpdates-sys-firewall[8123]: Traceback (most recent call last):
Jul 16 17:06:26 dom0 qubes.ReceiveUpdates-sys-firewall[8123]: File "/usr/libexec/qubes/qubes-receive-updates", line 131, in <module>
Jul 16 17:06:26 dom0 qubes.ReceiveUpdates-sys-firewall[8123]: main()
Jul 16 17:06:26 dom0 qubes.ReceiveUpdates-sys-firewall[8123]: File "/usr/libexec/qubes/qubes-receive-updates", line 129, in main
Jul 16 17:06:26 dom0 qubes.ReceiveUpdates-sys-firewall[8123]: handle_dom0updates(updatevm)
Jul 16 17:06:26 dom0 qubes.ReceiveUpdates-sys-firewall[8123]: File "/usr/libexec/qubes/qubes-receive-updates", line 81, in handle_dom0updates
Jul 16 17:06:26 dom0 qubes.ReceiveUpdates-sys-firewall[8123]: str(os.getuid()), updates_rpm_dir])
Jul 16 17:06:26 dom0 qubes.ReceiveUpdates-sys-firewall[8123]: File "/usr/lib64/python3.5/subprocess.py", line 271, in check_call
Jul 16 17:06:26 dom0 qubes.ReceiveUpdates-sys-firewall[8123]: raise CalledProcessError(retcode, cmd)
Jul 16 17:06:26 dom0 qubes.ReceiveUpdates-sys-firewall[8123]: subprocess.CalledProcessError: Command '['/usr/libexec/qubes/qfile-dom0-unpacker', '1000', '/var/lib/qubes/updates/rpm']' returned non-zero exit status -13
Jul 16 17:11:06 dom0 qrexec[3983]: qubes.ReceiveUpdates: sys-firewall -> dom0: allowed to dom0
claytoncarmineisahero
commented
Jul 16, 2018
|
I was able to dig up the following traceback from |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Jul 16, 2018
Member
Is that all? No one more line above?
-13 looks like "Permission denied" - check if /usr/libexec/qubes/qfile-dom0-unpacker is executable.
|
Is that all? No one more line above? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
claytoncarmineisahero
Jul 16, 2018
Running /usr/libexec/qubes/qfile-dom0-unpacker 1000 /var/lib/qubes/updates/rpm/ -v seems to run properly (and running qfile-dom0-unpacker with no args displays usage), but there's no output.
claytoncarmineisahero
commented
Jul 16, 2018
|
Running |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Jul 16, 2018
Member
It expect packages on stdin, so it is expected to not produce any output without input.
Maybe it's about access to /var/lib/qubes/updates/rpm? Is it writable by user?
|
It expect packages on stdin, so it is expected to not produce any output without input. |
andrewdavidwong
added
bug
C: core
labels
Jul 17, 2018
andrewdavidwong
added this to the Release 4.0 updates milestone
Jul 17, 2018
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Aekez
Jul 17, 2018
Maybe it's about access to /var/lib/qubes/updates/rpm? Is it writable by user?
There is another qubes-dom0-update bug that might be related, though I am of course not too sure if it is related or not. At first glimps these two issues look unrelated, but there might be a similar root cause? I just put the observed bug in a new issue here #4099
The manual fix is quite easy by just installing the updates manually though. But it's also easy for the user not to realize no dom0 updates were installing, and given it only affects some Qubes systems, it might potentially be a root cause for some other issues out there?
Aekez
commented
Jul 17, 2018
There is another qubes-dom0-update bug that might be related, though I am of course not too sure if it is related or not. At first glimps these two issues look unrelated, but there might be a similar root cause? I just put the observed bug in a new issue here #4099 The manual fix is quite easy by just installing the updates manually though. But it's also easy for the user not to realize no dom0 updates were installing, and given it only affects some Qubes systems, it might potentially be a root cause for some other issues out there? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
claytoncarmineisahero
Jul 17, 2018
In my particular scenario, only one RPM file is being successfully(?) copied out from the updatevm to dom0 (kernel.x.y.z.qubes.arch.rpm), and that file has NULLed permissions (chmod 000). I'm still attempting to debug and resolve the issue with the help of @marmarek, but I believe we're still stuck at the qfile-dom0-unpacker stage of running qubes-dom0-update. If there is a list of steps I can follow to manually update dom0 and side step this whole problem (as a temporary fix), please let me know.
claytoncarmineisahero
commented
Jul 17, 2018
|
In my particular scenario, only one RPM file is being successfully(?) copied out from the updatevm to dom0 ( |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Aekez
Jul 17, 2018
If there is a list of steps I can follow to manually update dom0 and side step this whole problem (as a temporary fix), please let me know.
I'm not a developer expert, I just hunt for patterns though. But there might be a chance that if you did not get dom0 updates before your curl errors started to happen (successfully downloaded, but not succesfully installed, which can happen silently without user realizing, as such bug A creates bug B, but bug B is rooted in bug A while bug A remains hidden). This might or might not be the root-cause for your curl errors on the second update (and all updates giving curl errors after that). For example if the code was updated in the updatevm, but was not updated in your dom0, it might be the root cause of the curl errors? I definitely lack the insight here, I'm merely speculating on one possibility that might be of consideration among other possibilities.
I won't pursue this though, I definitely lack further insight on these things, I'm merely and only suggesting a possible pattern. It is entirely possible that bug A and B are completely unrelated though, I'm only speculating on a possibility here :)
Aekez
commented
Jul 17, 2018
I'm not a developer expert, I just hunt for patterns though. But there might be a chance that if you did not get dom0 updates before your curl errors started to happen (successfully downloaded, but not succesfully installed, which can happen silently without user realizing, as such bug A creates bug B, but bug B is rooted in bug A while bug A remains hidden). This might or might not be the root-cause for your curl errors on the second update (and all updates giving curl errors after that). For example if the code was updated in the updatevm, but was not updated in your dom0, it might be the root cause of the curl errors? I definitely lack the insight here, I'm merely speculating on one possibility that might be of consideration among other possibilities. I won't pursue this though, I definitely lack further insight on these things, I'm merely and only suggesting a possible pattern. It is entirely possible that bug A and B are completely unrelated though, I'm only speculating on a possibility here :) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
claytoncarmineisahero
Jul 17, 2018
@marmarek It seems now that the previous ReceiveUpdates error found in journalctl output is no longer showing up. Can we manually step through the dom0 update process by issuing the appropriate commands (potentially with debug/verbose triggers) and try to pinpoint what exactly is preventing the update from running end-to-end?
claytoncarmineisahero
commented
Jul 17, 2018
|
@marmarek It seems now that the previous ReceiveUpdates error found in |
claytoncarmineisahero commentedJul 16, 2018
Qubes OS version:
Qubes release 4.0 (R4.0)
Affected component(s):
dom0 (qubes-dom0-update)
Steps to reproduce the behavior:
And others...
Expected behavior:
Update dom0
Actual behavior:
qubes-dom0-update returns Curl Error (3) on all identified repos/rpms, attempts to download the available updates and then hangs (requires Ctrl+C to kill).
General notes:
Below is the full output of running
sudo qubes-dom0-updateand similar variants:Related issues:
I've attempted to map this issue to other reported issues both on GitHub and within the official and unofficial Google Groups, but have not found any that (in)directly relate to this issue.