On 16.04.2012, at 15:19, Marcus Schäfer wrote:
Hi,
And a ls /boot show this: ******************************************************************************** -rw-r--r-- 1 root root 1,3K 20 mars 11:52 boot.readme -rw-r--r-- 1 root root 697 1 janv. 2000 boot.scr -rw-r--r-- 1 root root 625 1 janv. 2000 boot.script -rw-r--r-- 1 root root 81K 22 mars 12:50 config-3.3.0-1-omap2plus drwxr-xr-x 2 root root 1,0K 1 janv. 2000 grub lrwxrwxrwx 1 root root 24 23 févr. 02:11 initrd -> initrd-3.3.0-1-omap2plus -rw-r--r-- 1 root root 22M 13 mars 14:50 initrd.uboot -rw-r--r-- 1 root root 3,9M 13 mars 14:50 linux.vmx drwx------ 2 root root 12K 13 mars 14:50 lost+found -rwxr-xr-x 1 root root 29K 1 mars 00:37 MLO -rw-r--r-- 1 root root 73K 22 mars 13:43 symvers-3.3.0-1-omap2plus.gz -rw-r--r-- 1 root root 234 22 mars 13:43 sysctl.conf-3.3.0-1-omap2plus -rw-r--r-- 1 root root 1,9M 22 mars 13:32 System.map-3.3.0-1-omap2plus -rw-r--r-- 1 root root 331K 1 mars 11:27 u-boot.bin lrwxrwxrwx 1 root root 24 23 févr. 02:11 uImage -> uImage-3.3.0-1-omap2plus -rw-r--r-- 1 root root 4,0M 22 mars 13:43 uImage-3.3.0-1-omap2plus -rw-r--r-- 1 root root 4,9M 22 mars 13:37 vmlinux-3.3.0-1-omap2plus.gz ********************************************************************************
So, no initrd (except a broken link and the initrd.u-boot).
Moreover, when I try to boot, u-boot is still looking for uImage-3.2.0-2-omap2plus which is no more here. (same for initrd). The last state I'm aware of is that we don't have code in perl-bootloader to update the boot.scr[ipt] on kernel updates. The initrd should have been generated though, but it seems like another file is corrupted on that image (00-system.conf).
It may be simpler to use soft links "uImage" and "initrd" for u-boot instead of uImage-XXX and initrd-XXX and just update those links instead of update the boot.scr. But I am not sure if u-boot handles correctly the soft links. So maybe use hard links or copy files. Maybe boot.scr is not so hard to update? What do you think about it?
U-boot can handle symlinks IIRC. At least it could last time I checked :).
However, that would restrict us to only a single kernel installed at a time with no easy way to choose an old / known good kernel as fallback. But then again we don't have a menu in u-boot anyway, so maybe that is moot.
Yeah, maybe we should just use the symlinks. The kernel package should create those automatically, right? Marcus, what do you think?
Hmm, I sent a patch for mkinitrd upstream and got the feedback from the maintainer that it was checked in. Wondering why no initrd was created by mkinitrd ?
So the normal workflow is this:
* on firstboot mkinitrd is called which creates 'initrd-3.3.0-1-omap2plus' * on firstboot the boot.script and the image (boot.scr) is recreated using the result initrd and kernel files not the links. So it should load:
initrd-3.3.0-1-omap2plus uImage-3.3.0-1-omap2plus
The links initrd and uImage are nice but even on our other architectures perl-Bootloader (yast2) rewrites the bootloader configuration in a way that the real files and not the link names are placed in the setup on e.g update of the kernel
If we plan to support our standard workflow for kernel updates on arm, meaning mkinitrd and perl-bootloader are called as part of the kernel rpm postscript, then I don't think we should use links in the bootloader setup
if we don't plan to do this and want only one kernel on the box and no bootloader magic on update of this kernel we might want to use the link names in the bootloader setup
Well the issue that I just realized thanks to Guillaume is that with u-boot we don't have different choices to choose from. All other bootloaders allow us to specify a bunch of options the user is able to select from. We define an entry called "Linux 3.2-rc3" and then the user can select that one. We define an entry called "Linux 3.3" and the user can select one or the other. For u-boot, we can not define preconfigured choices. Well, we can, but we don't. Right now we create a boot.script that loads one kernel - exactly one. It doesn't give you the choice you would usually get from other bootloaders, at which point we could just as well default to the "default" kernel currently installed - uImage and uInitrd. If we want to integrate with how it's done with other bootloaders, we'd probably need to define several macros for each kernel entry that the user can then execute from the u-boot command line. And by default we'd execute the "default" macro. But until we have that, it's probably the best for kiwi to create a boot.scr that takes the symlinks as their default kernel choice, so updates work at all :). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org