[Sisuite-devel] Integrating kexec with SystemImager (was Re: SystemConfigurator and SystemImager)

[Bernard Li]

IMO it should work without SC, too. SC has some advantages in autodetecting
and configuring modules.conf, but this is not mandatory and one could use
other methods to do the post-config. I think you can take it out from the spec
file's Requires: (guess this is what you want, right?).

Actually no :-)

I am integrating kexec with SystemImager, this will give the user a
new option where they do not need to reboot and it will start up the
imaged kernel automatically. I have tested this manually and it
works, the only issue I am facing is how to accurately retrieve the
append and initrd options to pass to kexec (--append and --initrd).

For SystemImager, SystemConfigurator is the gatekeeper for these kind
of information, so I was thinking of using SystemConfigurator to
gather this info, but this is assuming that all users of SystemImager
will use SystemConfigurator so I would just like to confirm this.

I will probably send an email to Sean Dague to see if he has any other
suggestions for me.

I plan to add a new post-install action called "kexec", which will
automatically boot up the imaged kernel -- if you have any other
suggestions on how this should be implemented, please feel free to let
me know.

Thanks,

Bernard

[Erich Focht]

Hi Bernard,

I heard of the work on integrating PS3s, and if you integrate a kexec based
boot into systemimager, I guess I'll have to integrate a configurator module
for it into systemconfigurator. Can you give me any details on the
configuration files needed for kexec/kboot? How they look like, where they
are, what program is used to install them or so?

Thanks,
best regards,
Erich

Post by Bernard Li

IMO it should work without SC, too. SC has some advantages in autodetecting
and configuring modules.conf, but this is not mandatory and one could use
other methods to do the post-config. I think you can take it out from the spec
file's Requires: (guess this is what you want, right?).

Actually no :-)
I am integrating kexec with SystemImager, this will give the user a
new option where they do not need to reboot and it will start up the
imaged kernel automatically. I have tested this manually and it
works, the only issue I am facing is how to accurately retrieve the
append and initrd options to pass to kexec (--append and --initrd).
For SystemImager, SystemConfigurator is the gatekeeper for these kind
of information, so I was thinking of using SystemConfigurator to
gather this info, but this is assuming that all users of SystemImager
will use SystemConfigurator so I would just like to confirm this.
I will probably send an email to Sean Dague to see if he has any other
suggestions for me.
I plan to add a new post-install action called "kexec", which will
automatically boot up the imaged kernel -- if you have any other
suggestions on how this should be implemented, please feel free to let
me know.
Thanks,
Bernard

[Bernard Li]

Hi Erich:

Actually this has nothing to do with PS3. PS3 uses kboot, which is a
bootloader based on kexec, however currently I am only interested in
integrating kexec with SystemImager.

It is somewhat difficult to work on kboot for PS3 without the physical
hardware :-)

The idea of integrating kexec with SystemImager is that after the
imaging process, you would umount /a and you would then run kexec to
boot the just imaged kernel (you need to copy the kernel and initrd to
/tmp first).

The command is something like:

kexec --append="root=/dev/hda6 ro" --initrd=/tmp/sc-initrd.img -t
bzImage --force /tmp/vmlinuz

This would then boot up the just imaged kernel without reboot, and it
would even tell si_monitor that it has rebooted since it goes through
the entire process of booting up the kernel, doing init etc.

So for now, you don't need to do anything in regards to
SystemConfigurator, unless you want to help me parse for the info
which I need ;-) (--append and --initrd options above).

I hope that I am clear on this, please let me know if you have any
other questions.

Cheers,

Bernard

Post by Erich Focht
Hi Bernard,
I heard of the work on integrating PS3s, and if you integrate a kexec based
boot into systemimager, I guess I'll have to integrate a configurator module
for it into systemconfigurator. Can you give me any details on the
configuration files needed for kexec/kboot? How they look like, where they
are, what program is used to install them or so?
Thanks,
best regards,
Erich

Post by Bernard Li

IMO it should work without SC, too. SC has some advantages in autodetecting
and configuring modules.conf, but this is not mandatory and one could use
other methods to do the post-config. I think you can take it out from the spec
file's Requires: (guess this is what you want, right?).

Actually no :-)
I am integrating kexec with SystemImager, this will give the user a
new option where they do not need to reboot and it will start up the
imaged kernel automatically. I have tested this manually and it
works, the only issue I am facing is how to accurately retrieve the
append and initrd options to pass to kexec (--append and --initrd).
For SystemImager, SystemConfigurator is the gatekeeper for these kind
of information, so I was thinking of using SystemConfigurator to
gather this info, but this is assuming that all users of SystemImager
will use SystemConfigurator so I would just like to confirm this.
I will probably send an email to Sean Dague to see if he has any other
suggestions for me.
I plan to add a new post-install action called "kexec", which will
automatically boot up the imaged kernel -- if you have any other
suggestions on how this should be implemented, please feel free to let
me know.
Thanks,
Bernard

[Erich Focht]

Hi Bernard,

okay, I got it. Sounds good and I'll have a look at SC. You'll need some tiny
code which uses the SC libs to get the info...

I'm forwarding this email to oscar-devel and DongInn, maybe DongInn can pass
some info on kboot on his PS3.

Best regards,
Erich

Post by Bernard Li
Actually this has nothing to do with PS3. PS3 uses kboot, which is a
bootloader based on kexec, however currently I am only interested in
integrating kexec with SystemImager.
It is somewhat difficult to work on kboot for PS3 without the physical
hardware :-)
The idea of integrating kexec with SystemImager is that after the
imaging process, you would umount /a and you would then run kexec to
boot the just imaged kernel (you need to copy the kernel and initrd to
/tmp first).
kexec --append="root=/dev/hda6 ro" --initrd=/tmp/sc-initrd.img -t
bzImage --force /tmp/vmlinuz
This would then boot up the just imaged kernel without reboot, and it
would even tell si_monitor that it has rebooted since it goes through
the entire process of booting up the kernel, doing init etc.
So for now, you don't need to do anything in regards to
SystemConfigurator, unless you want to help me parse for the info
which I need ;-) (--append and --initrd options above).
I hope that I am clear on this, please let me know if you have any
other questions.
Cheers,
Bernard

Post by Erich Focht
Hi Bernard,
I heard of the work on integrating PS3s, and if you integrate a kexec based
boot into systemimager, I guess I'll have to integrate a configurator module
for it into systemconfigurator. Can you give me any details on the
configuration files needed for kexec/kboot? How they look like, where they
are, what program is used to install them or so?
Thanks,
best regards,
Erich

Post by Bernard Li

IMO it should work without SC, too. SC has some advantages in autodetecting
and configuring modules.conf, but this is not mandatory and one could use
other methods to do the post-config. I think you can take it out from the spec
file's Requires: (guess this is what you want, right?).

Actually no :-)
I am integrating kexec with SystemImager, this will give the user a
new option where they do not need to reboot and it will start up the
imaged kernel automatically. I have tested this manually and it
works, the only issue I am facing is how to accurately retrieve the
append and initrd options to pass to kexec (--append and --initrd).
For SystemImager, SystemConfigurator is the gatekeeper for these kind
of information, so I was thinking of using SystemConfigurator to
gather this info, but this is assuming that all users of SystemImager
will use SystemConfigurator so I would just like to confirm this.
I will probably send an email to Sean Dague to see if he has any other
suggestions for me.
I plan to add a new post-install action called "kexec", which will
automatically boot up the imaged kernel -- if you have any other
suggestions on how this should be implemented, please feel free to let
me know.
Thanks,
Bernard

[Bernard Li]

Hi Erich:

Thanks for offering to help - I really appreciate it!

However, I have a feeling that I need to touch all the Boot/*.pm libs
for SystemConfigurator since the code is different for each
bootloader. But perhaps you or Sean will have better ideas, since you
know the code much better than I do.

Cheers,

Bernard

Post by Erich Focht
Hi Bernard,
okay, I got it. Sounds good and I'll have a look at SC. You'll need some tiny
code which uses the SC libs to get the info...
I'm forwarding this email to oscar-devel and DongInn, maybe DongInn can pass
some info on kboot on his PS3.
Best regards,
Erich

Post by Bernard Li
Actually this has nothing to do with PS3. PS3 uses kboot, which is a
bootloader based on kexec, however currently I am only interested in
integrating kexec with SystemImager.
It is somewhat difficult to work on kboot for PS3 without the physical
hardware :-)
The idea of integrating kexec with SystemImager is that after the
imaging process, you would umount /a and you would then run kexec to
boot the just imaged kernel (you need to copy the kernel and initrd to
/tmp first).
kexec --append="root=/dev/hda6 ro" --initrd=/tmp/sc-initrd.img -t
bzImage --force /tmp/vmlinuz
This would then boot up the just imaged kernel without reboot, and it
would even tell si_monitor that it has rebooted since it goes through
the entire process of booting up the kernel, doing init etc.
So for now, you don't need to do anything in regards to
SystemConfigurator, unless you want to help me parse for the info
which I need ;-) (--append and --initrd options above).
I hope that I am clear on this, please let me know if you have any
other questions.
Cheers,
Bernard

Post by Erich Focht
Hi Bernard,
I heard of the work on integrating PS3s, and if you integrate a kexec based
boot into systemimager, I guess I'll have to integrate a configurator module
for it into systemconfigurator. Can you give me any details on the
configuration files needed for kexec/kboot? How they look like, where they
are, what program is used to install them or so?
Thanks,
best regards,
Erich

Post by Bernard Li

IMO it should work without SC, too. SC has some advantages in autodetecting
and configuring modules.conf, but this is not mandatory and one could use
other methods to do the post-config. I think you can take it out from the spec
file's Requires: (guess this is what you want, right?).

Actually no :-)
I am integrating kexec with SystemImager, this will give the user a
new option where they do not need to reboot and it will start up the
imaged kernel automatically. I have tested this manually and it
works, the only issue I am facing is how to accurately retrieve the
append and initrd options to pass to kexec (--append and --initrd).
For SystemImager, SystemConfigurator is the gatekeeper for these kind
of information, so I was thinking of using SystemConfigurator to
gather this info, but this is assuming that all users of SystemImager
will use SystemConfigurator so I would just like to confirm this.
I will probably send an email to Sean Dague to see if he has any other
suggestions for me.
I plan to add a new post-install action called "kexec", which will
automatically boot up the imaged kernel -- if you have any other
suggestions on how this should be implemented, please feel free to let
me know.
Thanks,
Bernard

[Erich Focht]

Hi Bernard,

you don't need to touch any SC component. You just need a tiny program that
uses SC libs to read and interpret the systemconfig.conf of the image. In the
latest systemconfigurator I added a handy tool for doing this. I think I can
script you something passing you all you need in a few minutes.

By the way: why do you need to unmount /a? Can't you boot directly from the
installed kernel and initrd? I'm afraid the space they take in the /ramfs will
stay locked, won't it?

Regards,
Erich

Post by Bernard Li
Thanks for offering to help - I really appreciate it!
However, I have a feeling that I need to touch all the Boot/*.pm libs
for SystemConfigurator since the code is different for each
bootloader. But perhaps you or Sean will have better ideas, since you
know the code much better than I do.
Cheers,
Bernard

Post by Erich Focht
Hi Bernard,
okay, I got it. Sounds good and I'll have a look at SC. You'll need some tiny
code which uses the SC libs to get the info...
I'm forwarding this email to oscar-devel and DongInn, maybe DongInn can pass
some info on kboot on his PS3.
Best regards,
Erich

Post by Bernard Li
Actually this has nothing to do with PS3. PS3 uses kboot, which is a
bootloader based on kexec, however currently I am only interested in
integrating kexec with SystemImager.
It is somewhat difficult to work on kboot for PS3 without the physical
hardware :-)
The idea of integrating kexec with SystemImager is that after the
imaging process, you would umount /a and you would then run kexec to
boot the just imaged kernel (you need to copy the kernel and initrd to
/tmp first).
kexec --append="root=/dev/hda6 ro" --initrd=/tmp/sc-initrd.img -t
bzImage --force /tmp/vmlinuz
This would then boot up the just imaged kernel without reboot, and it
would even tell si_monitor that it has rebooted since it goes through
the entire process of booting up the kernel, doing init etc.
So for now, you don't need to do anything in regards to
SystemConfigurator, unless you want to help me parse for the info
which I need ;-) (--append and --initrd options above).
I hope that I am clear on this, please let me know if you have any
other questions.
Cheers,
Bernard

Post by Erich Focht
Hi Bernard,
I heard of the work on integrating PS3s, and if you integrate a kexec based
boot into systemimager, I guess I'll have to integrate a configurator module
for it into systemconfigurator. Can you give me any details on the
configuration files needed for kexec/kboot? How they look like, where they
are, what program is used to install them or so?
Thanks,
best regards,
Erich

Post by Bernard Li

IMO it should work without SC, too. SC has some advantages in autodetecting
and configuring modules.conf, but this is not mandatory and one could use
other methods to do the post-config. I think you can take it out from the spec
file's Requires: (guess this is what you want, right?).

Actually no :-)
I am integrating kexec with SystemImager, this will give the user a
new option where they do not need to reboot and it will start up the
imaged kernel automatically. I have tested this manually and it
works, the only issue I am facing is how to accurately retrieve the
append and initrd options to pass to kexec (--append and --initrd).
For SystemImager, SystemConfigurator is the gatekeeper for these kind
of information, so I was thinking of using SystemConfigurator to
gather this info, but this is assuming that all users of SystemImager
will use SystemConfigurator so I would just like to confirm this.
I will probably send an email to Sean Dague to see if he has any other
suggestions for me.
I plan to add a new post-install action called "kexec", which will
automatically boot up the imaged kernel -- if you have any other
suggestions on how this should be implemented, please feel free to let
me know.
Thanks,
Bernard

[Bernard Li]

Post by Erich Focht
you don't need to touch any SC component. You just need a tiny program that
uses SC libs to read and interpret the systemconfig.conf of the image. In the
latest systemconfigurator I added a handy tool for doing this. I think I can
script you something passing you all you need in a few minutes.

Great -- I will wait for it then :-)

Post by Erich Focht
By the way: why do you need to unmount /a? Can't you boot directly from the
installed kernel and initrd? I'm afraid the space they take in the /ramfs will
stay locked, won't it?

If I do not umount /a, then when I kexec the new kernel, it will
complain that the disk is not umounted properly, etc.. I will need to
investigate whether it actually hangs onto the memory if I copy the
kernel/ramdisk to /tmp.

Thanks,

Bernard

[Erich Focht]

Hi Bernard,

please copy the two attached scripts into your image to some place like
/usr/bin. scconf_tool is a slightly modified version of what comes with
systeminstaller-oscar. scconf_bootinfo gives you the info on the kernel,
initrd, root device and append path.

You'll need to do (in the autoinstall script):

a=`chroot /a /usr/bin/scconf_bootinfo`
kernel=`echo $a | cut -d" " -f1`
dev=`echo $a | cut -d" " -f2`
initrd=`echo $a | cut -d" " -f3`
append=`echo $a | cut -d" " -f4-`

...


If this works for you I will add the two scripts to systemconfigurator and
remove scconf_tool from systeminstaller-oscar.

Please be aware that the paths printed need to be prefixed with /a. There
might be a problem when no absolute paths are used in the systemconfig.conf
file or when the path is relative to the /boot directory. In that case you'll
need to prefix the kernel and initrd paths with /boot first.

Best regards,
Erich

Post by Bernard Li

Post by Erich Focht
you don't need to touch any SC component. You just need a tiny program that
uses SC libs to read and interpret the systemconfig.conf of the image. In the
latest systemconfigurator I added a handy tool for doing this. I think I can
script you something passing you all you need in a few minutes.

Great -- I will wait for it then :-)

Post by Erich Focht
By the way: why do you need to unmount /a? Can't you boot directly from the
installed kernel and initrd? I'm afraid the space they take in the /ramfs will
stay locked, won't it?

If I do not umount /a, then when I kexec the new kernel, it will
complain that the disk is not umounted properly, etc.. I will need to
investigate whether it actually hangs onto the memory if I copy the
kernel/ramdisk to /tmp.
Thanks,
Bernard

[Bernard Li]

Hi Erich:

scconf_bootinfo only returned two values, the kernel and the rootdev,
initrd and append were not outputed.

This is what my image's /etc/systemconfig/systemconfig.conf looks like:

# systemconfig.conf written by systeminstaller.
CONFIGBOOT = YES
CONFIGRD = YES

[BOOT]
ROOTDEV = /dev/hda6
BOOTDEV = /dev/hda
DEFAULTBOOT = 2.6.18-1.2798.fc6

[KERNEL0]
PATH = /boot/vmlinuz-2.6.18-1.2798.fc6
LABEL = 2.6.18-1.2798.fc6

It does not have info about append/initrd -- is yours different?

Thanks,

Bernard

Post by Erich Focht
Hi Bernard,
please copy the two attached scripts into your image to some place like
/usr/bin. scconf_tool is a slightly modified version of what comes with
systeminstaller-oscar. scconf_bootinfo gives you the info on the kernel,
initrd, root device and append path.
a=`chroot /a /usr/bin/scconf_bootinfo`
kernel=`echo $a | cut -d" " -f1`
dev=`echo $a | cut -d" " -f2`
initrd=`echo $a | cut -d" " -f3`
append=`echo $a | cut -d" " -f4-`
...
If this works for you I will add the two scripts to systemconfigurator and
remove scconf_tool from systeminstaller-oscar.
Please be aware that the paths printed need to be prefixed with /a. There
might be a problem when no absolute paths are used in the systemconfig.conf
file or when the path is relative to the /boot directory. In that case you'll
need to prefix the kernel and initrd paths with /boot first.
Best regards,
Erich

Post by Bernard Li

Post by Erich Focht
you don't need to touch any SC component. You just need a tiny program that
uses SC libs to read and interpret the systemconfig.conf of the image. In the
latest systemconfigurator I added a handy tool for doing this. I think I can
script you something passing you all you need in a few minutes.

Great -- I will wait for it then :-)

Post by Erich Focht
By the way: why do you need to unmount /a? Can't you boot directly from the
installed kernel and initrd? I'm afraid the space they take in the /ramfs will
stay locked, won't it?

If I do not umount /a, then when I kexec the new kernel, it will
complain that the disk is not umounted properly, etc.. I will need to
investigate whether it actually hangs onto the memory if I copy the
kernel/ramdisk to /tmp.
Thanks,
Bernard

[Erich Focht]

Hi Bernard,

your systemconfig.conf has no INITRD entry. Mine had one. I see that this is
an issue and will try to autodetect one. For now please try the new attached
script (it adds some append string and shows you that the initrd is empty).

Regards,
Erich

Post by Bernard Li
# systemconfig.conf written by systeminstaller.
CONFIGBOOT = YES
CONFIGRD = YES
[BOOT]
        ROOTDEV = /dev/hda6
        BOOTDEV = /dev/hda
        DEFAULTBOOT = 2.6.18-1.2798.fc6
[KERNEL0]
        PATH = /boot/vmlinuz-2.6.18-1.2798.fc6
        LABEL = 2.6.18-1.2798.fc6

[Erich Focht]

Hi Bernard,

I have a smart version now. Since you just use this in conjunction with
systemconfigurator if the INITRD is missing, SC will generate an initrd.

Attached...

Would be happy about feedback.

Regards,
Erich

Post by Erich Focht
Hi Bernard,
your systemconfig.conf has no INITRD entry. Mine had one. I see that this is
an issue and will try to autodetect one. For now please try the new attached
script (it adds some append string and shows you that the initrd is empty).
Regards,
Erich

Post by Bernard Li
# systemconfig.conf written by systeminstaller.
CONFIGBOOT = YES
CONFIGRD = YES
[BOOT]
        ROOTDEV = /dev/hda6
        BOOTDEV = /dev/hda
        DEFAULTBOOT = 2.6.18-1.2798.fc6
[KERNEL0]
        PATH = /boot/vmlinuz-2.6.18-1.2798.fc6
        LABEL = 2.6.18-1.2798.fc6

[Bernard Li]

Hi Erich:

Just tested it -- it works. But as you mentioned, now the kernel and
initrd path is prepended with /boot. I will use basename to strip
this, as I need to copy them to /tmp (I will need to figure out if
this continues to consume the memory after kexec).

I'll code it up into the autoinstallscript tonight.

BTW, I suppose for your case, your systemconfig.conf had INITRD
entries because the image is from a golden client which is not
generated by SystemInstaller?

Thanks,

Bernard

Post by Erich Focht
Hi Bernard,
I have a smart version now. Since you just use this in conjunction with
systemconfigurator if the INITRD is missing, SC will generate an initrd.
Attached...
Would be happy about feedback.
Regards,
Erich

Post by Erich Focht
Hi Bernard,
your systemconfig.conf has no INITRD entry. Mine had one. I see that this is
an issue and will try to autodetect one. For now please try the new attached
script (it adds some append string and shows you that the initrd is empty).
Regards,
Erich

Post by Bernard Li
# systemconfig.conf written by systeminstaller.
CONFIGBOOT = YES
CONFIGRD = YES
[BOOT]
ROOTDEV = /dev/hda6
BOOTDEV = /dev/hda
DEFAULTBOOT = 2.6.18-1.2798.fc6
[KERNEL0]
PATH = /boot/vmlinuz-2.6.18-1.2798.fc6
LABEL = 2.6.18-1.2798.fc6

[Bernard Li]

Post by Bernard Li
Just tested it -- it works. But as you mentioned, now the kernel and
initrd path is prepended with /boot. I will use basename to strip
this, as I need to copy them to /tmp (I will need to figure out if
this continues to consume the memory after kexec).

I have updated the autoinstallscript generation and now if I specify
post-install action to be kexec, it will load up the kernel correctly
without the need to reboot.

I checked the memory consumption, it is as if the node was rebooted.

I just need to figure out how to modify the "font" of the text... you
know how SystemImager boots up in this funny font/screen size...

I will check my changes into trunk this weekend, or tomorrow if I have time.

Do you plan to cut a release for SystemConfigurator any time soon? I
guess I'll need to make a version requirement for SystemConfigurator
in the updated SystemImager...

Thanks,

Bernard

[Bernard Li]

Post by Bernard Li
I just need to figure out how to modify the "font" of the text... you
know how SystemImager boots up in this funny font/screen size...

Okay, this is caused by SystemImager kernel being loaded with
'vga=extended'. Changing the default to 'vga=normal' would work.

I tried the --reset-vga option for kexec, the screen is now full
height, although the spacing between the lines are still a bit off,
but I guess for now it'll have to be that way.

BTW, I'll need to also modify SystemInstaller for OSCAR to take
advantage of this new functionality.

Cheers,

Bernard

[Andrea Righi]

Post by Bernard Li
Do you plan to cut a release for SystemConfigurator any time soon? I
guess I'll need to make a version requirement for SystemConfigurator
in the updated SystemImager...

I would propose to tag a new stable release of systemconfigurator soon
(ok the same for systemimager 3.8.1 but I would like to fix one or two
potential bugs before...). Actually I tested the SC trunk in a lot of
cases and it seems to work very well.

Regarding the kexec support what do you think about creating a kind of
"plugin" for systemconfigurator that contains all the required scripts
made by Erich? I mean for now we could create a separate package like
"systemconfigurator-kexec-plugin" that requires systemconfigurator and
adds the kexec functionalities in the image.

When you use the post-install kexec action (with si_getimage or
si_mkautoinstallscript) a check will be made in to see if the plugin is
installed into the target image... for this check it's sufficient to see
if the new scripts are present or maybe we could simply touch a file in
/etc/systemconfig or add an entry in /etc/systemconfig/systemconfig.conf...

My 2 cents...

Regards,
-Andrea

[Erich Focht]

Hi,

I am indeed planning to tag a new version of systemconfigurator soon. The
version number will be 2.2.9. It will contain the two tools. At the same time
I'll need to tag another systeminstaller-oscar version and take out
scconf_tool from there.

[Erich Focht]

Hi Bernard,

I managed to update the systemconfigurator package in the svn.systemimager.org
repository. Could you please try it?

There is one significant change which touches the systemimager integration:
in order to ease the updating and avoid conflicts between the names, I added
/usr/bin/scconf-tool to systemconfigurator. This won't conflict with
/usr/bin/scconf_tool which is right now coming with sin-oscar. As I didn't
like the name asymmetry (scconf-tool and scconf_bootinfo, I also renamed the
later one to scconf-bootinfo. scconf-bootinfo is rewritten (to perl) and adds
/boot/ to the kernel or initrd names which are no absolute paths.

I changed the systemimager integration accordingly.

Best regards,
Erich

Post by Bernard Li
scconf_bootinfo only returned two values, the kernel and the rootdev,
initrd and append were not outputed.
# systemconfig.conf written by systeminstaller.
CONFIGBOOT = YES
CONFIGRD = YES
[BOOT]
ROOTDEV = /dev/hda6
BOOTDEV = /dev/hda
DEFAULTBOOT = 2.6.18-1.2798.fc6
[KERNEL0]
PATH = /boot/vmlinuz-2.6.18-1.2798.fc6
LABEL = 2.6.18-1.2798.fc6
It does not have info about append/initrd -- is yours different?
Thanks,
Bernard

Post by Erich Focht
Hi Bernard,
please copy the two attached scripts into your image to some place like
/usr/bin. scconf_tool is a slightly modified version of what comes with
systeminstaller-oscar. scconf_bootinfo gives you the info on the kernel,
initrd, root device and append path.
a=`chroot /a /usr/bin/scconf_bootinfo`
kernel=`echo $a | cut -d" " -f1`
dev=`echo $a | cut -d" " -f2`
initrd=`echo $a | cut -d" " -f3`
append=`echo $a | cut -d" " -f4-`
...
If this works for you I will add the two scripts to systemconfigurator and
remove scconf_tool from systeminstaller-oscar.
Please be aware that the paths printed need to be prefixed with /a. There
might be a problem when no absolute paths are used in the systemconfig.conf
file or when the path is relative to the /boot directory. In that case you'll
need to prefix the kernel and initrd paths with /boot first.
Best regards,
Erich

Post by Bernard Li

Post by Erich Focht
you don't need to touch any SC component. You just need a tiny program that
uses SC libs to read and interpret the systemconfig.conf of the image. In the
latest systemconfigurator I added a handy tool for doing this. I think I can
script you something passing you all you need in a few minutes.

Great -- I will wait for it then :-)

Post by Erich Focht
By the way: why do you need to unmount /a? Can't you boot directly from the
installed kernel and initrd? I'm afraid the space they take in the /ramfs will
stay locked, won't it?

If I do not umount /a, then when I kexec the new kernel, it will
complain that the disk is not umounted properly, etc.. I will need to
investigate whether it actually hangs onto the memory if I copy the
kernel/ramdisk to /tmp.
Thanks,
Bernard

[Andrea Righi]

Post by Erich Focht
Hi Bernard,
I managed to update the systemconfigurator package in the svn.systemimager.org
repository. Could you please try it?
in order to ease the updating and avoid conflicts between the names, I added
/usr/bin/scconf-tool to systemconfigurator. This won't conflict with
/usr/bin/scconf_tool which is right now coming with sin-oscar. As I didn't
like the name asymmetry (scconf-tool and scconf_bootinfo, I also renamed the
later one to scconf-bootinfo. scconf-bootinfo is rewritten (to perl) and adds
/boot/ to the kernel or initrd names which are no absolute paths.
I changed the systemimager integration accordingly.
Best regards,
Erich

Hi Erich,

I tested the new systemconfigurator and kexec stuff with suse 10.0, but
I've found a couple of problems.

First issue is that I have to manually create the file
/etc/systemconfig/systemconfig.conf in my image, I'm not using the
OSCAR-way to create images (via systeminstaller), I'm just using the
"standard" way of using systemimager, cloning the image from a golden
client. But this is not a critical problem, I'm trying to write a simple
UYOK-based script to automatically generate the file with the
appropriate kernel, initrd and append string. This script will be used
by si_prepareclient.

Anyway here is my systemconfig.conf file:

-----------------------------
[BOOT]
ROOTDEV = /dev/systemvg/rootlv
BOOTDEV = /dev/hda
DEFAULTBOOT = linux

[KERNEL0]
LABEL = linux
PATH = /boot/vmlinuz
INITRD = /boot/initrd
-----------------------------

The SC problem is that it's not able to detect the correct initrd to use
for the reboot (via scconf-bootinfo). It says:
/boot/sc-initrd-2.6.13-15-default.gz but that's wrong. Do you know how
to fix this?

Another issue is that systemconfigurator seems to be more slow now,
respect to the versions before r666 (trunk). Where's the bottleneck? do
you have an idea?

Thanks,
-Andrea

[Erich Focht]

Post by Andrea Righi
Hi Erich,
I tested the new systemconfigurator and kexec stuff with suse 10.0, but
I've found a couple of problems.
First issue is that I have to manually create the file
/etc/systemconfig/systemconfig.conf in my image, I'm not using the
OSCAR-way to create images (via systeminstaller), I'm just using the
"standard" way of using systemimager, cloning the image from a golden
client. But this is not a critical problem, I'm trying to write a simple
UYOK-based script to automatically generate the file with the
appropriate kernel, initrd and append string. This script will be used
by si_prepareclient.
-----------------------------
[BOOT]
ROOTDEV = /dev/systemvg/rootlv
BOOTDEV = /dev/hda
DEFAULTBOOT = linux
[KERNEL0]
LABEL = linux
PATH = /boot/vmlinuz
INITRD = /boot/initrd
-----------------------------
The SC problem is that it's not able to detect the correct initrd to use
/boot/sc-initrd-2.6.13-15-default.gz but that's wrong. Do you know how
to fix this?

Starnge. I'll look into it. The sc-initrd... is only selected when INITRD is
unset, so I wonder why this happens.

Post by Andrea Righi
Another issue is that systemconfigurator seems to be more slow now,
respect to the versions before r666 (trunk). Where's the bottleneck? do
you have an idea?

The only change in logic is an extension of the --no-floppy check. The grub
class is checking for --no-floppy right at load time, not only in
install_loader(). The reason is that there are "grub" commands which don't
support --no-floppy (I had an RHEL3 installation with this problem), so we
need to check centrally. Maybe this is the reason.

Best regards,
Erich

[Erich Focht]

Post by Andrea Righi
First issue is that I have to manually create the file
/etc/systemconfig/systemconfig.conf in my image, I'm not using the
OSCAR-way to create images (via systeminstaller), I'm just using the
"standard" way of using systemimager, cloning the image from a golden
client. But this is not a critical problem, I'm trying to write a simple
UYOK-based script to automatically generate the file with the
appropriate kernel, initrd and append string. This script will be used
by si_prepareclient.
-----------------------------
[BOOT]
ROOTDEV = /dev/systemvg/rootlv
BOOTDEV = /dev/hda
DEFAULTBOOT = linux
[KERNEL0]
LABEL = linux
PATH = /boot/vmlinuz
INITRD = /boot/initrd
-----------------------------

This is fixed now in trunk. Maybe you want to check.

Can you quantify how much time longer the systemconfigurator step takes?
I re-added zipl support such that all tests succeed now, again. Maybe that's
also a problem.

Regards,
Erich

[Andrea Righi]

Post by Erich Focht

Post by Andrea Righi
First issue is that I have to manually create the file
/etc/systemconfig/systemconfig.conf in my image, I'm not using the
OSCAR-way to create images (via systeminstaller), I'm just using the
"standard" way of using systemimager, cloning the image from a golden
client. But this is not a critical problem, I'm trying to write a simple
UYOK-based script to automatically generate the file with the
appropriate kernel, initrd and append string. This script will be used
by si_prepareclient.
-----------------------------
[BOOT]
ROOTDEV = /dev/systemvg/rootlv
BOOTDEV = /dev/hda
DEFAULTBOOT = linux
[KERNEL0]
LABEL = linux
PATH = /boot/vmlinuz
INITRD = /boot/initrd
-----------------------------

This is fixed now in trunk. Maybe you want to check.

Thanks Erich! It seems to work very well now. I'd like to include my
UYOK-based script soon in systemimager to automagically generate the
systemconfig.conf in the image using the golden-client approach.

Post by Erich Focht
Can you quantify how much time longer the systemconfigurator step takes?
I re-added zipl support such that all tests succeed now, again. Maybe that's
also a problem.

I use a virtual machine (with vmplayer) for my tests, so maybe the
latencies that I see are not so meaningful using a real hw environment.

Anyway, a typical installation using the standard BOEL kernel+initrd.img
and a ~650MB image needed 3-4min, now I need 8min, but repeating my
tests I've found that it's not a systemconfigurator issue... it's the
pci-automod overhead. I think we can work and spend some time to
optimize it, but it's not a critical problem for now, the advantages of
pci-automod respect to discover are huge, so I would consider this
overhead a minor side effect.

Thanks,
-Andrea