Re: [qubes-users] "Failed to return clean data" in Debian-10 Template

[Logan]

On 5/23/20 1:25 PM, unman wrote:

On Sat, May 23, 2020 at 08:39:11AM +0000, Logan wrote:

Hi all,

I am having trouble understanding the error i'm getting from the Qubes
Updater. My Debian template is no longer executing updates successfully.
Other templates are still ok.

 From all my searching I can only determine that retcode 255 appears to be
salt related. Any hints? I've typed out the report from dom0.


Updating debian-10

Error on updating debian-10: command '['sudo', 'qubesctl', '--skip-dom0',
'--targets=debian-10', '--show-output', 'state.sls', 'update.qubes-vm']'
returned non-zero exit status 20

debian-10:
        -----------
        _error:
                Failed to return clean data
        retcode:
                255
        stderr:
        stdout:


Thanks,
Logan

I cant reproduce this.
Can you try a dom0 update - also may be worth updating the template by
hnad and then seeing if that fixes the issue.

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200523132559.GD32656%40thirdeyesecurity.org.

Manually updated appears to have resolved the update issue, but my personal VM is now failing whereas other Debian based appVMs still work. Possibly an awkward coincidence.

It boots and about 10 seconds later a system halt is called:



switch_root: failed to mount moving /dev to /sysroot/dev: invalid argument



Logan

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/be2038f7-211b-e194-b3ee-e9b8647d84a4%40threatmodel.io.

A few possible issues are in the guest-<VM-NAME>.log, but the one that stands out most is: I'll include more log details after I run a diff between this and a fresh VM.

publickey - logan@threatmodel.io.asc.pgp
Description: application/pgp-key

signature.asc
Description: OpenPGP digital signature