[opensuse-arm] bind mount breakage
Hi Guillaume, Recent JeOS image builds break in bind mounting with very odd lines in /proc/mounts: /dev/mmcblk0p1 /boot\040(deleted) ext3 rw,relatime,errors=co... which results in /boot not being able to unmount or over-mount. So the first boot stage fails to update boot.scr or create an initrd, rendering the image useless after the first reboot. This is 99.999% a kernel bug. We're trying to trace this down to a kernel version change. Since you have been running images more frequently than us recently, have you seen the issue as well? And if so, could you narrow it down when it did appear for you? So far, we know that 3.2 worked fine still and that the current kernel is broken. Thanks! Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi, Le 02/07/2012 11:42, Alexander Graf a écrit :
Hi Guillaume,
Recent JeOS image builds break in bind mounting with very odd lines in /proc/mounts:
/dev/mmcblk0p1 /boot\040(deleted) ext3 rw,relatime,errors=co...
which results in /boot not being able to unmount or over-mount. So the first boot stage fails to update boot.scr or create an initrd, rendering the image useless after the first reboot. This is 99.999% a kernel bug.
We're trying to trace this down to a kernel version change. Since you have been running images more frequently than us recently, have you seen the issue as well? And if so, could you narrow it down when it did appear for you? So far, we know that 3.2 worked fine still and that the current kernel is broken.
Thanks!
Alex
I am using an old image that I have partially updated. I have not used recent images, so I have never faced this problem. If I have enough time, I will try to reproduce it with recent images. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 02.07.2012 13:56, schrieb Guillaume Gardet:
Hi,
Le 02/07/2012 11:42, Alexander Graf a �crit :
Hi Guillaume,
Recent JeOS image builds break in bind mounting with very odd lines in /proc/mounts:
/dev/mmcblk0p1 /boot\040(deleted) ext3 rw,relatime,errors=co...
which results in /boot not being able to unmount or over-mount. So the first boot stage fails to update boot.scr or create an initrd, rendering the image useless after the first reboot. This is 99.999% a kernel bug.
We're trying to trace this down to a kernel version change. Since you have been running images more frequently than us recently, have you seen the issue as well? And if so, could you narrow it down when it did appear for you? So far, we know that 3.2 worked fine still and that the current kernel is broken.
Thanks!
Alex
I am using an old image that I have partially updated. I have not used recent images, so I have never faced this problem. If I have enough time, I will try to reproduce it with recent images.
Guillaume
Hi, I'm not sure, if this is the above error, but with the current ARM image LimeJeOS-openSUSE-12.2-ARM-panda.armv7l-1.12.2-Build3.2.raw.xz the second boot fails on a Pandaboard ES: 1st boot log: http://paste.opensuse.org/abb4fe58 2nd boot log: http://paste.opensuse.org/f1390a70 Regards, endym -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 02.07.2012, at 22:14, endym wrote:
Am 02.07.2012 13:56, schrieb Guillaume Gardet:
Hi,
Le 02/07/2012 11:42, Alexander Graf a �crit :
Hi Guillaume,
Recent JeOS image builds break in bind mounting with very odd lines in /proc/mounts:
/dev/mmcblk0p1 /boot\040(deleted) ext3 rw,relatime,errors=co...
which results in /boot not being able to unmount or over-mount. So the first boot stage fails to update boot.scr or create an initrd, rendering the image useless after the first reboot. This is 99.999% a kernel bug.
We're trying to trace this down to a kernel version change. Since you have been running images more frequently than us recently, have you seen the issue as well? And if so, could you narrow it down when it did appear for you? So far, we know that 3.2 worked fine still and that the current kernel is broken.
Thanks!
Alex
I am using an old image that I have partially updated. I have not used recent images, so I have never faced this problem. If I have enough time, I will try to reproduce it with recent images.
Guillaume
Hi,
I'm not sure, if this is the above error, but with the current ARM image LimeJeOS-openSUSE-12.2-ARM-panda.armv7l-1.12.2-Build3.2.raw.xz the second boot fails on a Pandaboard ES:
1st boot log: http://paste.opensuse.org/abb4fe58 2nd boot log: http://paste.opensuse.org/f1390a70
Yup, that's exactly the problem I see with the bind mount issue. Marcus said he wants to throw something into kiwi to work around the bug. It also occured on x86, so it seems to be a generic kernel issue with 3.4. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi, Le 02/07/2012 22:19, Alexander Graf a écrit :
On 02.07.2012, at 22:14, endym wrote:
Am 02.07.2012 13:56, schrieb Guillaume Gardet:
Hi,
Le 02/07/2012 11:42, Alexander Graf a �crit :
Hi Guillaume,
Recent JeOS image builds break in bind mounting with very odd lines in /proc/mounts:
/dev/mmcblk0p1 /boot\040(deleted) ext3 rw,relatime,errors=co...
which results in /boot not being able to unmount or over-mount. So the first boot stage fails to update boot.scr or create an initrd, rendering the image useless after the first reboot. This is 99.999% a kernel bug.
We're trying to trace this down to a kernel version change. Since you have been running images more frequently than us recently, have you seen the issue as well? And if so, could you narrow it down when it did appear for you? So far, we know that 3.2 worked fine still and that the current kernel is broken.
Thanks!
Alex
I am using an old image that I have partially updated. I have not used recent images, so I have never faced this problem. If I have enough time, I will try to reproduce it with recent images.
Guillaume
Hi,
I'm not sure, if this is the above error, but with the current ARM image LimeJeOS-openSUSE-12.2-ARM-panda.armv7l-1.12.2-Build3.2.raw.xz the second boot fails on a Pandaboard ES:
1st boot log: http://paste.opensuse.org/abb4fe58 2nd boot log: http://paste.opensuse.org/f1390a70 Yup, that's exactly the problem I see with the bind mount issue. Marcus said he wants to throw something into kiwi to work around the bug. It also occured on x86, so it seems to be a generic kernel issue with 3.4.
Alex
Just tried the latest Image for beagleboard ( http://download.opensuse.org/repositories/openSUSE:/Factory:/ARM/images/Lime... ) and I have not such a problem. (kernel 3.4.4). Maybe kiwi is already fixed. ;) Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 10.07.2012, at 17:53, Guillaume Gardet wrote:
Hi,
Le 02/07/2012 22:19, Alexander Graf a écrit :
On 02.07.2012, at 22:14, endym wrote:
Am 02.07.2012 13:56, schrieb Guillaume Gardet:
Hi,
Le 02/07/2012 11:42, Alexander Graf a �crit :
Hi Guillaume,
Recent JeOS image builds break in bind mounting with very odd lines in /proc/mounts:
/dev/mmcblk0p1 /boot\040(deleted) ext3 rw,relatime,errors=co...
which results in /boot not being able to unmount or over-mount. So the first boot stage fails to update boot.scr or create an initrd, rendering the image useless after the first reboot. This is 99.999% a kernel bug.
We're trying to trace this down to a kernel version change. Since you have been running images more frequently than us recently, have you seen the issue as well? And if so, could you narrow it down when it did appear for you? So far, we know that 3.2 worked fine still and that the current kernel is broken.
Thanks!
Alex
I am using an old image that I have partially updated. I have not used recent images, so I have never faced this problem. If I have enough time, I will try to reproduce it with recent images.
Guillaume
Hi,
I'm not sure, if this is the above error, but with the current ARM image LimeJeOS-openSUSE-12.2-ARM-panda.armv7l-1.12.2-Build3.2.raw.xz the second boot fails on a Pandaboard ES:
1st boot log: http://paste.opensuse.org/abb4fe58 2nd boot log: http://paste.opensuse.org/f1390a70 Yup, that's exactly the problem I see with the bind mount issue. Marcus said he wants to throw something into kiwi to work around the bug. It also occured on x86, so it seems to be a generic kernel issue with 3.4.
Alex
Just tried the latest Image for beagleboard ( http://download.opensuse.org/repositories/openSUSE:/Factory:/ARM/images/Lime... ) and I have not such a problem. (kernel 3.4.4). Maybe kiwi is already fixed. ;)
Yup, kiwi already has the fixes in to work around the bug. Also, stay tuned for the new kernel-omap2plus! It has full support for omapdrm built in and also enabled LED flashing :) Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 10/07/2012 18:04, Alexander Graf a écrit :
On 10.07.2012, at 17:53, Guillaume Gardet wrote:
Hi,
Le 02/07/2012 22:19, Alexander Graf a écrit :
On 02.07.2012, at 22:14, endym wrote:
Am 02.07.2012 13:56, schrieb Guillaume Gardet:
Hi,
Le 02/07/2012 11:42, Alexander Graf a �crit :
Hi Guillaume,
Recent JeOS image builds break in bind mounting with very odd lines in /proc/mounts:
/dev/mmcblk0p1 /boot\040(deleted) ext3 rw,relatime,errors=co...
which results in /boot not being able to unmount or over-mount. So the first boot stage fails to update boot.scr or create an initrd, rendering the image useless after the first reboot. This is 99.999% a kernel bug.
We're trying to trace this down to a kernel version change. Since you have been running images more frequently than us recently, have you seen the issue as well? And if so, could you narrow it down when it did appear for you? So far, we know that 3.2 worked fine still and that the current kernel is broken.
Thanks!
Alex
I am using an old image that I have partially updated. I have not used recent images, so I have never faced this problem. If I have enough time, I will try to reproduce it with recent images.
Guillaume
Hi,
I'm not sure, if this is the above error, but with the current ARM image LimeJeOS-openSUSE-12.2-ARM-panda.armv7l-1.12.2-Build3.2.raw.xz the second boot fails on a Pandaboard ES:
1st boot log: http://paste.opensuse.org/abb4fe58 2nd boot log: http://paste.opensuse.org/f1390a70 Yup, that's exactly the problem I see with the bind mount issue. Marcus said he wants to throw something into kiwi to work around the bug. It also occured on x86, so it seems to be a generic kernel issue with 3.4.
Alex
Just tried the latest Image for beagleboard ( http://download.opensuse.org/repositories/openSUSE:/Factory:/ARM/images/Lime... ) and I have not such a problem. (kernel 3.4.4). Maybe kiwi is already fixed. ;) Yup, kiwi already has the fixes in to work around the bug.
Also, stay tuned for the new kernel-omap2plus! It has full support for omapdrm built in and also enabled LED flashing :)
Alex
Yes, I have it with the latest beagle image! ;) The LED flashing is nice. :) omapdrm seems to work in 1280x1024 (or something like this) but I needed to add a config file for XOrg. Same as 20-omapfb.conf but I replaced omapfb driver by omap. Maybe we should add it to xf86-video-omap? I will try to add support for 2D/3D acceleration to XOrg. (I have already enabled 2D/3D acceleration for omapfb framebuffer). Cheers, Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 10.07.2012, at 18:24, Guillaume Gardet wrote:
Le 10/07/2012 18:04, Alexander Graf a écrit :
On 10.07.2012, at 17:53, Guillaume Gardet wrote:
Hi,
Le 02/07/2012 22:19, Alexander Graf a écrit :
On 02.07.2012, at 22:14, endym wrote:
Am 02.07.2012 13:56, schrieb Guillaume Gardet:
Hi,
Le 02/07/2012 11:42, Alexander Graf a �crit : > Hi Guillaume, > > Recent JeOS image builds break in bind mounting with very odd lines in /proc/mounts: > > /dev/mmcblk0p1 /boot\040(deleted) ext3 rw,relatime,errors=co... > > which results in /boot not being able to unmount or over-mount. So the first boot stage fails to update boot.scr or > create an initrd, rendering the image useless after the first reboot. This is 99.999% a kernel bug. > > We're trying to trace this down to a kernel version change. Since you have been running images more frequently than us > recently, have you seen the issue as well? And if so, could you narrow it down when it did appear for you? So far, we > know that 3.2 worked fine still and that the current kernel is broken. > > > Thanks! > > Alex > > I am using an old image that I have partially updated. I have not used recent images, so I have never faced this problem. If I have enough time, I will try to reproduce it with recent images.
Guillaume
Hi,
I'm not sure, if this is the above error, but with the current ARM image LimeJeOS-openSUSE-12.2-ARM-panda.armv7l-1.12.2-Build3.2.raw.xz the second boot fails on a Pandaboard ES:
1st boot log: http://paste.opensuse.org/abb4fe58 2nd boot log: http://paste.opensuse.org/f1390a70 Yup, that's exactly the problem I see with the bind mount issue. Marcus said he wants to throw something into kiwi to work around the bug. It also occured on x86, so it seems to be a generic kernel issue with 3.4.
Alex
Just tried the latest Image for beagleboard ( http://download.opensuse.org/repositories/openSUSE:/Factory:/ARM/images/Lime... ) and I have not such a problem. (kernel 3.4.4). Maybe kiwi is already fixed. ;) Yup, kiwi already has the fixes in to work around the bug.
Also, stay tuned for the new kernel-omap2plus! It has full support for omapdrm built in and also enabled LED flashing :)
Alex
Yes, I have it with the latest beagle image! ;) The LED flashing is nice. :) omapdrm seems to work in 1280x1024 (or something like this) but I needed to add a config file for XOrg. Same as 20-omapfb.conf but I replaced omapfb driver by omap. Maybe we should add it to xf86-video-omap?
Yeah, I'm still not 100% sure why though. Also, fbdev is a lot faster than the omap xorg driver, so we're better off using that one for now. The omap driver plays its virtues out when using the EXA closed source binary blob which doesn't exist for OMAP3+hf.
I will try to add support for 2D/3D acceleration to XOrg. (I have already enabled 2D/3D acceleration for omapfb framebuffer).
This will be tricky ;). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (3)
-
Alexander Graf -
endym -
Guillaume Gardet