[opensuse-arm] armv7 images broken: Initramfs unpacking failed: write error
Hi, ARMv7 images are broken. On boot, with latest build (kernel 4.4.0-3-default) I get the following error: "Initramfs unpacking failed: write error". Full kernel log (for beaglebone black): ******************************************************** Starting kernel ... [ 0.000530] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0' [ 0.000538] This ensures that you still see kernel messages. Please [ 0.000545] update your kernel commandline. [ 5.154972] Initramfs unpacking failed: write error [ 5.351054] omap_voltage_late_init: Voltage driver support not added [ 5.357567] sr_dev_init: No voltage domain specified for smartreflex0. Cannot initialize [ 5.365720] sr_dev_init: No voltage domain specified for smartreflex1. Cannot initialize [ 5.563828] sr_init: platform driver register failed for SR [ 5.575720] Unable to find PPMU node [ 5.586412] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 [ 5.586412] [ 5.595610] CPU: 0 PID: 1 Comm: init Not tainted 4.4.0-3-default #1 [ 5.601901] Hardware name: Generic AM33XX (Flattened Device Tree) [ 5.608068] [<c022876c>] (unwind_backtrace) from [<c0221904>] (show_stack+0x20/0x28) [ 5.615856] [<c0221904>] (show_stack) from [<c0575ee8>] (dump_stack+0x9c/0xdc) [ 5.623125] [<c0575ee8>] (dump_stack) from [<c03803c0>] (panic+0xb0/0x248) [ 5.630039] [<c03803c0>] (panic) from [<c0274e54>] (complete_and_exit+0x0/0x2c) [ 5.637383] [<c0274e54>] (complete_and_exit) from [<c0274eec>] (do_group_exit+0x4c/0xcc) [ 5.645510] [<c0274eec>] (do_group_exit) from [<c0274f8c>] (__wake_up_parent+0x0/0x34) [ 5.653464] [<c0274f8c>] (__wake_up_parent) from [<c021ce60>] (ret_fast_syscall+0x0/0x34) [ 5.661690] Rebooting in 90 seconds.. ******************************************************** Note that there is no early message (except warning on console, for which I will send a JeOS SR). Any idea what is wrong? Any kernel config update related to initramfs? Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 17.02.2016 um 11:00 schrieb Guillaume Gardet <guillaume.gardet@free.fr>:
Hi,
ARMv7 images are broken.
On boot, with latest build (kernel 4.4.0-3-default) I get the following error: "Initramfs unpacking failed: write error". Full kernel log (for beaglebone black): ******************************************************** Starting kernel ...
[ 0.000530] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0' [ 0.000538] This ensures that you still see kernel messages. Please [ 0.000545] update your kernel commandline. [ 5.154972] Initramfs unpacking failed: write error [ 5.351054] omap_voltage_late_init: Voltage driver support not added [ 5.357567] sr_dev_init: No voltage domain specified for smartreflex0. Cannot initialize [ 5.365720] sr_dev_init: No voltage domain specified for smartreflex1. Cannot initialize [ 5.563828] sr_init: platform driver register failed for SR [ 5.575720] Unable to find PPMU node [ 5.586412] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 [ 5.586412] [ 5.595610] CPU: 0 PID: 1 Comm: init Not tainted 4.4.0-3-default #1 [ 5.601901] Hardware name: Generic AM33XX (Flattened Device Tree) [ 5.608068] [<c022876c>] (unwind_backtrace) from [<c0221904>] (show_stack+0x20/0x28) [ 5.615856] [<c0221904>] (show_stack) from [<c0575ee8>] (dump_stack+0x9c/0xdc) [ 5.623125] [<c0575ee8>] (dump_stack) from [<c03803c0>] (panic+0xb0/0x248) [ 5.630039] [<c03803c0>] (panic) from [<c0274e54>] (complete_and_exit+0x0/0x2c) [ 5.637383] [<c0274e54>] (complete_and_exit) from [<c0274eec>] (do_group_exit+0x4c/0xcc) [ 5.645510] [<c0274eec>] (do_group_exit) from [<c0274f8c>] (__wake_up_parent+0x0/0x34) [ 5.653464] [<c0274f8c>] (__wake_up_parent) from [<c021ce60>] (ret_fast_syscall+0x0/0x34) [ 5.661690] Rebooting in 90 seconds.. ********************************************************
Note that there is no early message (except warning on console, for which I will send a JeOS SR).
Any idea what is wrong?
Looks like the initrd is too big (again). Please try to set the rootfstype to ramfs in the kernel command line to verify. I guess we really need to come up with a good way around this whole mess. I like the squashfs-in-initramfs approach the best so far... Alex
Any kernel config update related to initramfs?
Guillaume
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 17/02/2016 11:15, Alexander Graf a écrit :
Am 17.02.2016 um 11:00 schrieb Guillaume Gardet <guillaume.gardet@free.fr>:
Hi,
ARMv7 images are broken.
On boot, with latest build (kernel 4.4.0-3-default) I get the following error: "Initramfs unpacking failed: write error". Full kernel log (for beaglebone black): ******************************************************** Starting kernel ...
[ 0.000530] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0' [ 0.000538] This ensures that you still see kernel messages. Please [ 0.000545] update your kernel commandline. [ 5.154972] Initramfs unpacking failed: write error [ 5.351054] omap_voltage_late_init: Voltage driver support not added [ 5.357567] sr_dev_init: No voltage domain specified for smartreflex0. Cannot initialize [ 5.365720] sr_dev_init: No voltage domain specified for smartreflex1. Cannot initialize [ 5.563828] sr_init: platform driver register failed for SR [ 5.575720] Unable to find PPMU node [ 5.586412] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 [ 5.586412] [ 5.595610] CPU: 0 PID: 1 Comm: init Not tainted 4.4.0-3-default #1 [ 5.601901] Hardware name: Generic AM33XX (Flattened Device Tree) [ 5.608068] [<c022876c>] (unwind_backtrace) from [<c0221904>] (show_stack+0x20/0x28) [ 5.615856] [<c0221904>] (show_stack) from [<c0575ee8>] (dump_stack+0x9c/0xdc) [ 5.623125] [<c0575ee8>] (dump_stack) from [<c03803c0>] (panic+0xb0/0x248) [ 5.630039] [<c03803c0>] (panic) from [<c0274e54>] (complete_and_exit+0x0/0x2c) [ 5.637383] [<c0274e54>] (complete_and_exit) from [<c0274eec>] (do_group_exit+0x4c/0xcc) [ 5.645510] [<c0274eec>] (do_group_exit) from [<c0274f8c>] (__wake_up_parent+0x0/0x34) [ 5.653464] [<c0274f8c>] (__wake_up_parent) from [<c021ce60>] (ret_fast_syscall+0x0/0x34) [ 5.661690] Rebooting in 90 seconds.. ********************************************************
Note that there is no early message (except warning on console, for which I will send a JeOS SR).
Any idea what is wrong? Looks like the initrd is too big (again). Please try to set the rootfstype to ramfs in the kernel command line to verify.
It did the trick indeed!
I guess we really need to come up with a good way around this whole mess. I like the squashfs-in-initramfs approach the best so far...
Why kernel does not handle it right without 'rootfstype=ramfs'? Could we tweak kernel config so that it works with large initramfs? squashfs-in-initramfs approach would need some kiwi work, I guess? Guillaume
Alex
Any kernel config update related to initramfs?
Guillaume
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
17.02.2016 14:01, Guillaume Gardet пишет:
Could we tweak kernel config so that it works with large initramfs?
How is it going to work when initramfs exceeds your existing RAM size? Real issue here is KIWI. Sometimes, unneeded things appear in initrd, like Mesa, or linker ld scripts.
squashfs-in-initramfs approach would need some kiwi work, I guess?
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 17.02.2016 um 12:01 schrieb Guillaume Gardet <guillaume.gardet@free.fr>:
Le 17/02/2016 11:15, Alexander Graf a écrit :
Am 17.02.2016 um 11:00 schrieb Guillaume Gardet <guillaume.gardet@free.fr>:
Hi,
ARMv7 images are broken.
On boot, with latest build (kernel 4.4.0-3-default) I get the following error: "Initramfs unpacking failed: write error". Full kernel log (for beaglebone black): ******************************************************** Starting kernel ...
[ 0.000530] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0' [ 0.000538] This ensures that you still see kernel messages. Please [ 0.000545] update your kernel commandline. [ 5.154972] Initramfs unpacking failed: write error [ 5.351054] omap_voltage_late_init: Voltage driver support not added [ 5.357567] sr_dev_init: No voltage domain specified for smartreflex0. Cannot initialize [ 5.365720] sr_dev_init: No voltage domain specified for smartreflex1. Cannot initialize [ 5.563828] sr_init: platform driver register failed for SR [ 5.575720] Unable to find PPMU node [ 5.586412] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 [ 5.586412] [ 5.595610] CPU: 0 PID: 1 Comm: init Not tainted 4.4.0-3-default #1 [ 5.601901] Hardware name: Generic AM33XX (Flattened Device Tree) [ 5.608068] [<c022876c>] (unwind_backtrace) from [<c0221904>] (show_stack+0x20/0x28) [ 5.615856] [<c0221904>] (show_stack) from [<c0575ee8>] (dump_stack+0x9c/0xdc) [ 5.623125] [<c0575ee8>] (dump_stack) from [<c03803c0>] (panic+0xb0/0x248) [ 5.630039] [<c03803c0>] (panic) from [<c0274e54>] (complete_and_exit+0x0/0x2c) [ 5.637383] [<c0274e54>] (complete_and_exit) from [<c0274eec>] (do_group_exit+0x4c/0xcc) [ 5.645510] [<c0274eec>] (do_group_exit) from [<c0274f8c>] (__wake_up_parent+0x0/0x34) [ 5.653464] [<c0274f8c>] (__wake_up_parent) from [<c021ce60>] (ret_fast_syscall+0x0/0x34) [ 5.661690] Rebooting in 90 seconds.. ********************************************************
Note that there is no early message (except warning on console, for which I will send a JeOS SR).
Any idea what is wrong? Looks like the initrd is too big (again). Please try to set the rootfstype to ramfs in the kernel command line to verify.
It did the trick indeed!
I guess we really need to come up with a good way around this whole mess. I like the squashfs-in-initramfs approach the best so far...
Why kernel does not handle it right without 'rootfstype=ramfs'?
The kernel defaults to tmpfs here, limiting the available space to half (or third? don't remember) of your system ram.
Could we tweak kernel config so that it works with large initramfs?
We could create a patch that defaults to ramfs instead. The real problem imho is that the initrd is too big though.
squashfs-in-initramfs approach would need some kiwi work, I guess?
Yes, it would. But then we would also get around the 64k page size problems. On 64k page size systems, every file in tmpfs occupies at least 64k. So if you have a few thousand like we do in the kiwi initrd, you waste a few 100 mbs just because of that. Alex
Guillaume
Alex
Any kernel config update related to initramfs?
Guillaume
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Do we really need this file in initrd? -rw-r--r-- 1 matwey users 25044944 фев 17 16:35 ./usr/share/icu/56.1/icudt56l.dat As far as I remember there were no libicu in initrd. 17.02.2016 16:34, Alexander Graf пишет:
Am 17.02.2016 um 12:01 schrieb Guillaume Gardet <guillaume.gardet@free.fr>:
Le 17/02/2016 11:15, Alexander Graf a écrit :
Am 17.02.2016 um 11:00 schrieb Guillaume Gardet <guillaume.gardet@free.fr>:
Hi,
ARMv7 images are broken.
On boot, with latest build (kernel 4.4.0-3-default) I get the following error: "Initramfs unpacking failed: write error". Full kernel log (for beaglebone black): ******************************************************** Starting kernel ...
[ 0.000530] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0' [ 0.000538] This ensures that you still see kernel messages. Please [ 0.000545] update your kernel commandline. [ 5.154972] Initramfs unpacking failed: write error [ 5.351054] omap_voltage_late_init: Voltage driver support not added [ 5.357567] sr_dev_init: No voltage domain specified for smartreflex0. Cannot initialize [ 5.365720] sr_dev_init: No voltage domain specified for smartreflex1. Cannot initialize [ 5.563828] sr_init: platform driver register failed for SR [ 5.575720] Unable to find PPMU node [ 5.586412] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 [ 5.586412] [ 5.595610] CPU: 0 PID: 1 Comm: init Not tainted 4.4.0-3-default #1 [ 5.601901] Hardware name: Generic AM33XX (Flattened Device Tree) [ 5.608068] [<c022876c>] (unwind_backtrace) from [<c0221904>] (show_stack+0x20/0x28) [ 5.615856] [<c0221904>] (show_stack) from [<c0575ee8>] (dump_stack+0x9c/0xdc) [ 5.623125] [<c0575ee8>] (dump_stack) from [<c03803c0>] (panic+0xb0/0x248) [ 5.630039] [<c03803c0>] (panic) from [<c0274e54>] (complete_and_exit+0x0/0x2c) [ 5.637383] [<c0274e54>] (complete_and_exit) from [<c0274eec>] (do_group_exit+0x4c/0xcc) [ 5.645510] [<c0274eec>] (do_group_exit) from [<c0274f8c>] (__wake_up_parent+0x0/0x34) [ 5.653464] [<c0274f8c>] (__wake_up_parent) from [<c021ce60>] (ret_fast_syscall+0x0/0x34) [ 5.661690] Rebooting in 90 seconds.. ********************************************************
Note that there is no early message (except warning on console, for which I will send a JeOS SR).
Any idea what is wrong? Looks like the initrd is too big (again). Please try to set the rootfstype to ramfs in the kernel command line to verify.
It did the trick indeed!
I guess we really need to come up with a good way around this whole mess. I like the squashfs-in-initramfs approach the best so far...
Why kernel does not handle it right without 'rootfstype=ramfs'?
The kernel defaults to tmpfs here, limiting the available space to half (or third? don't remember) of your system ram.
Could we tweak kernel config so that it works with large initramfs?
We could create a patch that defaults to ramfs instead. The real problem imho is that the initrd is too big though.
squashfs-in-initramfs approach would need some kiwi work, I guess?
Yes, it would. But then we would also get around the 64k page size problems. On 64k page size systems, every file in tmpfs occupies at least 64k. So if you have a few thousand like we do in the kiwi initrd, you waste a few 100 mbs just because of that.
Alex
Guillaume
Alex
Any kernel config update related to initramfs?
Guillaume
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Should grub2 be in initrd? I am not sure, just asking. 17.02.2016 16:42, Matwey V. Kornilov пишет:
Do we really need this file in initrd?
-rw-r--r-- 1 matwey users 25044944 фев 17 16:35 ./usr/share/icu/56.1/icudt56l.dat
As far as I remember there were no libicu in initrd.
17.02.2016 16:34, Alexander Graf пишет:
Am 17.02.2016 um 12:01 schrieb Guillaume Gardet <guillaume.gardet@free.fr>:
Le 17/02/2016 11:15, Alexander Graf a écrit :
Am 17.02.2016 um 11:00 schrieb Guillaume Gardet <guillaume.gardet@free.fr>:
Hi,
ARMv7 images are broken.
On boot, with latest build (kernel 4.4.0-3-default) I get the following error: "Initramfs unpacking failed: write error". Full kernel log (for beaglebone black): ******************************************************** Starting kernel ...
[ 0.000530] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0' [ 0.000538] This ensures that you still see kernel messages. Please [ 0.000545] update your kernel commandline. [ 5.154972] Initramfs unpacking failed: write error [ 5.351054] omap_voltage_late_init: Voltage driver support not added [ 5.357567] sr_dev_init: No voltage domain specified for smartreflex0. Cannot initialize [ 5.365720] sr_dev_init: No voltage domain specified for smartreflex1. Cannot initialize [ 5.563828] sr_init: platform driver register failed for SR [ 5.575720] Unable to find PPMU node [ 5.586412] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 [ 5.586412] [ 5.595610] CPU: 0 PID: 1 Comm: init Not tainted 4.4.0-3-default #1 [ 5.601901] Hardware name: Generic AM33XX (Flattened Device Tree) [ 5.608068] [<c022876c>] (unwind_backtrace) from [<c0221904>] (show_stack+0x20/0x28) [ 5.615856] [<c0221904>] (show_stack) from [<c0575ee8>] (dump_stack+0x9c/0xdc) [ 5.623125] [<c0575ee8>] (dump_stack) from [<c03803c0>] (panic+0xb0/0x248) [ 5.630039] [<c03803c0>] (panic) from [<c0274e54>] (complete_and_exit+0x0/0x2c) [ 5.637383] [<c0274e54>] (complete_and_exit) from [<c0274eec>] (do_group_exit+0x4c/0xcc) [ 5.645510] [<c0274eec>] (do_group_exit) from [<c0274f8c>] (__wake_up_parent+0x0/0x34) [ 5.653464] [<c0274f8c>] (__wake_up_parent) from [<c021ce60>] (ret_fast_syscall+0x0/0x34) [ 5.661690] Rebooting in 90 seconds.. ********************************************************
Note that there is no early message (except warning on console, for which I will send a JeOS SR).
Any idea what is wrong? Looks like the initrd is too big (again). Please try to set the rootfstype to ramfs in the kernel command line to verify.
It did the trick indeed!
I guess we really need to come up with a good way around this whole mess. I like the squashfs-in-initramfs approach the best so far...
Why kernel does not handle it right without 'rootfstype=ramfs'?
The kernel defaults to tmpfs here, limiting the available space to half (or third? don't remember) of your system ram.
Could we tweak kernel config so that it works with large initramfs?
We could create a patch that defaults to ramfs instead. The real problem imho is that the initrd is too big though.
squashfs-in-initramfs approach would need some kiwi work, I guess?
Yes, it would. But then we would also get around the 64k page size problems. On 64k page size systems, every file in tmpfs occupies at least 64k. So if you have a few thousand like we do in the kiwi initrd, you waste a few 100 mbs just because of that.
Alex
Guillaume
Alex
Any kernel config update related to initramfs?
Guillaume
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Guillaume, Am 17.02.2016 um 11:00 schrieb Guillaume Gardet:
On boot, with latest build (kernel 4.4.0-3-default) I get the following error: "Initramfs unpacking failed: write error". Full kernel log (for beaglebone black): ******************************************************** Starting kernel ...
[ 0.000530] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0' [ 0.000538] This ensures that you still see kernel messages. Please [ 0.000545] update your kernel commandline. [ 5.154972] Initramfs unpacking failed: write error [...] Note that there is no early message (except warning on console, for which I will send a JeOS SR).
Any idea what is wrong?
For early messages try adding "earlycon" to the command line. When you need only one console, the most future-proof would be to drop console= if /chosen stdout-path points to something sane in the device tree - Alex reported Kiwi possibly depending on console= parsing, so that may need patches and testing.
Any kernel config update related to initramfs?
Not that I'm aware of, no. Alex already pointed to tmpfs vs. ramfs as the most likely cause here; another cause to check for on such errors is whether the load addresses may be wrong - some time ago I ran into such an issue with an Arndale board. With the distro cleanups happening in U-Boot, too many of our JeOS images are still specifying hardcoded addresses in the JeOS scripts rather than using U-Boot-provided $ramdisk_addr_r and friends. I started a cleanup but never finished and don't have access to all boards to check, in particular the Olimex ones. Also once you've successfully installed a JeOS image we provide no package to ever update the boot.scr, so it bitrots and I usually replace it with something simpler on my systems at some point. Another thing to look into is our .kiwi.in template - last time I checked we were always including wildcard drivers such as mmc/* rather than the specific ones needed per board. config.sh should have the list of required drivers for second boot in the dracut snippets. Same comment here, such config files should really go into some board branding package so that users are not left without, e.g., mmc_block after updating the kernel (beaglebone-black-sd-branding-openSUSE?). Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 02/17/2016 03:47 PM, Andreas Färber wrote:
Hi Guillaume,
Am 17.02.2016 um 11:00 schrieb Guillaume Gardet:
On boot, with latest build (kernel 4.4.0-3-default) I get the following error: "Initramfs unpacking failed: write error". Full kernel log (for beaglebone black): ******************************************************** Starting kernel ...
[ 0.000530] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0' [ 0.000538] This ensures that you still see kernel messages. Please [ 0.000545] update your kernel commandline. [ 5.154972] Initramfs unpacking failed: write error [...] Note that there is no early message (except warning on console, for which I will send a JeOS SR).
Any idea what is wrong? For early messages try adding "earlycon" to the command line.
When you need only one console, the most future-proof would be to drop console= if /chosen stdout-path points to something sane in the device tree - Alex reported Kiwi possibly depending on console= parsing, so that may need patches and testing.
Any kernel config update related to initramfs? Not that I'm aware of, no.
Alex already pointed to tmpfs vs. ramfs as the most likely cause here;
It's not the cause, it's a workaround. We used to use tmpfs before as well, but then our initrd grew so much that it didn't fit anymore and so now the only way to get it extracted is to use ramfs. The real cause is that the kiwi initrd grew too big. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 17.02.2016 um 15:53 schrieb Alexander Graf:
On 02/17/2016 03:47 PM, Andreas Färber wrote:
Am 17.02.2016 um 11:00 schrieb Guillaume Gardet:
Any kernel config update related to initramfs? Not that I'm aware of, no.
Alex already pointed to tmpfs vs. ramfs as the most likely cause here;
It's not the cause, it's a workaround. We used to use tmpfs before as well, but then our initrd grew so much that it didn't fit anymore and so now the only way to get it extracted is to use ramfs.
My point was that if changing to ramfs works then the addresses are OK.
The real cause is that the kiwi initrd grew too big.
The initrd does not magically grow, so there must be some deeper cause. The 4.4 kernel submission is already some weeks back, so either updated Tumbleweed packages pull in new dependencies or there was a Kiwi update (we had a fork with patches some weeks ago, now it's inherited again) or our JeOS definitions changed - or maybe nobody tested BBB images for some time. 512 MB Raspberry Pi 1 B/B+ is armv6hl and thus has less kernel modules, while BBB is probably one of the lowest RAM armv7hl JeOS images built so noticing memory problems first. Matwey previously brought up the question of whether Kiwi's initrd stripping hooks are actually called - he reported it didn't work in September: http://lists.opensuse.org/opensuse-arm/2015-09/msg00054.html Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 17/02/2016 18:41, Andreas Färber a écrit :
Am 17.02.2016 um 15:53 schrieb Alexander Graf:
On 02/17/2016 03:47 PM, Andreas Färber wrote:
Am 17.02.2016 um 11:00 schrieb Guillaume Gardet:
Any kernel config update related to initramfs? Not that I'm aware of, no.
Alex already pointed to tmpfs vs. ramfs as the most likely cause here; It's not the cause, it's a workaround. We used to use tmpfs before as well, but then our initrd grew so much that it didn't fit anymore and so now the only way to get it extracted is to use ramfs. My point was that if changing to ramfs works then the addresses are OK.
The real cause is that the kiwi initrd grew too big. The initrd does not magically grow, so there must be some deeper cause. The 4.4 kernel submission is already some weeks back, so either updated Tumbleweed packages pull in new dependencies or there was a Kiwi update (we had a fork with patches some weeks ago, now it's inherited again) or our JeOS definitions changed - or maybe nobody tested BBB images for some time.
512 MB Raspberry Pi 1 B/B+ is armv6hl and thus has less kernel modules, while BBB is probably one of the lowest RAM armv7hl JeOS images built so noticing memory problems first.
Matwey previously brought up the question of whether Kiwi's initrd stripping hooks are actually called - he reported it didn't work in September: http://lists.opensuse.org/opensuse-arm/2015-09/msg00054.html
Marcus, how could we tell kiwi to remove some things from initrd? For example, some libs and some kernel drivers? Guillaume
Regards, Andreas
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi,
Marcus, how could we tell kiwi to remove some things from initrd?
For example, some libs and some kernel drivers?
could be done this way <strip type="delete"> <file name="..."/> </strip> Put the strip section below the toplevel <image> section. It's a powerful section only applied when the initrd is build. The contents are merged with the default strip section from /usr/share/kiwi/metadata/KIWIConfig.xml Regards, Marcus -- Public Key available via: https://keybase.io keybase search marcus_schaefer ------------------------------------------------------- Marcus Schäfer (Res. & Dev.) SUSE Linux GmbH Tel: 0911-740 53 0 Maxfeldstrasse 5 FAX: 0911-740 53 479 D-90409 Nürnberg HRB: 21284 (AG Nürnberg) Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton http://www.suse.de ------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 17/02/2016 18:41, Andreas Färber a écrit :
Am 17.02.2016 um 15:53 schrieb Alexander Graf:
On 02/17/2016 03:47 PM, Andreas Färber wrote:
Am 17.02.2016 um 11:00 schrieb Guillaume Gardet:
Any kernel config update related to initramfs? Not that I'm aware of, no.
Alex already pointed to tmpfs vs. ramfs as the most likely cause here; It's not the cause, it's a workaround. We used to use tmpfs before as well, but then our initrd grew so much that it didn't fit anymore and so now the only way to get it extracted is to use ramfs. My point was that if changing to ramfs works then the addresses are OK.
The real cause is that the kiwi initrd grew too big. The initrd does not magically grow, so there must be some deeper cause. The 4.4 kernel submission is already some weeks back, so either updated Tumbleweed packages pull in new dependencies or there was a Kiwi update (we had a fork with patches some weeks ago, now it's inherited again) or our JeOS definitions changed - or maybe nobody tested BBB images for some time.
I did not tested it for a while. Comparing an image from June 2015 to this one (February 2016), bigger differences are the following: * /lib : 47 MB > 74 MB - lib/firmware : 552 K > 22 M - lib/modules : 39 M > 44 M * /usr : 65 MB > 105 MB - usr/lib : 37 M > 59 M - usr/share : 17 M > 45 M (grub2 and icu folders appeared) So, the main problem seems to be that kernel-firmware, grub2 and icu packages are there with lots of deps. Marcus, any thing in kiwi explaining that? Guillaume
512 MB Raspberry Pi 1 B/B+ is armv6hl and thus has less kernel modules, while BBB is probably one of the lowest RAM armv7hl JeOS images built so noticing memory problems first.
Matwey previously brought up the question of whether Kiwi's initrd stripping hooks are actually called - he reported it didn't work in September: http://lists.opensuse.org/opensuse-arm/2015-09/msg00054.html
Regards, Andreas
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi,
I did not tested it for a while. Comparing an image from June 2015 to this one (February 2016), bigger differences are the following: * /lib : 47 MB > 74 MB - lib/firmware : 552 K > 22 M - lib/modules : 39 M > 44 M * /usr : 65 MB > 105 MB - usr/lib : 37 M > 59 M - usr/share : 17 M > 45 M (grub2 and icu folders appeared)
So, the main problem seems to be that kernel-firmware, grub2 and icu packages are there with lots of deps.
Marcus, any thing in kiwi explaining that?
I haven't touched this. Regards, Marcus -- Public Key available via: https://keybase.io keybase search marcus_schaefer ------------------------------------------------------- Marcus Schäfer (Res. & Dev.) SUSE Linux GmbH Tel: 0911-740 53 0 Maxfeldstrasse 5 FAX: 0911-740 53 479 D-90409 Nürnberg HRB: 21284 (AG Nürnberg) Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton http://www.suse.de ------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 18/02/2016 12:09, Marcus Schäfer a écrit :
Hi,
I did not tested it for a while. Comparing an image from June 2015 to this one (February 2016), bigger differences are the following: * /lib : 47 MB > 74 MB - lib/firmware : 552 K > 22 M - lib/modules : 39 M > 44 M * /usr : 65 MB > 105 MB - usr/lib : 37 M > 59 M - usr/share : 17 M > 45 M (grub2 and icu folders appeared)
So, the main problem seems to be that kernel-firmware, grub2 and icu packages are there with lots of deps.
Marcus, any thing in kiwi explaining that? I haven't touched this.
So, the only explaination is that a package is pulling it as a dependency? According to this page: https://build.opensuse.org/package/binary/openSUSE:Factory:ARM/grub2?arch=armv7l&filename=grub2-2.02~beta2-55.1.armv7hl.rpm&repository=standard Only kiwi-desc-oemboot-requires and kiwi-desc-vmxboot-requires are requiring it (except grub2* packages). It was not the case with older kiwi. It could explain it or not? Guillaume
Regards, Marcus
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Guillaume,
Only kiwi-desc-oemboot-requires and kiwi-desc-vmxboot-requires are requiring it (except grub2* packages). It was not the case with older kiwi.
It could explain it or not?
yes, the pullin of grub2 is currently a mistake, at least until Alex grub2/uboot unification kicks in. I"m adding a kiwi overlay to remove the grub2 dependency. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 18/02/2016 13:21, Dirk Müller a écrit :
Hi Guillaume,
Only kiwi-desc-oemboot-requires and kiwi-desc-vmxboot-requires are requiring it (except grub2* packages). It was not the case with older kiwi.
It could explain it or not? yes, the pullin of grub2 is currently a mistake, at least until Alex grub2/uboot unification kicks in. I"m adding a kiwi overlay to remove the grub2 dependency.
What's about kernel-firmware? For ICU, I do not know which part requires it. Guillaume
Greetings, Dirk
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Guillaume Gardet <guillaume.gardet@free.fr> writes:
For ICU, I do not know which part requires it.
osc buildinfo -d openSUSE:Factory:ARM/JeOS-arndale/factory/armv7l ICU is coming via wget->libpsl5->libicu56_1. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 18/02/2016 14:14, Andreas Schwab a écrit :
Guillaume Gardet <guillaume.gardet@free.fr> writes:
For ICU, I do not know which part requires it. osc buildinfo -d openSUSE:Factory:ARM/JeOS-arndale/factory/armv7l
thanks for this command I did not know about!
ICU is coming via wget->libpsl5->libicu56_1.
Ok. But wget is not in initrd. After a check, there is also: kiwi-desc-oemboot-requires -> curl ->libpsl5->libicu56_1. So, do we really need curl? Guillaume
Andreas.
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
18.02.2016 16:29, Guillaume Gardet пишет:
Le 18/02/2016 14:14, Andreas Schwab a écrit :
Guillaume Gardet <guillaume.gardet@free.fr> writes:
For ICU, I do not know which part requires it. osc buildinfo -d openSUSE:Factory:ARM/JeOS-arndale/factory/armv7l
thanks for this command I did not know about!
ICU is coming via wget->libpsl5->libicu56_1.
Ok. But wget is not in initrd. After a check, there is also: kiwi-desc-oemboot-requires -> curl ->libpsl5->libicu56_1.
So, do we really need curl?
Last time when I looked inside initrd, there were no network stack at all. I am not sure, that we need it. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Guillaume,
After a check, there is also: kiwi-desc-oemboot-requires -> curl ->libpsl5->libicu56_1.
So, do we really need curl?
Yeah, it is a dependency of dracut.. we should try to get rid of it, since it is pretty stupid imho. I've done a test and rebuild libpsl against libidn, and that only pulls in 1.7MB of dependencies instead of almost 40MB with icu. perhaps we could convince the maintainer to switch to libidn2 ? Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Yeah, it is a dependency of dracut.. we should try to get rid of it, since it is pretty stupid imho. I've done a test and rebuild libpsl against libidn, and that only pulls in 1.7MB of dependencies instead of almost 40MB with icu. perhaps we could convince the maintainer to switch to libidn2 ?
just stripping that nonsense saved ~ 20MB compressed size of the initrd. will submit. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi,
just stripping that nonsense saved ~ 20MB compressed size of the initrd. will submit.
ok, with two additional fixes we're down from 71MB to 44MB. Hopefully this will help with low memory boards. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi, ----- Dirk Müller <dirk@dmllr.de> a écrit :
Hi,
just stripping that nonsense saved ~ 20MB compressed size of the initrd. will submit.
ok, with two additional fixes we're down from 71MB to 44MB. Hopefully this will help with low memory boards.
Excellent! Thanks for taking care of this problem. Guillaume
Greetings, Dirk
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
21.02.2016 09:55, Dirk Müller пишет:
Hi,
just stripping that nonsense saved ~ 20MB compressed size of the initrd. will submit.
ok, with two additional fixes we're down from 71MB to 44MB. Hopefully this will help with low memory boards.
That is great. Two years ago I tried to run openSUSE on 256MB RAM board and I failed to fit initrd into it. Now I see that 512MB is considered low-memory. I think in 2018, we will find that initrd again won't fit into 1GB low-memory boards :)
Greetings, Dirk
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
20.02.2016 23:57, Dirk Müller пишет:
Hi Guillaume,
After a check, there is also: kiwi-desc-oemboot-requires -> curl ->libpsl5->libicu56_1.
So, do we really need curl?
Yeah, it is a dependency of dracut.. we should try to get rid of it, since it is pretty stupid imho.
Probably, some dracut module needs this and this particular module could be packaged as separate sub-package.
I've done a test and rebuild libpsl against libidn, and that only pulls in 1.7MB of dependencies instead of almost 40MB with icu. perhaps we could convince the maintainer to switch to libidn2 ?
Greetings, Dirk
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 17.02.2016 um 15:47 schrieb Andreas Färber:
I started a cleanup but never finished and don't have access to all boards to check, in particular the Olimex ones.
I can do that tests. While testing openSUSE-Tumbleweed-ARM-E20-olinuxinolime2.armv7l-1.12.1-Build377.1.raw.xz I faced some issues (I removed "quiet splash=silent" from the kernel command line to get some output to serial console): The first boot end with: <snip> + echo '[1455926389.155528] Checking ext4 filesystem on /dev/mmcblk0p2...' + '[' 0 = 0 ']' + set +x + checkFilesystem + local device= + local FSTYPE_SAVE= + '[' -z ext4 ']' + '[' ext4 = reiserfs ']' + '[' ext4 = ext2 ']' + '[' ext4 = ext3 ']' + '[' ext4 = ext4 ']' + e2fsck -p -f Usage: e2fsck [-panyrcdfvtDFV] [-b superblock] [-B blocksize] [-I inode_buffer_blocks] [-P process_inode_size] [-l|-L bad_blocks_file] [-C fd] [-j external_journal] [-E extended-options] device Emergency help: -p Automatic repair (no questions) -n Make no changes to the filesystem -y Assume "yes" to all questions -c Check for bad blocks and add them to the badblock list -f Force checking even if filesystem is marked clean -v Be verbose -b superblock Use alternative superblock -B blocksize Force blocksize when looking for superblock -j external_journal Set location of the external journal -l bad_blocks_file Add to badblocks list -L bad_blocks_file Set badblocks list + FSTYPE= + Echo 'Resizing filesystem on /dev/mmcblk0p2...' + local 'IFS= ' + '[' 0 = 0 ']' + set +x + echo '[1455926389.184328] Resizing filesystem on /dev/mmcblk0p2...' + '[' 0 = 0 ']' + set +x + eval resize2fs -f -F -p /dev/mmcblk0p2 ++ resize2fs -f -F -p /dev/mmcblk0p2 resize2fs 1.42.13 (17-May-2015) resize2fs: Unknown code ____ 255 while trying to flush /dev/mmcblk0p2 + '[' '!' 1 = 0 ']' + systemException 'Failed to resize/check filesystem' reboot + local 'IFS= ' + set +x + echo -e '[1455926389.338469] Failed to resize/check filesystem' + '[' 0 = 0 ']' + set +x + case "$what" in + cat /var/log/boot.kiwi [1455926395.681619] rebootException: reboot in 120 sec... [ 152.968761] reboot: Restarting system [ 153.972608] Reboot failed -- System halted <snap> after reset the board /boot/zImage points to zImage-4.4.1-1-default which is not there. So uboot fails at that point. /boot/dtb points to dtb-4.4.0-1 which indicates that the dtb version is different from the kernel version. This was already problem in the past where outdated dtb versions were used in images. Br, Frank -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Frank,
+ echo '[1455926389.155528] Checking ext4 filesystem on /dev/mmcblk0p2...' + '[' 0 = 0 ']' + set +x + checkFilesystem
Yeah, I've seen that in my testing as well. it is a kiwi bug (https://github.com/openSUSE/kiwi/pull/551) and I submitted a fix for it, next build should have it.
after reset the board /boot/zImage points to zImage-4.4.1-1-default which is not there. So uboot fails at that point.
Yeah, known problem. I"ve submitted a fix for that almost a week ago but factory review process takes forever :-( Thanks, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 21/02/2016 22:09, Dirk Müller a écrit :
Hi Frank,
+ echo '[1455926389.155528] Checking ext4 filesystem on /dev/mmcblk0p2...' + '[' 0 = 0 ']' + set +x + checkFilesystem Yeah, I've seen that in my testing as well. it is a kiwi bug (https://github.com/openSUSE/kiwi/pull/551) and I submitted a fix for it, next build should have it.
after reset the board /boot/zImage points to zImage-4.4.1-1-default which is not there. So uboot fails at that point. Yeah, known problem. I"ve submitted a fix for that almost a week ago but factory review process takes forever :-(
Where are the problem and the fix? I faced this problem recently. :( Guillaume
Thanks, Dirk
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 25.02.2016 um 13:54 schrieb Guillaume Gardet:
Le 21/02/2016 22:09, Dirk Müller a écrit :
Hi Frank,
+ echo '[1455926389.155528] Checking ext4 filesystem on /dev/mmcblk0p2...' + '[' 0 = 0 ']' + set +x + checkFilesystem Yeah, I've seen that in my testing as well. it is a kiwi bug (https://github.com/openSUSE/kiwi/pull/551) and I submitted a fix for it, next build should have it.
after reset the board /boot/zImage points to zImage-4.4.1-1-default which is not there. So uboot fails at that point. Yeah, known problem. I"ve submitted a fix for that almost a week ago but factory review process takes forever :-(
Where are the problem and the fix? I faced this problem recently. :(
The problem can be seen here (after first boot of openSUSE-Tumbleweed-ARM-JeOS-olinuxinolime2.armv7l-1.12.1-Build384.1.raw.xz): nohostname:~ # ls /boot -l total 27057 -rw-r--r-- 1 root root 65 Feb 18 10:06 .zImage-4.4.1-1-default.hmac -rw-r--r-- 1 root root 0 Feb 25 2016 0x2f883933 -rw-r--r-- 1 root root 3794718 Feb 18 09:29 System.map-4.4.1-1-default lrwxrwxrwx 1 root root 1 Feb 25 01:00 boot -> . -rw-r--r-- 1 root root 1725 Feb 18 11:27 boot.readme -rw-r--r-- 1 root root 2759 Feb 25 01:02 boot.scr -rw-r--r-- 1 root root 2687 Feb 25 01:00 boot.script -rw-r--r-- 1 root root 195238 Feb 18 03:35 config-4.4.1-1-default lrwxrwxrwx 1 root root 11 Feb 25 2016 dtb -> dtb-4.4.1-1 drwx------ 2 root root 1024 Feb 25 2016 dtb-4.4.1-1 lrwxrwxrwx 1 root root 22 Feb 25 2016 initrd -> initrd-4.4.1-1-default -rw------- 1 root root 5877616 Feb 25 01:02 initrd-4.4.1-1-default drwx------ 2 root root 12288 Feb 25 2016 lost+found -rwxr-xr-x 1 root root 24576 Feb 18 14:44 sunxi-spl.bin -rw-r--r-- 1 root root 302441 Feb 18 10:06 symvers-4.4.1-1-default.gz -rw-r--r-- 1 root root 207 Feb 18 10:06 sysctl.conf-4.4.1-1-default -rwxr-xr-x 1 root root 451691 Feb 18 14:44 u-boot-sunxi-with-spl.bin -rw-r--r-- 1 root root 418923 Feb 18 14:44 u-boot.img -rw-r--r-- 1 root root 9080243 Feb 18 10:10 vmlinux.gz -rw-r--r-- 1 root root 7413640 Feb 18 09:29 vmlinuz lrwxrwxrwx 1 root root 22 Feb 25 2016 zImage -> zImage-4.4.1-1-default The file zImage-4.4.1-1-default is missing, so the next boot will fail. Br, Frank -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
----- Frank Kunz <mailinglists@kunz-im-inter.net> a écrit :
Am 25.02.2016 um 13:54 schrieb Guillaume Gardet:
Le 21/02/2016 22:09, Dirk Müller a écrit :
Hi Frank,
+ echo '[1455926389.155528] Checking ext4 filesystem on /dev/mmcblk0p2...' + '[' 0 = 0 ']' + set +x + checkFilesystem Yeah, I've seen that in my testing as well. it is a kiwi bug (https://github.com/openSUSE/kiwi/pull/551) and I submitted a fix for it, next build should have it.
after reset the board /boot/zImage points to zImage-4.4.1-1-default which is not there. So uboot fails at that point. Yeah, known problem. I"ve submitted a fix for that almost a week ago but factory review process takes forever :-(
Where are the problem and the fix? I faced this problem recently. :(
The problem can be seen here (after first boot of openSUSE-Tumbleweed-ARM-JeOS-olinuxinolime2.armv7l-1.12.1-Build384.1.raw.xz): nohostname:~ # ls /boot -l total 27057 -rw-r--r-- 1 root root 65 Feb 18 10:06 .zImage-4.4.1-1-default.hmac -rw-r--r-- 1 root root 0 Feb 25 2016 0x2f883933 -rw-r--r-- 1 root root 3794718 Feb 18 09:29 System.map-4.4.1-1-default lrwxrwxrwx 1 root root 1 Feb 25 01:00 boot -> . -rw-r--r-- 1 root root 1725 Feb 18 11:27 boot.readme -rw-r--r-- 1 root root 2759 Feb 25 01:02 boot.scr -rw-r--r-- 1 root root 2687 Feb 25 01:00 boot.script -rw-r--r-- 1 root root 195238 Feb 18 03:35 config-4.4.1-1-default lrwxrwxrwx 1 root root 11 Feb 25 2016 dtb -> dtb-4.4.1-1 drwx------ 2 root root 1024 Feb 25 2016 dtb-4.4.1-1 lrwxrwxrwx 1 root root 22 Feb 25 2016 initrd -> initrd-4.4.1-1-default -rw------- 1 root root 5877616 Feb 25 01:02 initrd-4.4.1-1-default drwx------ 2 root root 12288 Feb 25 2016 lost+found -rwxr-xr-x 1 root root 24576 Feb 18 14:44 sunxi-spl.bin -rw-r--r-- 1 root root 302441 Feb 18 10:06 symvers-4.4.1-1-default.gz -rw-r--r-- 1 root root 207 Feb 18 10:06 sysctl.conf-4.4.1-1-default -rwxr-xr-x 1 root root 451691 Feb 18 14:44 u-boot-sunxi-with-spl.bin -rw-r--r-- 1 root root 418923 Feb 18 14:44 u-boot.img -rw-r--r-- 1 root root 9080243 Feb 18 10:10 vmlinux.gz -rw-r--r-- 1 root root 7413640 Feb 18 09:29 vmlinuz lrwxrwxrwx 1 root root 22 Feb 25 2016 zImage -> zImage-4.4.1-1-default
The file zImage-4.4.1-1-default is missing, so the next boot will fail.
As a workaround, you can rename vmlinuz to zImage-4.4.1-1-default. Guillaume
Br, Frank
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Frank,
lrwxrwxrwx 1 root root 22 Feb 25 2016 zImage -> zImage-4.4.1-1-default The file zImage-4.4.1-1-default is missing, so the next boot will fail.
Ouch. I think I found the reason for that, lets see if next image is better. Thanks, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 29.02.2016 um 14:38 schrieb Dirk Müller:
Ouch. I think I found the reason for that, lets see if next image is better.
Ok, I will test. What was the problem? ...and what is the simplest way to find out which fixes/changes are included in a image build? Br, Frank -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 29/02/2016 19:44, Frank Kunz a écrit :
Am 29.02.2016 um 14:38 schrieb Dirk Müller:
Ouch. I think I found the reason for that, lets see if next image is better. Ok, I will test. What was the problem?
...and what is the simplest way to find out which fixes/changes are included in a image build?
You can have a look here: https://build.opensuse.org/package/revisions/openSUSE:Factory:ARM/JeOS and you will get a log to know what has been modified in the images build process. Note the revision number which is the major number in image version. But you will not get any information about packages updates here. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (9)
-
Alexander Graf -
Andreas Färber -
Andreas Schwab -
Dirk Müller -
Frank Kunz -
Guillaume Gardet -
guillaume.gardet＠free.fr
-
Marcus Schäfer -
Matwey V. Kornilov