oem type and oem-recovery set to false...

[John Lund @ EMC]

Using the lastest kiwi builds we are noticing that when we have
<oem-recovery>false</oem-recovery>
in our config.xml, we are still getting a restore option in the boot
menus.
Is this correct? Is there another way to remove the restore option
from the boot menu if we are not creating a recovery partition?

Thank you,
John Lund

[Marcus Schäfer]

Hi,

Hmm, if you set it to false or remove it the image shouldn't have
any recovery menu entry anymore. I checked the code and on a first
look I don't see why it should ignore the value

which config.xml did you adapt ? The one from the original
image description or from an already prepared image tree ?
Did you rebuild the entire image or did you just call
the kiwi create step together with an already prepared
image tree ? The latter would require to change the
config.xml from inside the already prepared tree in
order to let the changes have any effect

Regards,
Marcus
--
Public Key available
gpg --keyserver gpg-keyserver.de --recv-keys 0xCCE3C6A2
-------------------------------------------------------
Marcus Schäfer (Res. & Dev.) SUSE LINUX Products GmbH
Tel: 0911-740 53 0 Maxfeldstrasse 5
FAX: 0911-740 53 479 D-90409 Nürnberg
GF: Jeff Hawn,Jennifer Guild, Felix Imendörffer
HRB: 21284 (AG Nürnberg) Germany
http://www.suse.de
-------------------------------------------------------

[John Lund @ EMC]

Hi Marcus,

Perhaps I am calling the OEM (ISO/USB) boot/install image option by
the wrong thing here. I thought it was the recovery showing up again,
but it seems that I misread the actual title of the option.

When we are booting our current oem type ISO images, we get the
following options:
Boot From Hard Disk
Install/Restore <ImageName>
Failsafe -- Install/Restore <ImageName>

First, is there any way to remove the "Restore" from the Install
option? I don't think that the install from an OEM type ISO has any
way to perform a restore. So I'm not sure how this wording makes
sense here. It has been causing a small bit of confusion for our QA
and testing teams. (Which is why I asked the initial question :-)

Second what is the Failsafe option? I don't see it documented in the
pdf, or online.
Looking at the code, and the boot menus, it looks like that just adds
some more kernel command line options. We don't need this, and it
could cause trouble in our install/boot scenarios.
Is there a way we can turn this option off?

Thank you,
John Lund

[Marcus Schäfer]

Hi John,

> Perhaps I am calling the OEM (ISO/USB) boot/install image option by
> the wrong thing here. I thought it was the recovery showing up again,
> but it seems that I misread the actual title of the option.
>
> When we are booting our current oem type ISO images, we get the
> following options:
> Boot From Hard Disk
> Install/Restore <ImageName>
> Failsafe -- Install/Restore <ImageName>
>
> First, is there any way to remove the "Restore" from the Install
> option? I don't think that the install from an OEM type ISO has any
> way to perform a restore.

Ok now I understand. I think we labeled this Install/Restore because
if you have already installed this image for the first time you can
restore the same thing back to the factory state by just repeating
the install process. So I think this is kind of a restore then
but I'm open for any better wording to express that

> So I'm not sure how this wording makes
> sense here. It has been causing a small bit of confusion for our QA
> and testing teams. (Which is why I asked the initial question :-)

yes we use the word Restore in the oem recovery system as well.
The menu entry 'Restore Factory System' does basically the same
as if you select 'Install/Restore' from the install iso.

> Second what is the Failsafe option? I don't see it documented in the
> pdf, or online.

Failsafe just runs the kernel with 'failsafe' options:
switch of the framebuffer, switch of the object resume feature,
switch off acpi and apm and set ide to not use DMA

> Looking at the code, and the boot menus, it looks like that just adds
> some more kernel command line options. We don't need this, and it
> could cause trouble in our install/boot scenarios.
> Is there a way we can turn this option off?

I'm pretty sure the failsafe mode will not cause trouble in your
testing. failsafe just decreases the kernel performance and _can_
help in very rare cases to overcome hardware problems

But I think you want control over the menu items here. So the
customer is the king and there is a way how you can influence
the contents of any boot menu created by kiwi :-)

*** The following applies to v5.03.x which is not yet released ***

1) specify an editbootconfig script name in your config.xml

<type ... editbootconfig="/absolute/path/to/a/script"/>

It's not required that you use a script, you also can write a C
program and let kiwi call this one. But what is required is the
absolute path. So far kiwi does not search for the program.
If this feature will become popular which I don't hope I will
make it more user friendly ;)

2) the specified script is called prior to _ANY_ bootloader setup
This is important to understand because when you build an install ISO
kiwi also builds the image which the install ISO should install.
That image also has a bootloader on board. Thus there are two
bootloader configurations involved in the process and your
bootconfig script is called twice.

3) The script is called as follows:

system ("cd $tmpdir && bash --norc -c $editBoot");

So you are not in a chroot and you are root. Be careful what you do
in your script and I also strongly recommend to use relative paths
only and pushd/popd to change directories or even better avoid
changing directories at all. kiwi creates the bootloader relevant
files and directories in a tmpdir and copies them at the right
time. editbootconfig allows to interrupt at that point and gives
you the oppurtunity to change everything

4) In order to change the boot menu for an install iso the file
you need to adapt is:

boot/grub/menu.lst

==> relatively to the system call !

The install iso calls isolinux in a way which embeds grub

If you have that in mind you can setup your own bootloader setup
and more... but you also can destroy everything :) That's the reason
why I also did not document it so far

I also know that most of the security people will hit me for
writing such a code but sometimes I think functionality goes before
security and with kiwi you also have to be root prior to any other
task. So one is already in the situation to do everything one wants

Hope that helps

[natcho....@emc.com]

Hi Marcus,

Thanks for the quick response (as usual), much appreciated! I am sure that your suggestion will work as expected, but it looks as a solution of a last resort. Of course we can use it, but since kiwi already handles well bootloader configuration we would prefer to only have the capability to customize the entries and still have kiwi write them.

For example, about the "Failsafe" option - I think that it will be more consistent with the overall kiwi experience if an option "<oem-failsafe>true/false</oem-failsafe>" was added to the kiwi XML schema with the effect that Failsafe entries are written only when the option is true - from my inspection of KIWILinuxRC.sh it looks like it will require several if statements to be added in the code. I would have submitted a patch, but I am not familiar with the process to modify the XML schema :-).

On a related note, regarding

"I'm pretty sure the failsafe mode will not cause trouble in your testing. failsafe just decreases the kernel performance and _can_ help in very rare cases to overcome hardware problems"

I completely agree with you from a developer's perspective, but our kiwi-built system are sometimes serviced by people with limited Linux experience, so I can almost guarantee that no matter what we document, someone will look at the "failsafe" option that is presented to them and will think "Yes - this is a great idea - this will make the system safe, so lets do this!" and then the customer will escalate to our engineering organization that the system has poor performance - or even worse - they may decide that ours is a slow, crappy product and kick us out :-). At the same time, we deliver our product only on qualified hardware systems.

Regarding the "Install/Restore" wording, the "restore" word is often associated with "backup". In our opinion, naming the option just "Install" is sufficient and the possibility to use the option for "factory reset" can just be documented by the respective product team for their kiwi images. An alternative that requires more kiwi changes is to add something like "<oem-install-title></oem-install-title> that can be used to customize the string if a kiwi developer decides to do so.

Let us know what you think.
Thanks,
Natcho

[Marcus Schäfer]

Hi Natcho,

> Thanks for the quick response (as usual), much appreciated! I am sure that your suggestion will work as expected, but it looks as a solution of a last resort. Of course we can use it, but since kiwi already handles well bootloader configuration we would prefer to only have the capability to customize the entries and still have kiwi write them.
>
> For example, about the "Failsafe" option - I think that it will be more consistent with the overall kiwi experience if an option "<oem-failsafe>true/false</oem-failsafe>" was added to the kiwi XML schema with the effect that Failsafe entries are written only when the option is true - from my inspection of KIWILinuxRC.sh it looks like it will require several if statements to be added in the code. I would have submitted a patch, but I am not familiar with the process to modify the XML schema :-).
>
> On a related note, regarding
> "I'm pretty sure the failsafe mode will not cause trouble in your testing. failsafe just decreases the kernel performance and _can_ help in very rare cases to overcome hardware problems"
> I completely agree with you from a developer's perspective, but our kiwi-built system are sometimes serviced by people with limited Linux experience, so I can almost guarantee that no matter what we document, someone will look at the "failsafe" option that is presented to them and will think "Yes - this is a great idea - this will make the system safe, so lets do this!" and then the customer will escalate to our engineering organization that the system has poor performance - or even worse - they may decide that ours is a slow, crappy product and kick us out :-). At the same time, we deliver our product only on qualified hardware systems.
>
> Regarding the "Install/Restore" wording, the "restore" word is often associated with "backup". In our opinion, naming the option just "Install" is sufficient and the possibility to use the option for "factory reset" can just be documented by the respective product team for their kiwi images. An alternative that requires more kiwi changes is to add something like "<oem-install-title></oem-install-title> that can be used to customize the string if a kiwi developer decides to do so.
>
> Let us know what you think.

I understand your points and they make sense to me too. You are right
with the editbootconfig feature as a last resort solution. I will
think about your suggestions when I'm back from a short volleyball
oriented trip on Wednesday :)

Thanks for your feedback and the customer view, that's very
valuable information for me

[Marcus Schäfer]

Hi,

> For example, about the "Failsafe" option - I think that it will be more consistent with the overall kiwi experience if an option "<oem-failsafe>true/false</oem-failsafe>" was added to the kiwi XML schema with the effect that Failsafe entries are written only when the option is true - from my inspection of KIWILinuxRC.sh it looks like it will require several if statements to be added in the code. I would have submitted a patch, but I am not familiar with the process to modify the XML schema :-).

I added the following to the latest version of kiwi:

<type ... installprovidefailsafe="true/false"/>

> Regarding the "Install/Restore" wording, the "restore" word is often associated with "backup". In our opinion, naming the option just "Install" is sufficient and the possibility to use the option for "factory reset" can just be documented by the respective product team for their kiwi images. An alternative that requires more kiwi changes is to add something like "<oem-install-title></oem-install-title> that can be used to customize the string if a kiwi developer decides to do so.
>

I don't like to make this entry a customizable text but I adapted
it according to your suggestion. So it says only "Install ..."

All this in kiwi >= v5.03.2

Thanks,

[Jay Nitikman]

This is nice, but I really want this feature for the oemboot and vmxboot 'include' scripts. Your change only affects the kiwi installer, not the boot loader in my image. I am manually editing menu.lst in my preCallInit.sh script to remove the Fail Safe option.

-----------------
Jay Nitikman
jay.ni...@virtualinstruments.com

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential material. If you receive this material/information in error,please contact the sender immediately and permanently delete or destroy the material/information.

[Marcus Schäfer]

Hi,

> This is nice, but I really want this feature for the oemboot and vmxboot 'include' scripts. Your change only affects the kiwi installer, not the boot loader in my image. I am manually editing menu.lst in my preCallInit.sh script to remove the Fail Safe option.

But you can influence the bootloader setup for your appliance on first
boot in some ways. with yast2, by a custom overlay script in /etc/boot.local
maybe more...

The failsafe entry is created in any case on a standard suse installation
So I'd like to stay compatible here with what the standard way sets up.
The install media is a kiwi only thing and different to the distribution
DVD so it was not a big deal to change/custom it

Let me know what you think