Bug 431703

What we would need here is a mechanism so that we can try creating the initrd when the last kernel package is installed in a transaction. A transaction in this sense could be installing a number of packages at once from the rpm command line, but also installing a number of kernel packages from the package manager. (The package manager does not install all the kernel packages at once.) Unfortunately, we don't know that.

The best solution I have for this right now is to change mkinitrd so that it doesn't fail when modules are missing. Hannes, can we do that?

Is it not possible to put the post install scripts in a separate rpm?

Dave, the question IMO is who should call these scripts?

I don't understand the mechanics of the satsolver or what determines the order of installation of the kernel packages but if this was determinable then the scripts would be the last to be installed.

The order of installation are calculated by RPM dependencies, like rpm would itself, too.

We need a "weak" PreReq here ...

This is not about the order in which the kernel packages get installed. We cannot create an initrd only in the -base package: even if we managed to get the package order "right" within a single transaction, the user would still be able to install kernel-$foo-base, kernel-$foo, kernel-$foo-extra from the command line, separately, in this order.

(It could be that there is a way to play some really evil tricks with triggers, but I can't say that this idea really thrills me.)

If the kernel base package is not sufficient to create an initrd then surely it should not contain the script to do so. I was lead to believe it contains modules for jbd and extfs and could be used in a very lean system? If that is not so then it doesn't need mkinitrd.

I had a boot problem after upgrade to beta 2 and blamed it on grub but it seems that grub was not at fault. I'm not that familiar with grub, my system booted as far a the grub shell, would this indicate that my initrd was at fault?

That's impossible to tell without additional information such as the YAST logs of the update, or the error messages you got during boot.

(In reply to comment #9 from Andreas Gruenbacher)
> That's impossible to tell without additional information such as the YAST logs
> of the update, or the error messages you got during boot.
> 
Nothing was loaded all I had was the grub shell. I thought it was https://bugzilla.novell.com/show_bug.cgi?id=428127 and used 11.0 dvd rescue system to replace the files in /boot/grub with a backup then I could boot to grub boot menu which pointed at my old non existent kernel. I then used 11.0 dvd system repair expert install new bootloader to point to correct kernel vmlinuz-2.6.27-rc7-12-pae and initrd-2.6.27-rc7-12-pae. I create a symlink to /mnt/boot called boot, in ctrl/alt/F2 console, to enable me to browse to the correct kernel and initrd in the bootloader repair program.
That means that initrd-2.6.27-rc7-12-pae was present prior to finishing the repair so it must have been created during install. Grub was also updated to grub-0.97-151.3, which is supposed to work, during my upgrade. I reopened the grub bug and then forced a reinstallation of grub-0.97-151.3 and the system still booted, now I am not sure what caused the boot failure.

Created attachment 243492 [details]
Yast log with installation of kernel

I could only see the one error from kernel-pae-base installation, kernel-pae installation returned no rpm error, its a pity the log doesn't show output from rpm during a successful install.

Anything other steps I can take please ask.

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

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

(In reply to comment #11 from Dave Plater)
> Created an attachment (id=243492) [details]
> Yast log with installation of kernel
> 
> I could only see the one error from kernel-pae-base installation, kernel-pae
> installation returned no rpm error, its a pity the log doesn't show output from
> rpm during a successful install.
> 

I downgraded to my previous kernel-2.6.27-rc5.git9.6.i586 and then after reboot upgraded to the present kernel packages and on reboot I was taken into grub shell again. This time I have left my system in the same state and booted from rescue system using kexec. Any idea where I can look next? I used to use lilo until recently and I do not have much experience with grub. I have proven that the problem comes from kernel installation though.

A clue might be when I execute kexec-bootloader I receive the message:-
 "Default boot section is no image."

In yast2 bootloader there are no sections at all.

output of mkinitrd:-
Kernel image:   /boot/vmlinuz-2.6.27-rc7-12-pae
Initrd image:   /boot/initrd-2.6.27-rc7-12-pae
Root device:    /dev/disk/by-id/ata-WDC_WD800JB-00JJC0_WD-WMAM9RA78067-part1 (/dev/sda1) (mounted on / as xfs)
find: `/lib/modules/2.6.27-rc7-12-pae/kernel/drivers/s390': No such file or directory
find: `/lib/modules/2.6.27-rc7-12-pae/kernel/drivers/s390': No such file or directory
Kernel Modules: dock scsi_mod libata ata_piix xfs processor thermal fan edd ahci pata_rz1000 pata_pdc2027x pata_sis pdc_adma sata_mv sata_nv pata_sch sata_promise pata_sc1200 sata_qstor sata_sil pata_serverworks sata_sil24 sata_sis sata_svw sata_sx4 sata_uli sata_via sata_vsc pata_sil680 ata_generic pata_acpi pata_ali pata_amd pata_sl82c105 pata_artop pata_atiixp pata_cmd640 pata_cmd64x pata_cs5520 pata_cs5530 pata_cs5535 pata_cs5536 pata_cypress pata_efar pata_hpt366 pata_hpt37x pata_hpt3x2n pata_hpt3x3 pata_isapnp pata_it8213 pata_it821x pata_jmicron pata_legacy pata_marvell pata_mpiix pata_netcell pata_ninja32 pata_ns87410 pata_ns87415 pata_oldpiix pata_opti pata_optidma pcmcia_core pcmcia pata_pcmcia pata_pdc202xx_old pata_qdi pata_radisys pata_triflex pata_via pata_winbond sata_inic162x ide-core ide-disk cdrom ide-cd_mod ide-floppy ide-generic dtc2278 ht6560b ide-cs qd65xx umc8672 ali14xx ide-4drives ide_platform aec62xx alim15x3 amd74xx atiixp cmd64x cs5520 cs5530 cs5535 hpt366 ns87415 opti621 pdc202xx_new pdc202xx_old piix rz1000 serverworks siimage sis5513 trm290 via82cxxx cmd640 delkin_cb ide-pci-generic it8213 it821x jmicron sc1200 slc90e66 triflex ide-pnp ide-tape BusLogic crc-t10dif sd_mod sg sr_mod st 3w-9xxx 3w-xxxx aacraid scsi_transport_spi aic79xx aic7xxx scsi_transport_sas libsas aic94xx arcmsr atp870u ch dc395x scsi_dh scsi_dh_alua scsi_dh_emc scsi_dh_hp_sw scsi_dh_rdac dmx3191d dpt_i2o eata scsi_tgt scsi_transport_fc libfc fcoe fdomain gdth hptiop ide-scsi parport imm ipr ips scsi_transport_iscsi libiscsi iscsi_tcp libsrp lpfc megaraid_mm megaraid_mbox megaraid_sas megaraid mvsas nsp32 osst aha152x_cs fdomain_cs nsp_cs qlogicfas408 qlogic_cs sym53c500_cs ppa qla1280 qla2xxx qla4xxx sym53c416 t128 raid_class scsi_debug in2000 initio pas16 scsi_transport_srp scsi_wait_scan enclosure ses stex sym53c8xx tmscsim NCR53c406a a100u2w advansys aha152x aha1542 aic7xxx_old dtc g_NCR5380 g_NCR5380_mmio qlogicfas u14-34f ultrastor wd7000 usbcore ohci-hcd uhci-hcd ehci-hcd ff-memless hid usbhid
Features:       block usb resume.userspace resume.kernel
Bootsplash:     openSUSE (1280x1024)
39468 blocks
Still no sections in yast2 bootloader

Output of grub-install:-
    GNU GRUB  version 0.97  (640K lower / 3072K upper memory)

 [ Minimal BASH-like line editing is supported.  For the first word, TAB
   lists possible command completions.  Anywhere else TAB lists the possible
   completions of a device/filename. ]
grub> setup --stage2=/boot/grub/stage2 (hd0) (hd0,0)
 Checking if "/boot/grub/stage1" exists... yes
 Checking if "/boot/grub/stage2" exists... yes
 Checking if "/boot/grub/xfs_stage1_5" exists... yes
 Running "embed /boot/grub/xfs_stage1_5 (hd0)"...  18 sectors are embedded.
succeeded
 Running "install --stage2=/boot/grub/stage2 /boot/grub/stage1 (hd0) (hd0)1+18 p (hd0,0)/boot/grub/stage2 /boot/grub/menu.lst"... succeeded
Done.
grub> quit
Still nothing in yast2 bootloader

This sounds like a bad interaction between perl-Bootloader and the kernel-$flavor-base %post script. It may be that perl-Bootloader chokes when asked to add a bootloader entry even though the initrd doesn't exit yet at that point in time. Adding the perl-Bootloader maintainer as well ...

One thing to try would be to downgrade to the old kernel, then upgrade to the new kernel by installing the new kernel-$flavor-base and kernel-$flavor packages while running the scripts by hand, like this:

   rpm -U --noscripts $foo.rpm
   rpm -qp --qf '%{postin}' $foo.rpm > post.sh
   bash -x post.sh > post-$foo.log 2>&1

this should show all the commands, messages, and errors. /boot/grub/menu.lst would be interesting in its state with the old kernel, with only the kernel-$flavor-base package installed, and with the kernel-$flavor package installed as well.

Created attachment 243883 [details]
output of rpm -vv

I did a kdiff on postin sripts from previous and present kernel-pae note not pae-base which fails anyway and after finding what I think might be the problem :-

run_bootloader () {
    # Only create the bootloader entry when installing kernel-$flavor-base.
    if [ kernel-pae != kernel-pae-base ]; then
	return 1
    fi

This is in the new kernel-pae and would prevent bootloader from being updated.
After running rpm -U --force -vv kernel-pae-base-2.6.27-12.1.i586.rpm
Yast bootloader now shows sections therefore when I reboot it should work.
I've attached the output of above command.

Rebooted grub present and correct. Catch 22 situation, bootloader doesn't update with installation of kernel-pae-base because no xfs filesystem module and installation of kernel-pae doesn't update bootloader due to added script to prevent it from happening.
Strange no one else has complained.

It seems that kernel-pae-base doesn't add the bootloader entry because mkinitrd fails before that. Once that is fixed (even though kernel-pae-base won't be able to create the initrd), kernel-base won't have a reason to add the same bootloader entry a second time. That's what the check in run_bootloader was meant for.

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

I think we have a reasonable solution to this problem now: we agreed that mkinitrd will use a different status code for reporting when required modules are missing (such as reiserfs or xfs). In that case, it also won't create an initrd, because that initrd wouldn't boot, anyway. In the various kernel's %post scripts I will check for this particular status code, and not error out.

On top of that, the %post scripts will only add a bootloader entry when an initrd has been created (or the kernel has been compiled without modules, and doesn't need one).

Other than now, the code adding the bootloader entry may get run repeatedly now; at most three times if an initrd could already be created with kernel-$flavor-base.

I think we have a reasonable solution to this problem now: we agreed that mkinitrd will use a different status code for reporting when required modules are missing (such as reiserfs or xfs). In that case, it also won't create an initrd, because that initrd wouldn't boot, anyway. In the various kernel's %post scripts I will check for this particular status code, and not error out.

On top of that, the %post scripts will only add a bootloader entry when an initrd has been created (or the kernel has been compiled without modules, and doesn't need one).

Other than right now, the code adding the bootloader entry may get run repeatedly now (once per kernel sub-package for which an initrd could be created). Does perl-Bootloader cope with this, or do we need to add a separate check to figure out if a particular kernel already has a bootloader entry?

Oh, before I forget ... only creating the bootloader entry if we have an initrd (or the kernel isn't modular in the first place) also means that we may end up without a bootloader entry if mkinitrd gets it wrong, but that's not so much different from trying to boot with a broken initrd.

The one case I am unsure about is the installation order of kernel packages and KMPs: in case mkinitrd decides to depend on a module from a KMP, there is no guarantee that the KMP with that module will get installed before the kernel package(s). We *could* try to add bootloader entries out of KMP %post scripts, but that seems really ugly to me --- so maybe a package manager hack would be more acceptable?

OK - few notes.
You can boot without initrd, but now perl-Bootloader doesn't support it (I can add this support if it is needed).
perl-Bootloader doesn't have any problem with multiple kernel. Add new entry is not problem (if version is different it create more entry - so if you install new base you have two entries in bootloader menu...if you have base, none and extra with same version then is created only one entry (I now test it and it works :).
Only problem is when you upgrade only one part...because it have same image and initrd name it remove it after first upgrade...so if you have base and extra and you update only base, then extra is removed from entry.
I watch this discuss so if you need anything feel free to ask.

Do you mean it is possible to upgrade base version without upgrading none and extra? When I force upgraded base only it didn't harm the system and the bootloader was fixed.

> Only problem is when you upgrade only one part...because it have same image
> and initrd name it remove it after first upgrade...so if you have base and
> extra and you update only base, then extra is removed from entry.

I don't understand: the kernel-$flavor-base, kernel-$flavor, and kernel-$flavor-extra packages are all for the same kernel, they all have the same package version and release number, and they all refer to the same /boot/vmlinu* and /boot/initrd file. The kernel-$flavor and kernel-$flavor-extra packages only contain additional modules.

> Do you mean it is possible to upgrade base version without upgrading none and
> extra?

Not usually, but I would like this to work even when enforced.

(In reply to comment #31 from Andreas Gruenbacher)
> > Only problem is when you upgrade only one part...because it have same image
> > and initrd name it remove it after first upgrade...so if you have base and
> > extra and you update only base, then extra is removed from entry.
> 
> I don't understand: the kernel-$flavor-base, kernel-$flavor, and
> kernel-$flavor-extra packages are all for the same kernel, they all have the
> same package version and release number, and they all refer to the same
> /boot/vmlinu* and /boot/initrd file. The kernel-$flavor and
> kernel-$flavor-extra packages only contain additional modules.
> 

yes, but if you call in post script remove some image and initrd it doesn't check if it exist only remove it. So if you upgrade base and old base is uninstalled if you call remove for post script it remove old entry even default and extra can still have old image. Or I bad understand it?

(In reply to comment #32 from Josef Reidinger)
> (In reply to comment #31 from Andreas Gruenbacher)
> > > Only problem is when you upgrade only one part...because it have same image
> > > and initrd name it remove it after first upgrade...so if you have base and
> > > extra and you update only base, then extra is removed from entry.
> > 
> > I don't understand: the kernel-$flavor-base, kernel-$flavor, and
> > kernel-$flavor-extra packages are all for the same kernel, they all have the
> > same package version and release number, and they all refer to the same
> > /boot/vmlinu* and /boot/initrd file. The kernel-$flavor and
> > kernel-$flavor-extra packages only contain additional modules.
> > 
> 
> yes, but if you call in post script remove some image and initrd it doesn't
> check if it exist only remove it. So if you upgrade base and old base is
> uninstalled if you call remove for post script it remove old entry even default
> and extra can still have old image. Or I bad understand it?
> 
This is for the future, when upgrade will be up to three kernel packages?
Then the last installed part of kernel packages will have to do postin script.

(In reply to comment #33 from Dave Plater)
> This is for the future, when upgrade will be up to three kernel packages?
> Then the last installed part of kernel packages will have to do postin script.
> 

This must be done now, because in simplier case if you install base, normal and extra package and then remove extra, then extra cannot call post-uninstall script for bootloader (It looks like not this is done as during test after uninstall bootloader menu is correct).

And one note which I find during testing. If you have installed base and normal package and want uninstall normal and let only base, it is not possible, because you are forced to install another kernel.

(In reply to comment #34 from Josef Reidinger)
> (In reply to comment #33 from Dave Plater)
> > This is for the future, when upgrade will be up to three kernel packages?
> > Then the last installed part of kernel packages will have to do postin script.
> > 
> 
> This must be done now, because in simplier case if you install base, normal and
> extra package and then remove extra, then extra cannot call post-uninstall
> script for bootloader (It looks like not this is done as during test after
> uninstall bootloader menu is correct).
> 
> And one note which I find during testing. If you have installed base and normal
> package and want uninstall normal and let only base, it is not possible,
> because you are forced to install another kernel.
> 
Extra package only contains postin script, no postun.

Yes and this must not change.

Where are the split source rpms factory src repo only contains single kernel source rpms?

(In reply to comment #37 from Dave Plater)
> Where are the split source rpms factory src repo only contains single kernel
> source rpms?
> 

I think that it is in one rpm where modules depend only on spec file, where is specified more packages?

I'm a novice as far as rpmbuild is concerned. Do the base, none and extra packages build from one source package.

> And one note which I find during testing. If you have installed base and
> normal package and want uninstall normal and let only base, it is not
> possible, because you are forced to install another kernel.

I don't understand -- what do you mean?

(In reply to comment #40 from Andreas Gruenbacher)
> > And one note which I find during testing. If you have installed base and
> > normal package and want uninstall normal and let only base, it is not
> > possible, because you are forced to install another kernel.
> 
> I don't understand -- what do you mean?
> 

Try zypper in kernel-default. It also install base...but then you want only base, so you do zypper rm kernel-default and it force you to install another kernel. I test it with the newest zypper. Maybe I have only old one.

(In reply to comment #41 from Josef Reidinger)
> (In reply to comment #40 from Andreas Gruenbacher)
> > > And one note which I find during testing. If you have installed base and
> > > normal package and want uninstall normal and let only base, it is not
> > > possible, because you are forced to install another kernel.
> > 
> > I don't understand -- what do you mean?
> > 
> 
> Try zypper in kernel-default. It also install base...but then you want only
> base, so you do zypper rm kernel-default and it force you to install another
> kernel. I test it with the newest zypper. Maybe I have only old one.
> 

Sorry it is just old zypper, in beta2 this is allowed correctly. So you can reduce your kernel to only base.

# zypper rm kernel-pae
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following packages are going to be REMOVED:
  kernel-pae kernel-pae-extra


After the operation, 86.9 M will be freed.
Continue? [YES/no]: n

Look at the package dependencies: kernel-pae-extra requires kernel-pae, and kernel-pae requires kernel-pae-base. So it's completely normal that removing kernel-pae will also remove kernel-pae-extra.

(Side note: we could technically make kernel-pae-extra require only kernel-pae-base, but I can't imagine that this would ever lead to a useful result.)

(In reply to comment #44 from Andreas Gruenbacher)
> Look at the package dependencies: kernel-pae-extra requires kernel-pae, and
> kernel-pae requires kernel-pae-base. So it's completely normal that removing
> kernel-pae will also remove kernel-pae-extra.
> 
> (Side note: we could technically make kernel-pae-extra require only
> kernel-pae-base, but I can't imagine that this would ever lead to a useful
> result.)
> 

No, I think that this dependencies is correct and this work good. Problem I saw only when I try it with old zypper.

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

Just updated to factory kernel via zypper and apart from kernel-source not being updated as a dependency everything seems fine. Grub updated perfectly and I have just completed a cold boot with absolutely no problems. Whatever has been changed works.

Thanks for confirming!

Hmm ... fixed since a loooong time ...

Verified sles11sp1gmc3 with xfs root filesystem on ia64 and with reiserfs root filesystem on x86_64. Fixed.