Bug 292435

As y2log is too big to attach and zip is unhandy, you find it here:
~trenn/Export/y2log
Tell me if you cannot access it.

Please, never file a Critical bugs using the BETA/STABLE build. That's what we have Alphas/Betas for. If you want to debug a new feature or bugfix, use the latest (or any other) Alpha/Beta and create your own inst-sys including that feature/bugfix.

The current bug might be caused by a still-buggy libzypp or other features JustWorkInProgress. New libzypp is just in autobuild.

See these logs:
--- cut ---
MediaCurl.cc(doGetFileCopy):812 curl error: 9: Server denied you to change to the given directory
MediaCurl.cc(doGetFileCopy):888: File /repodata/repomd.xml not found on media: ftp://10.11.0.100/stable-x86_64
SourceImpl.cc(provideJustFile):379 Media couldn't provide file /repodata/repomd.xml , releasing.

MediaCurl.cc(doGetFileCopy):812 curl error: 19: RETR response: 550
Exception.cc(log):94 MediaCurl.cc(doGetFileCopy):888 THROW:    MediaCurl.cc(doGetFileCopy):888: File ./media.1/directory.yast not found on media: ftp://10.11.0.100/stable-x86_64
SourceFactory.cc(createFrom):212 No next type of source
Exception.cc(log):94 SourceFactory.cc(createFrom):213 THROW:    SourceFactory.cc(createFrom):213: Cannot create the installation source
Source.cc(SourceCreateEx):1126 SourceCreate for 'ftp://10.11.0.100/stable-x86_64' product '' has failed

<3> 10.11.1.32(3811) [YCP] Packages.ycp:579 No source on 'ftp://10.11.0.100/stable-x86_64'
AutoinstSoftware.ycp:93 packages not found: expect
nmap
tcpdump
findutils-locate
itcl
emacs-x11
perl-libwww-perl
gcc-c++
rug
ncurses-devel
kexec-tools
kernel-kdump
(at least some packages are probably needed for the chroot environment for SCR::Switch).

AutoinstSoftware.ycp:430 Error while setting-addon selection or pattern: base,x11

[Interpreter] clients/switch_scr_finish.ycp:61 Can't create component 'chroot=/mnt:scr'
Y2WFMComponent.cc(SCROpen):250 SCROpen 'chroot=/mnt:scr' failed: -1
--- cut ---

Additionally, YaST logs can be gzipped or bzip2ed, you don't need to use 'zip' and actually all bugreports for YaST have them.

Closing as INVALID because STABLE/BETA can't be used as appropriate testing source and bug cannot be correctly reproduced because of undefined behavior.

Created attachment 152316 [details]
y2log of failed Alpha6 autoyast installation hanging with error message at bootloader installation after packages got written to disk

The error message (german) where yast hangs is:

Während der Installation des Bootloaders trat ein Fehler auf.
Wollen Sie die Bootloader-Konfiguration wiederholen?

Created attachment 152317 [details]
autoyast xml file used to install 10.3 (/boot is not formatted, but data (kernels) from already installed systems like sles10,... is still in there)

I need to give a comment for reopening..., see comment #5, Alpha 6 is affected.

Actually, I can't speak German, so I don't exactly know what "Während der Installation des Bootloaders trat ein Fehler auf. Wollen Sie die Bootloader-Konfiguration wiederholen?" means however I can guess ;)

The original bugreport was about SCR_switch that didn't go well. As I've checked, the SCR_switch went without errors in this case (comment #5) but I've found these errors from Bootloader configuration:

--- cut ---
[bash] ShellCommand.cc(shellcommand):78 BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.8.8/Compress/Zlib.pm line 9.
ShellCommand.cc(shellcommand):78 BEGIN failed--compilation aborted at /usr/lib/YaST2/bin/examine_mbr.pl line 3.
[Interpreter] bootloader/routines/autoinstall.ycp:221 Intermediate structure with index ["specific", "global"] does not exist
[Interpreter] bootloader/routines/autoinstall.ycp:221 Intermediate structure with index ["specific", "global"] does not exist
[Interpreter] bootloader/routines/autoinstall.ycp:244 Intermediate structure with index ["specific", "global"] does not exist
--- cut ---

--- cut ---
[YCP] Bootloader.ycp:389 Writing bootloader configuration
[YCP] Bootloader.ycp:441 Failed to initialize device mapper
--- cut ---

Reassigning to bootloader maintainer...

Translation of "Während der Installation des Bootloaders trat ein Fehler auf. Wollen Sie die Bootloader-Konfiguration wiederholen?" is "There was an error while installing the boot loader. Do you want to repeat the bootloader configuration?".

The attachment in comment #5 contains only the y2log. But I need the full
logs, as save_y2logs would save them.

Please attach the full logs. Alternatively, please give me access to the
test machine (which seems to be mussorgsky, but I cannot access it or start
it remotely).

Created attachment 153999 [details]
save_y2logs output

Created attachment 154000 [details]
y2logs on the target system (/mnt/var/log/Yast2

Created attachment 154001 [details]
Already existing menu.lst of /boot (/boot is not reformatted, but shared through several installations (SLES9/SLES10/...)

The y2log from the target system shows that the Bootloader_API namespace is
missing:

------------------------------------------------------------------
2007-07-30 14:11:19 <3> 10.11.1.32(23057) [Interpreter] <stdin>:183 Loading module 'Bootloader_API' failed
2007-07-30 14:11:19 <3> 10.11.1.32(23057) [libycp] Import.cc(import):97 No matching component found
2007-07-30 14:11:19 <3> 10.11.1.32(23057) [Parser] <stdin>:183 Can't load module 'Bootloader_API'.
2007-07-30 14:11:19 <3> 10.11.1.32(23057) [Parser] <stdin>:183 Unknown namespace 'Bootloader_API'. Missing 'import'?
------------------------------------------------------------------

In fact, yast2-bootloader is not installed:

------------------------------------------------------------------
inst-sys:/mnt/var/log/YaST2 # chroot /mnt
inst-sys:/ # rpm -qa | grep ootload
perl-Bootloader-0.4.17-5
inst-sys:/ # 
------------------------------------------------------------------

This can also be verified with the y2logRPM from the target system.

I am not sure why this happens, but AFAICS the autoyast XML control file
from comment #6 shows no special settings for package installation.

Is the default package selection wrong?

Reassigning to yast2-maintainers.

Uwe, could you please check to autoyast XML file.
What could be the reason for uninstalled yast2-bootloader? 
I didn't find any logging about yast2-bootloader in y2log even though the package is available on music:/srv/ftp/10.3/x86_64/DVD1.
Maybe the patterns aren't set correctly?

I am currently going over that...
We use an external file which we include into each autoyast file via xinclude tag (cmp with autoyast.xml file in comment #6).
The file is looks like:

<?xml version="1.0"?>
  <software xmlns:config="http://www.suse.com/1.0/configns">
      <patterns config:type="list">
        <pattern>x11</pattern>
        <pattern>base</pattern>
      </patterns>
      <packages config:type="list">
         <package>expect</package>
         <package>nmap</package>
         <package>tcpdump</package>
         <package>findutils-locate</package>
         <package>itcl</package>
         <package>emacs-x11</package>
         <package>perl-libwww-perl</package>
        <package>gcc-c++</package>
        <package>rug</package>
        <package>ncurses-devel</package>
        <package>kexec-tools</package>
        <package>kernel-kdump</package>
        </packages>
    </software>


I grepped a bit through:
/mounts/dist/install/SLP/openSUSE-10.3-Alpha6-DVD/x86_64/DVD1/suse/setup/descr/*
and it really maybe that the culprit lies in the patterns...

I will give it a try with adding yast2_basis to our patterns and will report back soon. If it works, a fix could be to add yast2_basis to the basis system or similar...

Adding:
        <pattern>yast2_basis</pattern>
to the pattern selection fixes the problem.
IMO yast2-bootloader package or yast2_basis pattern must be part of the base selection (or require or whatever can be done in the patterns config file) 
Uwe, do you know whom this should get assigned


I cannot say whether all works fine now as after successful reboot I went into the next (unrelated) bug:
-----
kernel BUG at kernel/power/snapshot.c:464!
invalid opcode: 0000 [1] SMP 
last sysfs file: /kernel/uevent_seqnum
CPU 3 
Modules linked in: ohci_hcd sd_mod usbcore edd reiserfs fan thermal processor sata_sil pata_amd libata scsi_mod
Pid: 1039, comm: resume Tainted: G      N 2.6.22-5-default #1
RIP: 0010:[<ffffffff80250a06>]  [<ffffffff80250a06>] memory_bm_find_bit+0x20/0x78
RSP

Will try on the next machine..., finally we can go on finding/fixing bugs again...
Thanks a lot Olaf (and whoever helped here)!

Ok, this is not critical.
If a fresh autoyast.xml is generated with the 10.3 autoyast module I expect (hope!) the yast2_basis pattern gets added.
This is a compatibility issue. Not sure whether it should get fixed at all.

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

if the pattern is installed, autoyast will clone it. That's no problem.
The bad thing is, that old autoyast profiles will break because the yast2_basis pattern is not installed via "REQUIRED" in the content file but has to be configured explicitly. That's not good.

I couldn't care less, but AJ explicitly designed the minimal system in a way that you don't need the yast2 patterns e.g. in a live CD. So autoyast needs to take care.

if the installation should work without the yast2_basis pattern, then it's a bug in the patterns, because it does not work without them.
If the base pattern + the yast2_basis pattern are required for installation, then it's a bug in the content file.
I can't do anything in autoyast.

The yast2_basis pattern is *recommended* by the base pattern.  Why does this not work?

The requirement is that it's possible in the installed system to remove YaST packages.

Klaus, please analyze and propose what's the best action here.

"recommended" is not enough. The installation does not work without that pattern.

Jiri, apparently more YaST packages are needed than currently enforced via 'requires' of patterns.

Can you please check which packages are missing ?

I think Klaus misunderstood the problem. yast2_basis is recommended - due to a design decision of AJ. The problem is that yast2_basis is really just required for installation, after it it's not. 

in beta2 I had to explicitly say that I need resmgr - otherwise login via keyboard was not possible. I think we hardly can call that an optional package then.
It's getting worse.

Hmm, any idea why you would need resmgr for login?

from /etc/pam.d/login:

[...]
session  required       pam_resmgr.so
[...]

rpm -qf /lib64/security/pam_resmgr.so
resmgr-1.1.0_SVNr143-5

*** This bug has been marked as a duplicate of bug 304695 ***

comment #17 is still not fixed

fixed in patterns svn.

comment #17 is still not fixed
yast packages are missing in the basesystem pattern and so an "only Basesystem" installation does not work. The chroot into the installed system fails.
(beta 3)

If you hadn't hijacked the bug with some other bug, we'd still read #26

The base system does not have yast and if you need yast for installation, you need to add it to your config.

?!?
Yast boot loader is needed that a system can be installed right?
So this package (and everything that it needs) must be installed, even if only BasePackage pattern is defined.

Why cannot the yast_basis pattern be set to required, instead of recommended, that should be an easy fix (if that works)?