Bug 151501

Created attachment 68842 [details]
y2log file

just for information. If we don't fix that, we can't keep the "cloning at the end of a manual installation" feature.

I don't know how important that is for SL10.1 but I think it's a blocker for SLES.

Higher Severity, it is very important for SLES.

Uwe, do you mean this part:

[...]
<bootloader>
    <activate config:type="boolean">false</activate>
    <global>
[...]

right?
(I'm not really common with autoYaST)

The autoyast documentation doesn't even mention this tag, so I'm guessing this is to activate the bootloader partition?

yes, that's the tag that I mean. I don't know what that tag is doing. I can't know all tags of all yast modules. That would make me an expert on nearly everything yast can configure :) The yast module developer should know what that tag is for.

Philipp, here is what I found out so far:
YaST2 autoyast apparently executes completely differntn code than yast2 bootloader does. yast2 bootloader uses a lot of Storage:: code which yast2 autoyast doesn't.
Therefore, bootloader device is nil as well.

The "bootloader device nil" is gone. But there is a different bug here that's not
autoyast specific but seems to be a generic bootloader bug.

activate is not set, because device-map is nil in the autoyast case.
looks like there might be a problem in perl-Bootloader getDeviceMap
Look into Core/GRUB.pm.

Also default section is not read properly in my test case here.

Does Bootloader::ReadOrProposeIfNeeded() work right?

*** Bug 159570 has been marked as a duplicate of this bug. ***

Any progress here?

Yes, but not nearly enough.

od and pth:

When we started "yast2 bootloader" and looked at the state of the "Activating
Bootloader Partition" checkbox, it was left unchecked.

The root problem here is that yast2 does not store the state of all user
selections. In the case of grub, there is no "activate" flag to store in the
menu.lst file. So yast2-bootloader has no way to find out that "activate" is
wanted, unless the user tells him by checking the checkbox.

So this works for lilo (which knows the "activate" flag), but does not work for
grub.

So either
    - we find a good place where yast2-bootloader can store and retrieve the
      state of the activate flag for the grub case, or 
    - we find out how to come to a better proposal for the "activate" flag when
      autoyast is collecting information from yast2-bootloader.


One way to remember this may be a comment in menu.lst:

# YaST2 stored user setting: activate

We then could decide when this flag will be honoured: everytime or only for
autoyast.

We need someone to help us decide this.

I don't know too much about that stuff but is there really no way to read the information from the running system?
"fdisk -l" for example shows the activated partition. 

Why not use the information provided by getTargetMap? it tells wether a partition has a bootable flag or not.

To answer the question in the two previous comments first:

The activate flag tells yast2-bootloader (and lilo) to activate the boot
partition device (whatever device this may be).

It is impossible to find out from the disk only whether the user wanted the
activate flag to be changed or not. lilo.conf contains the flag, menu.lst
does not.


But after sleeping a few nights (during weekend) over this, I realized that
the real problem here is somthing different:

The yast2-bootloader code has been changed for 9.1 to return a configuration
to autoyast that is compatible with a different disk setup on the target
system which will be installed with the resulting autoyast.xml:

-------------------------------------------------------------------
Thu May 27 16:35:45 CEST 2004 - jsrain@suse.cz

- don't display device name if user selected to activate boot
  loader partition ot replace MBR with generic code when preparing
  AutoYaST  profile, as the device names aren't known (#41258)
- [...]

-------------------------------------------------------------------

and

-------------------------------------------------------------------
Tue Feb  4 13:50:29 CET 2003 - jsrain@suse.de

- updates of autoinstallation

-------------------------------------------------------------------


Originally, autoyast was used to
    a) collect setup information from the current system
    b) display this to the user and let him edit the information
    c) apply this setup to the target system during installation.


The target system could be quite different from the system used to collect
the setup information. This means that the disk setup (bootloader device,
activate flag, probably also partitioning) could not be used on the target
system. In effect, the user would have to provide this information manually
in step b) above.

Thus, with the changes documented in the changelog entries above, the
information about the bootloader device and other disk-specific information
was filtered out or not even collected from the disk anymore.

For the new "Clone system" functionality, the expectations are different:

    - the target system is expected to be very similar or (almost) identical
      to the original system
    - autoyast is expected to provide a copy of the configuration of the
      original system, rather then a more or less rough template.


We would need to find out what kind of configuration information
yast2-bootloader is supposed to return to autoyast.

I would suggest to provide an additional flag to the rest of yast that
specifies more exactly whether autoyast wants a

    - malleable setup information template or a
    - clone of the setup information.

The parts of yast who need to base decisions on this information could then
evaluate this flag.

Adding visnov and jsrain to Cc.

jsrain, ug - does this make sense to you and sound OK from your experience and
             from the technical stuff?

visnov, sf, ... - any comments & how/where/who does this in yast?

ug, it would be good if you could provide feature ids, so we could check
what is really requested of us.

the feature id is #264

About the cloning. From my point of view, the reference profile should be as close as possible to the currently installed system. For example, the cloning of the partitioning was so close to the current system, that even the cylinder borders were cloned (I changed that, because I think it's too strict and useless but it was invented that way). So the idea of the autoyast reference profile has always been "create a profile, that makes it possible to install THIS machine again without user interaction". If the user wants to use that profile to install a different machine, he should take care that he changes the stuff that must be changed (partition sizes for example).

Even if you would say "we don't know if the user wants to activate the boot partition" the yast2-bootloader behaves wrong, because it explicitly says "false" to the activate flag. It says "don't activate it".

I read the changelog entry and if the bootloader can autodetect stuff during the installation by itself, then it might be okay not to provide that information in the cloned autoyast profile at all but in this case the information in the profile is simply wrong.

yast2-bootloader will now pass the activate flag and the loader_device to
AutoYaST after reading the information from the disk.

The activate flag may still be a problem in one case: it will be "false"
when the bootloader is in MBR and some partition is already activated.

Does it make sense to leave it like that or should the activate flag
_always_ be set to "true"?

@Olaf
since we just talked about that, you already know that I think this solution is fine. :)
Thanx.

The fix is in yast2-bootloader-2.13.43.

Please test.

*** Bug 165459 has been marked as a duplicate of this bug. ***

*** Bug 164586 has been marked as a duplicate of this bug. ***

----- Additional Comments From ameet@us.ibm.com(prefers email via ameet@austin.ibm.com)  2006-04-19 13:25 EDT -------
SuSE,

This is still failing for us on SLES10 beta 10.  The YaST logs are in Novell 164586. 

Olaf - doesn't appear to be fixed in beta10.

First, the second part of bug #164586 >= comment #12 is a different problem:
Grub finds everything needed, and starts the kernel.
But the root=/dev/hda5 is wrong.
Where does it come from? did you change the partitioning in the xml-file?
If yes, you _have_ to change this as well.

Not activating a partition is correct in this case, as grub is written to MBR,
as it can't be booted from a extended partition.
And this is done, as the kernel is started.


 

Which info do you need from me?

Sorry, I meant Glen...

----- Additional Comments From zhanx@cn.ibm.com  2006-04-27 07:24 EDT -------
Could anyone let me know when this defect will be fixed? Thank you. 

------- Additional Comments From hanpt@cn.ibm.com  2006-04-27 21:54 EDT -------
(In reply to comment #26)
> Ping,
> 
> SuSE is looking for an answer to these questions in comment #22:
> 
> But the root=/dev/hda5 is wrong.
> Where does it come from? did you change the partitioning in the xml-file?
> If yes, you _have_ to change this as well.
We use the xml-file generated by manually install. It seems that the
"roo=/dev/hda5" is generated by the autoyast itself. We hadn't modified the
xml-file anymore. 

I think all the info is provided, right?  The autoyast file is attached.

And this got bumped one slot to blocker on the LTC side.

Glen, the original problem is fixed.  I consider your bug a different issue and I do not consider this a blocker for SUSE Linux 10.1.

If you disagree with the non-blocker, file a new bug against SLES10, but this bug will be CRITICAL only.

Finally found the problem, and reproduced it: 
Your setup:
/dev/hda1 swap
/dev/hda2 extended partition
/dev/hda5 /

autoyast changes this to:
/dev/hda1 swap
/dev/hda2 /

With root=/dev/hda5 in the bootloader configuration, the kernel doesn't find the 
root filesystem.

So this is a autoyast partitioning problem.

Uwe, your fix in the autoyast.xml did the trick, works now.

fixed (#170597)