Bug 392054

the /.buildenv is there exactly to stop the kernel from failing in %post during the build process. I would remove it from my config, but as kiwi generates this file as general step, it should be removed in a general step too.

> the /.buildenv is there exactly to stop the kernel from failing in %post
> during the build process.

I don't understand. I'm talking about the running system, not a build environment. What does kiwi have to do with build environments? This sounds very strange to me.

the live cds have to be built somewhere - I call these environments build environments.

... which is distinct from package building; essentially, you are installing packages, not building them. So is the same /.buildenv file being used in two different contexts?

in reply to comment #1: yes I agree it should not be part of the final image
and should be removed after the root tree preparation

fixed

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

Hi,

is there any way for us beta3 live cd users to work around this? I have reinstalled 3 times now and every time after the update to 2.6.25-4.2 my system gets borked. Removing the /.buildenv before the update does not fix this, it results in a black screen after grub without boot, failsafe boot works properly though. I would like to be able to update all 784 packages and be able to still boot afterwards.

stefan

The immediate fix is to remove /.buildenv.

I just realized that the kernel-$flavor spec files include "#!BuildIgnore: mkinitrd" which tells the various build systems to exclude the mkinitrd package from the dependency list. Therefore, it is sufficient to test for the existence of /sbin/mkinitrd in %post. I will change that, and so future updates will no longer have this problem.

Coolo, meanwhile, what do you think of getting this problem documented in the openSUSE WiKi, so that people won't hit this annoying bog over and over again?

removing /.buildenv changes the issue but - for me - does not solve it. Now the system boots so safe mode but the normal kernel gives nothing but a black screen. I do have an /boot/initrd-2.6.25-4.2 now with a correct symlink so that is fine. further there are now 4 entries in grub, 2x kernel and 2x failsafe one by name OpenSuSe and the other by version number.

stefan

Alright, neither seems to be related to the /.buildenv problem though: I would suppose that the duplicate boot loader entry is due to a bug in perl-Bootloader, but I'd need more details from you on that (and also, perl-Bootloader is maintained by aosthof@novell.com so he would be the person to look into this). The black screen problem sounds like an unrelated issue yet again, but I'd also need more details on that.

So would you mind to please report these two issues separately? Thanks!

Andreas, your change to the post.sh will break creating the live cds. We use the /.buildenv hack to make it possible to install the kernel into a chroot. It insists on running mkinitrd in %post - which is kind of against the policy not to run host specifics in %post. So we use /.buildenv to signal a special build environment.

Andreas - I filed the new problem (after removing /.buildenv) yesterday #393030#, I've CC'd you on that (and Stefan) - it has various (hopefully useful) details.
HTH.

Comment 11: I see -- that's ugly. I think it will be safest to reintroduce the /.buildenv check for now, at least until we have fully analyzed the situation. That way we won't end up in a worse mess than what we have right now at least.

Comment 5: What are the reasons why the filesystem into which the packages are installed (apparently) has an /etc/fstab? Is a fake fstab required by other packages? Otherwise, would it make sense to ensure that no /etc/fstab exists while the image is being created? This would also stop the kernel %post from creating an initrd / trying to update the boot loader.

Another problem with skipping the bootloader configuration in the kernel %post is that the kernel %post is supposed to create the bootloader entries (and YaST won't otherwise do it for the kernel).

So on the one hand in some cases you want to skip creating the initrd because an initrd isn't needed, and on the other hand, you want to still invoke perl-Bootloader. This makes me wonder whether we shouldn't move the initrd creation into perl-Bootloader (which knows the kind of system, and knows whether an initrd make sense), and let the kernel %post invoke perl-Bootloader unconditionally.

the highly depends: if the perl-Bootloader will error out if it doesn't make sense or if the system is "misconfigured", this would be a problem. At least YAST_IS_RUNNING should be taken into account (which kiwi sets by now)

What do you think we should do or not do if YAST_IS_RUNNING? I would like kernel packages to "register" themselves with YaST (i.e., perl-Bootloader) when they are installed, independent of how the kernel is installed (YaST, rpm command line, etc.)

perl-Bootloader should know what kind of system it is running on, and so it should be able to "do the right thing".

The current assumption is that an initrd should always be created, but that's true only almost all the time. Therefore, we may want to move this into perl-Bootloader, so that all the boot environment dependencies will be centralized in one single place. For 11.0 this sounds quite late though.

the bare minimum I'm talking about: not creating errors from %post if YAST_IS_RUNNING is set.

I think the solution Andreas suggested would be a clean and future-proof
solution which would make some ugly hacks to disappear, but I think it's too
late for 11.0

YAST_IS_RUNNING is set by kiwi 

mass reopening of later+remind bugs of 11.0

according to comment #15 this should be addressed in yast

According comment #16 reassigned to kernel-maintainers

wasn't fixed in 2 years, no reason to keep it open any longer