Am 25.02.2015 um 19:33 schrieb Marco d'Itri:
> On Feb 13, Michael Biebl wrote:
>
>> If the kernel is supposed to support such timeouts, this looks like a
>> hardware/qemu issue to me then.
> Apparently Red Hat has a fix:
> https://bugzilla.redhat.com/show_bug.cgi?id=1173038
I don't see a fix the
On Feb 13, Michael Biebl wrote:
> If the kernel is supposed to support such timeouts, this looks like a
> hardware/qemu issue to me then.
Apparently Red Hat has a fix:
https://bugzilla.redhat.com/show_bug.cgi?id=1173038
I can reproduce the issue with Debian KVM and a RHEL7 guest, so this is
a K
Processing commands for cont...@bugs.debian.org:
> clone 35 -1
Bug #35 [systemd] data corruption on reboot when using watchdog/qemu
Bug 35 cloned as bug 778291
> reassign -1 qemu-system-x86
Bug #778291 [systemd] data corruption on reboot when using watchdog/qemu
Bug reassigned from pac
clone 35 -1
reassign -1 qemu-system-x86
retile -1 setting unsupported timeout for i6300esb watchdog causes reset
thanks
Am 13.02.2015 um 08:55 schrieb Peter Colberg:
> On Fri, Feb 13, 2015 at 08:02:09AM +0100, Michael Biebl wrote:
>> Am 13.02.2015 um 07:44 schrieb Michael Biebl:
>>> I went on
Am 13.02.2015 um 08:55 schrieb Peter Colberg:
> In the linux-3.16.7-ckt4 source the range of the timeout value for
> the i6300esb is 1s < timeout < 2*1023s. In theory it should work
> with the default shutdown timeout of 10min.
This again might suggest, that his is a hardware, i.e. qemu bug?
> Fo
On Fri, Feb 13, 2015 at 08:02:09AM +0100, Michael Biebl wrote:
> Am 13.02.2015 um 07:44 schrieb Michael Biebl:
> > I went on and looked what the watchdog package does. Interestingly, it
> > clamps any timeout value to 254s, thus not hitting this issue.
> > Apparently, i6300esb is able to deal with
Am 13.02.2015 um 07:44 schrieb Michael Biebl:
> I went on and looked what the watchdog package does. Interestingly, it
> clamps any timeout value to 254s, thus not hitting this issue.
> Apparently, i6300esb is able to deal with such a timeout.
>
> Peter, I therefore recommend you set
>
> Shutdow
Am 12.02.2015 um 09:54 schrieb Peter Colberg:
> [ 11.473895] systemd[1]: Failed to set timeout to 600s: Invalid argument
> [ 11.474649] ib700wdt: WDT device closed unexpectedly. WDT will not stop!
>
> Both watchdogs close unexpectedly, but i6300esb immediately resets the
> machine, while ib70
On Thu, Feb 12, 2015 at 08:50:59AM +0100, Michael Biebl wrote:
> Some more findings: Aside from only happening on reboot, but not
> shutdown, it also seems to only happen with i6300esb. Switching the qemu
> config to use ib700 instead of i6300esb, I am not able to trigger the
> problem. This confir
Am 12.02.2015 um 08:31 schrieb Michael Biebl:
> Am 12.02.2015 um 07:34 schrieb Michael Biebl:
>> Am 12.02.2015 um 07:29 schrieb Peter Colberg:
>>> On Thu, Feb 12, 2015 at 07:14:05AM +0100, Michael Biebl wrote:
>>
>>> It is curious that the bug only manifests itself with the qemu watchdog.
>>> Two p
Am 12.02.2015 um 07:34 schrieb Michael Biebl:
> Am 12.02.2015 um 07:29 schrieb Peter Colberg:
>> On Thu, Feb 12, 2015 at 07:14:05AM +0100, Michael Biebl wrote:
>
>> It is curious that the bug only manifests itself with the qemu watchdog.
>> Two physical machines using the hardware iTCO_wdt watchdo
Am 12.02.2015 um 07:34 schrieb Michael Biebl:
> Am 12.02.2015 um 07:29 schrieb Peter Colberg:
>> On Thu, Feb 12, 2015 at 07:14:05AM +0100, Michael Biebl wrote:
>
>> It is curious that the bug only manifests itself with the qemu watchdog.
>> Two physical machines using the hardware iTCO_wdt watchdo
Am 12.02.2015 um 07:29 schrieb Peter Colberg:
> On Thu, Feb 12, 2015 at 07:14:05AM +0100, Michael Biebl wrote:
> It is curious that the bug only manifests itself with the qemu watchdog.
> Two physical machines using the hardware iTCO_wdt watchdog reboot fine.
In my tests, I did indeed have an unc
On Thu, Feb 12, 2015 at 07:14:05AM +0100, Michael Biebl wrote:
> Thanks, I was able to reproduce the issue this way (marking the bug
> accordingly).
> It's likely that the watchog is resetting systemd/rsyslog before it has
> a chance to stop properly.
>
> Let's see, where we can go from here.
In
control: tags -1 = confirmed
control: retitle -1 data corruption on reboot when using watchdog/qemu
Am 12.02.2015 um 06:57 schrieb Peter Colberg:
> On Thu, Feb 12, 2015 at 05:44:59AM +0100, Michael Biebl wrote:
>> Fwiw, I pulled the debian_wheezy_amd64_desktop.qcow2 qemu-kvm image from
>> [1], sta
Processing control commands:
> tags -1 = confirmed
Bug #35 [systemd] systemd: Disk corruption on reboot initiated through
systemd
Added tag(s) confirmed; removed tag(s) unreproducible and moreinfo.
> retitle -1 data corruption on reboot when using watchdog/qemu
Bug #35 [systemd] systemd:
On Thu, Feb 12, 2015 at 05:44:59AM +0100, Michael Biebl wrote:
> Fwiw, I pulled the debian_wheezy_amd64_desktop.qcow2 qemu-kvm image from
> [1], started it with "qemu-system-x86_64 -enable-kvm -hda
> debian_wheezy_amd64_standard.qcow2".
> Then did a dist-upgrade to jessie, which replaced sysvinit w
On Thu, Feb 12, 2015 at 04:28:38AM +0100, Michael Biebl wrote:
> Just to be clear here: Is this only happening once after the
> dist-upgrade from wheezy (sysvinit) to jessie (systemd-sysv) on reboot
> or everytime you reboot your jessie system?
It happens everytime I reboot from within the VM.
>
Processing control commands:
> severity -1 important
Bug #35 [systemd] systemd: Disk corruption on reboot initiated through
systemd
Severity set to 'important' from 'grave'
--
35: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=35
Debian Bug Tracking System
Contact ow...@bugs.debia
control: severity -1 important
Am 12.02.2015 um 04:28 schrieb Michael Biebl:
>> I could reproduce this issue with three machines that are virtualized
>> > with qemu-kvm. On the other hand, I did not see this issue with two
>> > physical machines. All of these are running the above version of
>> >
Processing control commands:
> tags -1 moreinfo unreproducible
Bug #35 [systemd] systemd: Disk corruption on reboot initiated through
systemd
Added tag(s) unreproducible and moreinfo.
--
35: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=35
Debian Bug Tracking System
Contact ow...
control: tags -1 moreinfo unreproducible
Am 12.02.2015 um 03:19 schrieb Peter Colberg:
> Package: systemd
> Version: 215-11
> Severity: grave
> Justification: causes non-serious data loss
>
> Dear Maintainer,
>
> After upgrading to jessie from wheezy, I noticed that some of the
> system logs exp
Package: systemd
Version: 215-11
Severity: grave
Justification: causes non-serious data loss
Dear Maintainer,
After upgrading to jessie from wheezy, I noticed that some of the
system logs experience corruption when rebooting the system.
After rebooting the system using the command ‘reboot’ or ‘s
23 matches
Mail list logo
