Bug 1156008

Created attachment 949824 [details]
File: anaconda-tb

Created attachment 949825 [details]
File: anaconda.log

Created attachment 949826 [details]
File: environ

Created attachment 949827 [details]
File: ks.cfg

Created attachment 949828 [details]
File: lsblk_output

Created attachment 949829 [details]
File: nmcli_dev_list

Created attachment 949830 [details]
File: os_info

Created attachment 949831 [details]
File: program.log

Created attachment 949832 [details]
File: storage.log

Created attachment 949833 [details]
File: syslog

Created attachment 949834 [details]
File: ifcfg.log

Created attachment 949835 [details]
File: packaging.log

Another user experienced a similar problem:

Yet another crash during kickstarted installation. Most probably a duplicate of bug 1156008.

addons:         com_redhat_kdump
cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-S-21_B_T4-x86_64 quiet inst.ks=hd:vda1:/ks.cfg
hashmarkername: anaconda
kernel:         3.17.0-301.fc21.x86_64
package:        anaconda-21.48.10-1
product:        Fedora"
reason:         OSError: [Errno 2] No such file or directory
release:        Cannot get release name.
version:        Fedora

Another user experienced a similar problem:

And another crash. Duplicate of bug 1156008, most probably.

addons:         com_redhat_kdump
cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   ks=file:///ks.cfg  inst.stage2=http://download.eng.brq.redhat.com/pub/fedora/fedora-alt/stage/21_Beta_TC4/Server/x86_64/os/
hashmarkername: anaconda
kernel:         3.17.0-301.fc21.x86_64
package:        anaconda-21.48.10-1
product:        Fedora"
reason:         OSError: [Errno 2] No such file or directory
release:        Cannot get release name.
version:        Fedora

Looks like new-kernel-pkg is missing for some reason:

13:48:39,323 INFO program: Running... new-kernel-pkg --mkinitrd --dracut --depmod --update 3.17.1-302.fc21.x86_64
13:48:39,335 ERR program: Error running new-kernel-pkg: No such file or directory

Maybe a comps error ?

Another user experienced a similar problem:

And another crash, yay. I'm fairly certain now what causes it, it's %packages --nocore. If I don't specify --nocore (which means select @core by default), everything works correctly.

addons:         com_redhat_kdump
cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-S-21_B_T4-x86_64 quiet inst.ks=http://192.168.11.1:8000/ks.cfg
hashmarkername: anaconda
kernel:         3.17.0-301.fc21.x86_64
package:        anaconda-21.48.10-1
product:        Fedora"
reason:         OSError: [Errno 2] No such file or directory
release:        Cannot get release name.
version:        Fedora

Having functional --nocore might be important for some people (ultra small deployments), so I'm proposing this as a Final blocker. We probably have no better criteria than:
https://fedoraproject.org/wiki/Fedora_21_Beta_Release_Criteria#Unattended_installation

Another user experienced a similar problem:

I have tried kparal's kickstart file and encountered same problem.

addons:         com_redhat_kdump
cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-S-21_B_T4-x86_64 quiet inst.ks=http://192.168.122.1:8000/kamil-ks.cfg
hashmarkername: anaconda
kernel:         3.17.0-301.fc21.x86_64
package:        anaconda-21.48.10-1
product:        Fedora"
reason:         OSError: [Errno 2] No such file or directory
release:        Cannot get release name.
version:        Fedora

The whole point of --nocore is that you get to keep the pieces if you break things.

In this case you're missing grubby which provides new-kernel-pkg.

Sorry to reopen this, but this is not sufficient. Current documentation doesn't say anything any --nocore being dangerous or "you're on your own"-style option:
http://fedoraproject.org/wiki/Anaconda/Kickstart

     --nocore 
        Do not install the @core group (installed by default, otherwise). 

If there was such information, I wouldn't have reported this bug in the first place.

> The whole point of --nocore is that you get to keep the pieces if you break things.

And my point is - how should I have known? And how should the users know?

Anaconda is not doing really well at keeping its documentation up to date and relevant. I'd like that to improve. Documentation *is* a part of the program and quite a few people act according to it.

I'd edit the wiki myself, if I felt like knowing all the background, but as you can see, I don't. Please put more info into the wiki, thanks.

This is common sense stuff here - if you disable the group that includes all the useful base stuff, things are gonna fail.  You're not a new Fedora user, so stop acting like one.  You know what's in these groups and when things are likely to fail.  This was added specifically for building cloud images, not for general user consumption.

Now you have all the same background we do.  This is a group project, and there's a specific reason stuff like this is on the wiki - so anyone can do the editing.  Now you can go and do it too.  See, that would help keep documentation up to date and relevant.

I still don't feel like having the same background as you, but I made the change myself here:
https://fedoraproject.org/w/index.php?title=Anaconda%2FKickstart&diff=392537&oldid=390965

No, as I said - this was added specifically for building cloud images.  I didn't say it wasn't supported.

That's what I understood from comment 19. But it's a nice illustration why I believe it's more time effective if people having the full information edit the documentation, rather than relying on middlemen. I don't really understand why we're having this conversion in the first place. Instead of discussing with me, any of you could have provided 100% correction information on the wiki already, and save a lot of time as well. Whenever I report a problem in anaconda's documentation, I have this feeling of "not our problem, you fix it" approach. And so I do try to fix it, if there's really no other way.

It should be pretty obvious that

%packages --nocore
%end

isn't going to do anything useful. So instead of seeing that this is an area in kickstart documentation that could be clarified, you decided to be obtuse about it and provide incorrect information. And we're the ones being unhelpful.

It seems I'm the one having a bad day, after all.

I can assure you it wasn't any obvious to me that
%packages --nocore
%end
is not going to do anything useful. Quite the opposite, I was trying to heavily optimize shortly before Beta final validation to have as small "minimal installation" as possible, and the selection above resulted in mere 150 packages, thus helping me to execute more test cases quicker (at least that was the idea). If I knew this was not going work properly, I wouldn't have wasted time (quite precious, yesterday and today) debugging, reporting, and asking my colleagues to reproduce it. Let's describe that as obtuse. Not deliberately, though.

My prime goal is to have it covered in documentation, because I know I forget easily and I'd fall into the same trap during the next or next+1 release. I have made my documentation edit before ever seeing comment 21 (which was actually a mid-air collision), so much for providing "incorrect information". But if you don't find it ridiculous, please hand me a snippet that is accurate and intended for the end-user, and I'll paste it into the wiki.