"Failed to return clean data" in Debian-10 Template

23 views
Skip to first unread message

Logan

unread,
May 23, 2020, 4:39:19 AM5/23/20
to qubes-users
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
publickey - logan@threatmodel.io.asc.pgp
signature.asc

unman

unread,
May 23, 2020, 9:26:02 AM5/23/20
to qubes-users
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.

Logan

unread,
May 23, 2020, 10:31:11 AM5/23/20
to qubes...@googlegroups.com
> --
> 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...@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:

A few possible issues are in the guest-<VM-NAME>.log, but the one that
stands out most is:

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

I'll include more log details after I run a diff between this and a
fresh VM.

Logan

publickey - logan@threatmodel.io.asc.pgp
signature.asc

unman

unread,
May 23, 2020, 11:23:50 AM5/23/20
to qubes...@googlegroups.com
Has it resolved the salt update issue? Not entirely clear.
On the other issue, you are taking right steps.
Your diff would be interesting - make sure you have a backup of the data in
your personal VM, just in case.

Logan

unread,
May 23, 2020, 8:58:47 PM5/23/20
to qubes...@googlegroups.com
Yes it has! Thank you.
> On the other issue, you are taking right steps.
> Your diff would be interesting - make sure you have a backup of the data in
> your personal VM, just in case.
>
> --
> 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...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200523152346.GA905%40thirdeyesecurity.org.
>

I have identified the moment when all services start shutting down and
the system halts: Appears to be I/O related. I should have enough disk
space as I just increased Private storage to 10240mb and System storage
is the same.

Here is the smoking gun, I think:

Debian GNU/Linux 10 Personal hvc0
login: [15.293110] fuse init (API version 7.27)

[31.774331] tun: Universal TUN/TAP device driver, 1.6


[23025.639734] blkfront: xvdd: empty flush op
failed
[23025.639751] blkfront: xvdd: barrier or flush: disabled; pe

Stopping .[0;1;39mRealtimeKit Scheduling Policy Serv

Stopping .[0;1;39mAvailability of block devices.[0m.
[.[0;32m OK .[0m] Stopped target .[0;1;39mTimers.[0m.
[.[0;32m OK .[0m] Stopped .[0;1;39mDaily man-db regeneratio

Stopping .[0;1;39mCUPS Scheduler.[0m...

publickey - logan@threatmodel.io.asc.pgp
signature.asc
Reply all
Reply to author
Forward
0 new messages