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

[Logan]

On 5/23/20 3:23 PM, unman wrote:

On Sat, May 23, 2020 at 02:30:53PM +0000, Logan wrote:

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:

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

Has it resolved the salt update issue? Not entirely clear.

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200523152346.GA905%40thirdeyesecurity.org.

Here is the smoking gun, I think:

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





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...

--
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/5748ea83-b262-0f29-67e6-dc937e32300c%40threatmodel.io.

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. [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

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

signature.asc
Description: OpenPGP digital signature