[opensuse-arm] Raspberry Pi 1 downstream strange behavior
Hi, On the downstream image for raspberry pi 1, I have a very strange error. First boot is ok, but generated initrd is broken after 1st reboot. At the end of the 1st boot, I can verify initrd with 'lsinitrd /boot/initrd-4.3.3-1-raspberrypi' and all is ok. But if I reboot or if I umount and remount /boot (mmcblk0p2), initrd file is broken: lsinitrd /boot/initrd-4.3.3-1-raspberrypi returns: ******************************************************************************** Image: /boot/initrd-4.3.3-1-raspberrypi: 5,8M ======================================================================== xzcat: /boot/initrd-4.3.3-1-raspberrypi: Compressed data is corrupt Version: Arguments: xzcat: /boot/initrd-4.3.3-1-raspberrypi: Compressed data is corrupt dracut modules: xzcat: /boot/initrd-4.3.3-1-raspberrypi: Compressed data is corrupt ======================================================================== xzcat: /boot/initrd-4.3.3-1-raspberrypi: Compressed data is corrupt cpio: premature end of file drwxr-xr-x 15 root root 0 Feb 29 01:04 . drwxr-xr-x 2 root root 0 Feb 29 01:04 bin -rwxr-xr-x 1 root root 771176 Feb 29 01:04 bin/bash ======================================================================== ******************************************************************************** Once remounted, if I call "dracut -f -H" manually to regenerate initrd, all is ok after umounting and remounting the partition or if I reboot. Any idea what would be the problem and how to fix that ? Note that upstream image is not affected. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 02/03/2016 14:51, Michael Ströder a écrit :
Guillaume Gardet wrote:
On the downstream image for raspberry pi 1, I have a very strange error. Which image are you using? Please mention the exact name and build version, ideally the URL you've downloaded from, It was openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-1.12.1-Build386.1.raw.xz from: http://downloadcontent.opensuse.org/repositories/devel:/ARM:/Factory:/Contri...
It was just updated to Build 388.1 and the result is the same. Here is a workaround: umount /boot/efi umount /boot/ mount /boot/ mount /boot/efi dracut -H -f Then, you can reboot safely. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi,
It was just updated to Build 388.1 and the result is the same.
Here is a workaround: umount /boot/efi umount /boot/ mount /boot/ mount /boot/efi dracut -H -f
sounds a bit as if the partition resizing / reloading of the kernel fails on first boot, so the kernel is not using the new partition offsets. Or could it be that the efi partition is also resized ? I think the code only expects one partition to be resized. Thanks, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi, Le 02/03/2016 16:58, Dirk Müller a écrit :
Hi,
It was just updated to Build 388.1 and the result is the same.
Here is a workaround: umount /boot/efi umount /boot/ mount /boot/ mount /boot/efi dracut -H -f sounds a bit as if the partition resizing / reloading of the kernel fails on first boot, so the kernel is not using the new partition offsets.
Maybe.
Or could it be that the efi partition is also resized ? I think the code only expects one partition to be resized.
Apparently not. Only change seems to be ext4 partition resize and swap partition added. Guillaume
Thanks, Dirk
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Op donderdag 3 maart 2016 21:30:32 schreef Guillaume Gardet:
Hi,
Le 02/03/2016 16:58, Dirk Müller a écrit :
Hi,
It was just updated to Build 388.1 and the result is the same.
Here is a workaround: umount /boot/efi umount /boot/ mount /boot/ mount /boot/efi dracut -H -f
sounds a bit as if the partition resizing / reloading of the kernel fails on first boot, so the kernel is not using the new partition offsets.
Maybe.
Or could it be that the efi partition is also resized ? I think the code only expects one partition to be resized.
Apparently not. Only change seems to be ext4 partition resize and swap partition added.
Guillaume
Thanks, Dirk
Just tried openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-20160303.0.0-Build1.1.raw.xz which works, at least in a headless situation. New naming? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 04/03/2016 13:12, Freek de Kruijf a écrit :
Op donderdag 3 maart 2016 21:30:32 schreef Guillaume Gardet:
Hi,
Le 02/03/2016 16:58, Dirk Müller a écrit :
Hi,
It was just updated to Build 388.1 and the result is the same.
Here is a workaround: umount /boot/efi umount /boot/ mount /boot/ mount /boot/efi dracut -H -f sounds a bit as if the partition resizing / reloading of the kernel fails on first boot, so the kernel is not using the new partition offsets. Maybe.
Or could it be that the efi partition is also resized ? I think the code only expects one partition to be resized. Apparently not. Only change seems to be ext4 partition resize and swap partition added.
Guillaume
Thanks, Dirk Just tried openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-20160303.0.0-Build1.1.raw.xz which works, at least in a headless situation.
From which repo? [1] http://download.opensuse.org/ports/armv6hl/tumbleweed/images/ [2] http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp...
New naming?
Indeed, we now have a date in the naming. But old images are still there... Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Op vrijdag 4 maart 2016 14:08:50 schreef Guillaume Gardet:
Le 04/03/2016 13:12, Freek de Kruijf a écrit :
Op donderdag 3 maart 2016 21:30:32 schreef Guillaume Gardet:
Hi,
Le 02/03/2016 16:58, Dirk Müller a écrit :
Hi,
It was just updated to Build 388.1 and the result is the same.
Here is a workaround: umount /boot/efi umount /boot/ mount /boot/ mount /boot/efi dracut -H -f
sounds a bit as if the partition resizing / reloading of the kernel fails on first boot, so the kernel is not using the new partition offsets.
Maybe.
Or could it be that the efi partition is also resized ? I think the code only expects one partition to be resized.
Apparently not. Only change seems to be ext4 partition resize and swap partition added.
Guillaume
Thanks, Dirk
Just tried openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-20160303.0.0-Build1.1.raw. xz which works, at least in a headless situation.
From which repo? [1] http://download.opensuse.org/ports/armv6hl/tumbleweed/images/ [2] http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Ras pberryPi/images/
From [2], which is more or less mentioned in the subject. Besides, the one from [1] also works. AFAIK both result in the same system.
New naming?
Indeed, we now have a date in the naming. But old images are still there...
Guillaume
-- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 04/03/2016 17:00, Freek de Kruijf a écrit :
Op vrijdag 4 maart 2016 14:08:50 schreef Guillaume Gardet:
Op donderdag 3 maart 2016 21:30:32 schreef Guillaume Gardet:
Hi,
Le 02/03/2016 16:58, Dirk Müller a écrit :
Hi,
It was just updated to Build 388.1 and the result is the same.
Here is a workaround: umount /boot/efi umount /boot/ mount /boot/ mount /boot/efi dracut -H -f sounds a bit as if the partition resizing / reloading of the kernel fails on first boot, so the kernel is not using the new partition offsets. Maybe.
Or could it be that the efi partition is also resized ? I think the code only expects one partition to be resized. Apparently not. Only change seems to be ext4 partition resize and swap partition added.
Guillaume
Thanks, Dirk Just tried openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-20160303.0.0-Build1.1.raw. xz which works, at least in a headless situation. From which repo? [1] http://download.opensuse.org/ports/armv6hl/tumbleweed/images/ [2] http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Ras
Le 04/03/2016 13:12, Freek de Kruijf a écrit : pberryPi/images/ From [2], which is more or less mentioned in the subject. Besides, the one from [1] also works. AFAIK both result in the same system.
It works after a reboot too? Guillaume
New naming? Indeed, we now have a date in the naming. But old images are still there...
Guillaume
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Op vrijdag 4 maart 2016 17:19:20 schreef Guillaume Gardet:
Le 04/03/2016 17:00, Freek de Kruijf a écrit :
Op vrijdag 4 maart 2016 14:08:50 schreef Guillaume Gardet:
Le 04/03/2016 13:12, Freek de Kruijf a écrit :
Op donderdag 3 maart 2016 21:30:32 schreef Guillaume Gardet:
Hi,
Le 02/03/2016 16:58, Dirk Müller a écrit :
Hi,
> It was just updated to Build 388.1 and the result is the same. > > Here is a workaround: > umount /boot/efi > umount /boot/ > mount /boot/ > mount /boot/efi > dracut -H -f
sounds a bit as if the partition resizing / reloading of the kernel fails on first boot, so the kernel is not using the new partition offsets.
Maybe.
Or could it be that the efi partition is also resized ? I think the code only expects one partition to be resized.
Apparently not. Only change seems to be ext4 partition resize and swap partition added.
Guillaume
Thanks, Dirk
Just tried openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-20160303.0.0-Build1.1.ra w. xz which works, at least in a headless situation.
From which repo?
[1] http://download.opensuse.org/ports/armv6hl/tumbleweed/images/ [2] http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/R as pberryPi/images/
From [2], which is more or less mentioned in the subject.
Besides, the one from [1] also works. AFAIK both result in the same system.
It works after a reboot too?
Yes. It shows a nice looking Raspberry Pi logo.
Guillaume
New naming?
Indeed, we now have a date in the naming. But old images are still there...
Guillaume
-- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (4)
-
Dirk Müller -
Freek de Kruijf -
Guillaume Gardet -
Michael Ströder