[opensuse-autoinstall] grub boots wrong kernel after stage 1
Good morning, we are using PXE to boot into autoyast and install the packages from local repositories via http and are having a problem since Suse released a new kernel package in April. Everything works fine up to the first reboot after finishing stage 1. Then grub has two kernels to choose from: 2.6.31.12-0.1-default, which is the kernel of the autoyast installation, and 2.6.31.12-0.2-desktop, which is the newest kernel freshly installed from our repositories. Grub boots the 2.6.31.12-0.1-default-kernel, complains (with good cause) 'unable to canonicalize path "/lib/modules/2.6.31.12-0.1-default/systemtap/preloadtrace.ko": No such file or directory' and continues booting, but fails to load the modules for the network card and the graphics card (and probably others). This leads to X not starting and -worse- autoyast failing to load some configuration files via ftp, configured like this: <file> <file_path>/etc/somefile</file_path> <file_owner>root:root</file_owner> <file_permissions>644</file_permissions> <file_location>ftp://somehost/files/etc/somefile</file_location> </file> Autoyast does not complain very visibly about this failure while it's running. The files not loaded do exist on the system afterwards, alas with a size of 0 bytes. The normal system logs do not contain that first boot, so it is kinda hard to figure out exactly why the final system does not work like it should. If I babysit the installation and manually choose the other kernel version (2.6.31.12-0.2-desktop) when grub comes up after stage 1, everything continues like it should, but I don't really want to wait to hit "down down return" at the exact right time... So: Why is the installation kernel still configured in grub when it is not fully functional anymore? How do I get rid of it at this early time? Or is our error something else entirely? Thanks in advance, Antje -- Antje Bendrich (Team IT-Services), Phone +49 40 808077-642 DFN-CERT Services GmbH, https://www.dfn-cert.de/, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Sachsenstraße 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski
QUZBSUsgaSBoYWQgYSBzaW1pbGFyIHByb2JsZW0gYSBsb25nIHRpbWUgYWdvIGFuZCBzb2x2ZWQgaXQgYnkgc2VsZWN0aW5nL2RlZmluaW5nIHRoZSBrZXJuZWwgaW4gdGhlIHNvZnR3YXJlIHNlY3Rpb24gb2YgdGhlIGluc3RhbGxhdGlvbiBmaWxlIC4NCg0KRXhhbXBsZTogDQouLi4NCjxzb2Z0d2FyZT4NCiAgICA8ZG9fb25saW5lX3VwZGF0ZSBjb25maWc6dHlwZT0iYm9vbGVhbiI+dHJ1ZTwvZG9fb25saW5lX3VwZGF0ZT4NCiAgICA8a2VybmVsPmtlcm5lbC1wYWU8L2tlcm5lbD4NCi4uLg0KDQpIdGgNCkhham8NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQW50amUgQmVuZHJpY2ggW21haWx0bzpiZW5kcmljaEBkZm4tY2VydC5kZV0gDQpTZW50OiBUaHVyc2RheSwgTWF5IDIwLCAyMDEwIDg6MzAgQU0NClRvOiBvcGVuc3VzZS1hdXRvaW5zdGFsbEBvcGVuc3VzZS5vcmcNClN1YmplY3Q6IFtvcGVuc3VzZS1hdXRvaW5zdGFsbF0gZ3J1YiBib290cyB3cm9uZyBrZXJuZWwgYWZ0ZXIgc3RhZ2UgMQ0KDQpHb29kIG1vcm5pbmcsDQoNCndlIGFyZSB1c2luZyBQWEUgdG8gYm9vdCBpbnRvIGF1dG95YXN0IGFuZCBpbnN0YWxsIHRoZSBwYWNrYWdlcyBmcm9tIGxvY2FsDQpyZXBvc2l0b3JpZXMgdmlhIGh0dHAgYW5kIGFyZSBoYXZpbmcgYSBwcm9ibGVtIHNpbmNlIFN1c2UgcmVsZWFzZWQgYSBuZXcga2VybmVsDQpwYWNrYWdlIGluIEFwcmlsLg0KDQpFdmVyeXRoaW5nIHdvcmtzIGZpbmUgdXAgdG8gdGhlIGZpcnN0IHJlYm9vdCBhZnRlciBmaW5pc2hpbmcgc3RhZ2UgMS4gVGhlbiBncnViDQpoYXMgdHdvIGtlcm5lbHMgdG8gY2hvb3NlIGZyb206IDIuNi4zMS4xMi0wLjEtZGVmYXVsdCwgd2hpY2ggaXMgdGhlIGtlcm5lbCBvZg0KdGhlIGF1dG95YXN0IGluc3RhbGxhdGlvbiwgYW5kIDIuNi4zMS4xMi0wLjItZGVza3RvcCwgd2hpY2ggaXMgdGhlIG5ld2VzdCBrZXJuZWwNCmZyZXNobHkgaW5zdGFsbGVkIGZyb20gb3VyIHJlcG9zaXRvcmllcy4NCg0KR3J1YiBib290cyB0aGUgMi42LjMxLjEyLTAuMS1kZWZhdWx0LWtlcm5lbCwgY29tcGxhaW5zICh3aXRoIGdvb2QgY2F1c2UpICd1bmFibGUNCnRvIGNhbm9uaWNhbGl6ZSBwYXRoDQoiL2xpYi9tb2R1bGVzLzIuNi4zMS4xMi0wLjEtZGVmYXVsdC9zeXN0ZW10YXAvcHJlbG9hZHRyYWNlLmtvIjogTm8gc3VjaCBmaWxlIG9yDQpkaXJlY3RvcnknIGFuZCBjb250aW51ZXMgYm9vdGluZywgYnV0IGZhaWxzIHRvIGxvYWQgdGhlIG1vZHVsZXMgZm9yIHRoZSBuZXR3b3JrDQpjYXJkIGFuZCB0aGUgZ3JhcGhpY3MgY2FyZCAoYW5kIHByb2JhYmx5IG90aGVycykuIFRoaXMgbGVhZHMgdG8gWCBub3Qgc3RhcnRpbmcNCmFuZCAtd29yc2UtIGF1dG95YXN0IGZhaWxpbmcgdG8gbG9hZCBzb21lIGNvbmZpZ3VyYXRpb24gZmlsZXMgdmlhIGZ0cCwNCmNvbmZpZ3VyZWQgbGlrZSB0aGlzOg0KICAgIDxmaWxlPg0KICAgICAgPGZpbGVfcGF0aD4vZXRjL3NvbWVmaWxlPC9maWxlX3BhdGg+DQogICAgICA8ZmlsZV9vd25lcj5yb290OnJvb3Q8L2ZpbGVfb3duZXI+DQogICAgICA8ZmlsZV9wZXJtaXNzaW9ucz42NDQ8L2ZpbGVfcGVybWlzc2lvbnM+DQogICAgICA8ZmlsZV9sb2NhdGlvbj5mdHA6Ly9zb21laG9zdC9maWxlcy9ldGMvc29tZWZpbGU8L2ZpbGVfbG9jYXRpb24+DQogICAgPC9maWxlPg0KDQpBdXRveWFzdCBkb2VzIG5vdCBjb21wbGFpbiB2ZXJ5IHZpc2libHkgYWJvdXQgdGhpcyBmYWlsdXJlIHdoaWxlIGl0J3MgcnVubmluZy4NClRoZSBmaWxlcyBub3QgbG9hZGVkIGRvIGV4aXN0IG9uIHRoZSBzeXN0ZW0gYWZ0ZXJ3YXJkcywgYWxhcyB3aXRoIGEgc2l6ZSBvZiAwDQpieXRlcy4gVGhlIG5vcm1hbCBzeXN0ZW0gbG9ncyBkbyBub3QgY29udGFpbiB0aGF0IGZpcnN0IGJvb3QsIHNvIGl0IGlzIGtpbmRhDQpoYXJkIHRvIGZpZ3VyZSBvdXQgZXhhY3RseSB3aHkgdGhlIGZpbmFsIHN5c3RlbSBkb2VzIG5vdCB3b3JrIGxpa2UgaXQgc2hvdWxkLg0KDQpJZiBJIGJhYnlzaXQgdGhlIGluc3RhbGxhdGlvbiBhbmQgbWFudWFsbHkgY2hvb3NlIHRoZSBvdGhlciBrZXJuZWwgdmVyc2lvbg0KKDIuNi4zMS4xMi0wLjItZGVza3RvcCkgd2hlbiBncnViIGNvbWVzIHVwIGFmdGVyIHN0YWdlIDEsIGV2ZXJ5dGhpbmcgY29udGludWVzDQpsaWtlIGl0IHNob3VsZCwgYnV0IEkgZG9uJ3QgcmVhbGx5IHdhbnQgdG8gd2FpdCB0byBoaXQgImRvd24gZG93biByZXR1cm4iIGF0IHRoZQ0KZXhhY3QgcmlnaHQgdGltZS4uLg0KDQpTbzogV2h5IGlzIHRoZSBpbnN0YWxsYXRpb24ga2VybmVsIHN0aWxsIGNvbmZpZ3VyZWQgaW4gZ3J1YiB3aGVuIGl0IGlzIG5vdCBmdWxseQ0KZnVuY3Rpb25hbCBhbnltb3JlPyBIb3cgZG8gSSBnZXQgcmlkIG9mIGl0IGF0IHRoaXMgZWFybHkgdGltZT8gT3IgaXMgb3VyIGVycm9yDQpzb21ldGhpbmcgZWxzZSBlbnRpcmVseT8NCg0KVGhhbmtzIGluIGFkdmFuY2UsDQpBbnRqZQ0KDQotLSANCkFudGplIEJlbmRyaWNoIChUZWFtIElULVNlcnZpY2VzKSwgICAgICAgICAgICAgICAgIFBob25lICs0OSA0MCA4MDgwNzctNjQyDQoNCkRGTi1DRVJUIFNlcnZpY2VzIEdtYkgsIGh0dHBzOi8vd3d3LmRmbi1jZXJ0LmRlLywgUGhvbmUgICs0OSA0MCA4MDgwNzctNTU1DQpTaXR6IC8gUmVnaXN0ZXI6IEhhbWJ1cmcsIEFHIEhhbWJ1cmcsIEhSQiA4ODgwNSwgIFVzdC1JZE5yLjogIERFIDIzMjEyOTczNw0KU2FjaHNlbnN0cmHDn2UgNSwgMjAwOTcgSGFtYnVyZy9HZXJtYW55LCAgIENFTzogRHIuIEtsYXVzLVBldGVyIEtvc3Nha293c2tpDQoNCg0K-- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.orgFor additional commands, e-mail: opensuse-autoinstall+help@opensuse.org
Am 20.05.2010 09:54, schrieb Hans-Joachim Ehlers:
AFAIK i had a similar problem a long time ago and solved it by selecting/defining the kernel in the software section of the installation file .
Example: ... <software> <do_online_update config:type="boolean">true</do_online_update> <kernel>kernel-pae</kernel> ...
We are using <kernel>kernel-desktop</kernel> to install the right kernel and it works just fine. Our problem is that this kernel is not grub's default choice for booting into stage 2. But now that you mention it: We do not use <do_online_update>, because the packages in our repo are already the newest version. Is this bad practice? Antje -- Antje Bendrich (Team IT-Services), Phone +49 40 808077-642 DFN-CERT Services GmbH, https://www.dfn-cert.de/, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Sachsenstraße 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski
Hm , i think i missed the grub section to mention - sorry Example: ... <bootloader> <global> <activate>true</activate> <boot_extended>true</boot_extended> <default>openSUSE 11.1 - 2.6.27.7-9 (pae)</default> <generic_mbr>true</generic_mbr> <gfxmenu>/boot/message</gfxmenu> <lines_cache_id>5</lines_cache_id> <timeout config:type="integer">8</timeout> </global> ... <sections config:type="list"> <section> <append>smp pci=noacpi resume=/dev/sda5 splash=silent showopts vga=0x315</append> <image>/boot/vmlinuz-2.6.27.7-9-pae</image> <initial>1</initial> <initrd>/boot/initrd-2.6.27.7-9-pae</initrd> <lines_cache_id>0</lines_cache_id> <name>openSUSE 11.1 - 2.6.27.7-9 (pae)</name> <original_name>linux</original_name> <type>image</type> </section> <section> <append>showopts ide=nodma apm=off noresume nosmp maxcpus=0 edd=off powersaved=off nohz=off highres=off processor.max_cst ate=1 x11failsafe</append> <image>/boot/vmlinuz-2.6.27.7-9-pae</image> <initrd>/boot/initrd-2.6.27.7-9-pae</initrd> <lines_cache_id>1</lines_cache_id> <name>Failsafe -- openSUSE 11.1 - 2.6.27.7-9 (pae)</name> <original_name>failsafe</original_name> <type>image</type> </section> </sections> </bootloader> ... So IMO you must configure the kernel section AND the grub section. Thus grub knows what to start. If everything fails you can change the kernel in a post init script. Meaning installing the default kernel and then chancing to the required one.
But now that you mention it: We do not use <do_online_update>, because the packages in our repo are already the newest version. Is this bad practice? I have only working practise :-). I never cared about this " <do_online_update> "
For details see http://ugansert.blogspot.com/2008_07_01_archive.html Cheers Hajo
Am 20.05.2010 11:04, schrieb Hans-Joachim Ehlers:
Hm , i think i missed the grub section to mention - sorry [..] So IMO you must configure the kernel section AND the grub section. Thus grub knows what to start.
The bootloader-section is unconfigured so far. I'll play around with it and see what happens and whether I can handle it gracefully for new kernel versions as they come up in our installation repository. I'll give you results later after thinking and testing ;)
If everything fails you can change the kernel in a post init script. Meaning installing the default kernel and then chancing to the required one.
Good idea as a fallback, thank you. Antje -- Antje Bendrich (Team IT-Services), Phone +49 40 808077-642 DFN-CERT Services GmbH, https://www.dfn-cert.de/, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Sachsenstraße 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski
Am 20.05.2010 13:47, schrieb Antje Bendrich:
Am 20.05.2010 11:04, schrieb Hans-Joachim Ehlers:
Hm , i think i missed the grub section to mention - sorry [..] So IMO you must configure the kernel section AND the grub section. Thus grub knows what to start.
The bootloader-section is unconfigured so far.
I'll play around with it and see what happens and whether I can handle it gracefully for new kernel versions as they come up in our installation repository. I'll give you results later after thinking and testing ;)
Just for the record, here's what I configured: <bootloader> <global> [..] <default>openSUSE 11.2 - Desktop</default> </global> <loader_type>grub</loader_type> <sections config:type="list"> <image>(hd0,5)/vmlinuz</image> <initrd>(hd0,5)/initrd</initrd> <name>openSUSE 11.2 - Desktop</name> <original_name>linux</original_name> <type>image</type> <vgamode>0x314</vgamode> <configfile>1</configfile> [..] </sections> </bootloader> and <scripts> <chroot-scripts config:type="list"> <script> <debug config:type="boolean">true</debug> <chrooted config:type="boolean">true</chrooted> <filename>0050_stage1_link_kernel_for_grub.sh</filename> <source><![CDATA[#!/bin/sh # The <bootloader>-section makes the kernel that is linked to /boot/vmlinuz the # default. So we need to set that link correctly before the first reboot. # Ugly, not fault-tolerant, but works good enough for testing. echo 'Setting links for the newest desktop kernels:' if [ -f "$(ls -tr /boot/vmlinuz*-desktop | tail -n1)" ] then ln -sfv $(ls -tr /boot/vmlinuz*-desktop | tail -n1) /boot/vmlinuz ln -sfv $(ls -tr /boot/initrd*-desktop | tail -n1) /boot/initrd else echo 'ERROR: Kein passender Kernel unter /boot/vmlinuz*-desktop gefunden.' fi ]]></source> </script> </chroot-scripts> </scripts> The script works fine, both according to its log and the resulting links. On the finished installation, the /boot/grub/menu.lst ends up to boot not /boot/vmlinuz, but rather /boot/vmlinuz-2.6.31.12-0.2-desktop and the name differs from the one set in the bootloader-section as well. But as long as my problem with stage2 using the wrong kernel is gone, I frankly don't care ;) Antje -- Antje Bendrich (Team IT-Services), Phone +49 40 808077-642 DFN-CERT Services GmbH, https://www.dfn-cert.de/, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Sachsenstraße 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski
participants (2)
-
Antje Bendrich -
Hans-Joachim Ehlers