On Thu, Jun 08, 2017 at 02:54:22AM -0700, Vít Šesták wrote:
> I've traced the issue a bit. Maybe the race condition is not true. The VM
> updates works in has root's shell configured to bash instead of zsh. But
> that's still strange:
>
> * user with bash: OK
> * user with zsh: OK
> * root with
On 06/08/2017 05:54 AM, Vít Šesták wrote:
I've traced the issue a bit. Maybe the race condition is not true. The VM
updates works in has root's shell configured to bash instead of zsh. But that's
still strange:
* user with bash: OK
* user with zsh: OK
* root with bash: OK
* root with zsh:
I've traced the issue a bit. Maybe the race condition is not true. The VM
updates works in has root's shell configured to bash instead of zsh. But that's
still strange:
* user with bash: OK
* user with zsh: OK
* root with bash: OK
* root with zsh: environment issues
I've also tried updating to
On 06/07/2017 05:23 PM, Vít Šesták wrote:
Boot-time race condition sounds plausibly:
* It could explain not having this issue on my old laptop (SSD+HDD mix –
Debian's root.img stored on SSD, volatile.img stored on HDD) and having the
issue on the new one (SSD only), despite having almost the
On 06/07/2017 05:23 PM, Vít Šesták wrote:
Boot-time race condition sounds plausibly:
* It could explain not having this issue on my old laptop (SSD+HDD
mix – Debian's root.img stored on SSD, volatile.img stored on HDD)
and having the issue on the new one (SSD only), despite having almost
the
On Wed, Jun 07, 2017 at 02:23:45PM -0700, Vít Šesták wrote:
> Boot-time race condition sounds plausibly:
>
> * It could explain not having this issue on my old laptop (SSD+HDD mix –
> Debian's root.img stored on SSD, volatile.img stored on HDD) and having the
> issue on the new one (SSD only),
Boot-time race condition sounds plausibly:
* It could explain not having this issue on my old laptop (SSD+HDD mix –
Debian's root.img stored on SSD, volatile.img stored on HDD) and having the
issue on the new one (SSD only), despite having almost the same config. (But
I've performed a clean
On 06/07/2017 12:31 PM, Vít Šesták wrote:
I have the same kernel version, AppArmor default (haven't bothered about it)
and VM connected to sys-firewall.
To clarify, apparmor is enabled in kernelopts, but not inside the
template. I doubt its affecting this issue, though.
To make it even
I have the same kernel version, AppArmor default (haven't bothered about it)
and VM connected to sys-firewall.
To make it even more strange, when I changed the command to run in a
debian-8-based AppVM instead of the debian-8 itself, I realized there is some
VM it works in. But it does not work
On 06/06/2017 02:07 AM, Vít Šesták wrote:
I am not aware of any change that could have affected it. And I have no further
ideas what to check.
Regards,
Vít Šesták 'v6ak'
Only other variables I can think of: I'm using a 4.9.28 kernel and a VPN
proxyVM. Also, Apparmor is enabled.
--
10 matches
Mail list logo
