Bug 971656

(In reply to Benjamin Herrenschmidt from comment #0)
> Description of problem:
> 
> If Anaconda doesn't recognize the specific machine type from /proc/cpuinfo,
> it throws an exception and completely refuses to launch.
...

Thanks for your comments.

1. How are you launching anaconda?
2. What is in /proc/cpuinfo?
3. Could you attach an exception report or screenshot?

In this specific case I was attempting to install fc19 on a Freescale 64-bit embedded powerpc eval board (e5500 core, a p5020ds specifically but the specifics don't really matter, the issue would be the same with anything not recognized by Anaconda).

The standard fc19 kernel, of course, doesn't have built-in support for these (it's not even built for that CPU family, ie, 64-bit BookE) so I used a custom
kernel with all the necessary drivers built-in, and the fc19 dracut initrd.

I don't remember the specific details of the exception , I might be able to try again next week, but I do remember that Anaconda specifically tests for the machine type (pseries, powermac, ..) in /proc/cpuinfo and simply aborts if unrecognized (by looking at Anaconda python source).

This is fairly unfriendly behaviour :-) For example, that it can't install a bootloader would be understandable (since the bootloader setup can depend on the machine type) so maybe just skip that test with a warning....

How do you guys do on ARM ? Do you refuse to install on any board not specifically known/listed ?

It seems to me that it would be a lot better to allow the install (with a basic DOS disklabel and maybe not bootloader setup or just a standard grub2 setup). The user can fixup the boot later on.

Thanks for the additional info. The developers are far better qualified to comment than I am, but it sounds like you are proposing that Fedora support a new architecture:

Fedora Secondary Architectures
http://fedoraproject.org/get-fedora-options#2nd_arches

Architectures/ARM/F19 Release Announcement
http://fedoraproject.org/wiki/Architectures/ARM/F19_Release_Announcement

Source tar files can be downloaded from here:
https://git.fedorahosted.org/git/anaconda.git

Anaconda requires numerous other components:
anaconda-19.30.13-1/anaconda.spec.in

This finds files that appear to be related to kernels and bootloaders:
$ grep -Rl 'ARM' anaconda-19.30.13-1
anaconda-19.30.13-1/anaconda.spec.in
anaconda-19.30.13-1/pyanaconda/packaging/__init__.py
anaconda-19.30.13-1/pyanaconda/bootloader.py

$ grep -Rl 's390' anaconda-19.30.13-1
$ grep -Rl 'ppc' anaconda-19.30.13-1

Where did you see /proc/cpuinfo being analyzed?

$ grep -Rl '/proc/cpuinfo' anaconda-19.30.13-1
anaconda-19.30.13-1/data/liveinst/zz-liveinst.sh
anaconda-19.30.13-1/pyanaconda/isys/__init__.py

Oh no, I'm certainly not asking for Fedora to "support a new architecture" :-)

For all intend and purposes however, those embedded processors *are* just PowerPC ISA compliant, and thus Fedora userspace will just work (minus some issues with missing optional instructions that are generated by the fedora crop of gcc but we fix that up in the kernel nowadays).

I'm simply saying that it would be nice if Anaconda abstained from blowing up and at least tried to installed if it doesn't recognize the machine type (or sub-architecture, whatever you want to call it) :-)

This would be generally useful for people bringing up new machines, working on custom HW, etc... My mention of ARM was specifically because there is a lot more ARM stuff out there than will be "supported" out of the box by Fedora, and I was wondering whether Anaconda policy was also to just blow up on anything it doesn't recognize or at least give the developer a chance and try to install :-)

I will try to dig out the specific bit of Anaconda code I spotted back then that was causing the problem when I get a chance next week. I might even propose a patch.

This is definitely not something urgent nor even of major importance at this point, so feel free to reduce the importance/priority.

Do you expect most ppc and ppc64 packages to be compatible without being rebuilt?
http://mirrors.kernel.org/fedora-secondary/releases/19/Everything/

(In reply to Steve Tyler from comment #6)
> Do you expect most ppc and ppc64 packages to be compatible without being
> rebuilt?
> http://mirrors.kernel.org/fedora-secondary/releases/19/Everything/

"Only 64bit machines (Power5 or newer) are supported, but we still provide 32bit packages."
https://fedoraproject.org/wiki/Architectures/PowerPC

Fedora 19 for PPC64 Release Announcement
https://fedoraproject.org/wiki/Architectures/PowerPC/F19_release_announcement

Yes. e5500 is compliant with version 2.05 of the architecture, POWER5 is 2.02. So yes. The only problem in practice is that Fedora's gcc will emit instructions like fsqrt which are optional and not implemented on FSL chips, but as I said, we emulate them in the kernel, so it's not fast but works.

Similarily, if I were to create a new platform using a POWER8 chip tomorrow, all the packages would work, but the platform name in /proc/cpuinfo would be different (due to a different firmware interface for example).

Thanks, Benjamin. Now I finally understand ... :-)

If the exception you were getting was a Python traceback, that would probably be enough to identify what anaconda code is analyzing /proc/cpuinfo.

Adding a NEEDINFO for:
1. /proc/cpuinfo
2. Exception report
   (A screenshot or digital photo would be fine, if that is easier.)

FYI, the installer writes log files to /tmp in the install environment:
X.log
anaconda.log
ifcfg.log
packaging.log
program.log
storage.log
syslog

Thanks. I'll try to get those info some time this week (schedule is pretty hectic
but with a bit of luck I should manage).

How are you launching anaconda?

I'm asking, because launching from the command-line doesn't work: 
Bug 986573, Comment 12

Bug 986573 - LVMError: lvdeactivate failed for root: running lvm lvchange -a n --config devices { filter=["r|/loop0$|","r|/loop1$|","r|/loop2$|","r|/loop3$|","r|/loop4$|","r|/loop5$|","r|/loop6$|","r|/loop7$|"] } fedora/root failed

(In reply to Benjamin Herrenschmidt from comment #2)
> ... the fc19 dracut initrd. ...

Could you confirm that this is unmodified?

(In reply to Benjamin Herrenschmidt from comment #2)
...
> ... Anaconda specifically tests for
> the machine type (pseries, powermac, ..) in /proc/cpuinfo
...

I can't find "pseries" or "powermac" in the initrd.img on the F19 DVD.

Procedure:

$ sudo mount -o loop Fedora-19-x86_64-DVD.iso /mnt/spare1
$ ls /mnt/spare1/isolinux/
$ xzcat /mnt/spare1/isolinux/initrd.img | cpio -iv | less
$ egrep -Rli 'pseries|powermac' .

Yes, it was unmodified, but pre-final fc19 (around the beta). The test wasn't there, the test was in the next stage after it loads the netinst ISO and runs from there iirc. As I said, this was a while ago and my memory isn't fresh, I'll try to get you the info, I remember Tony Breeds helped me locate the instance of the check in the Anaconda code.

Don't worry too much, I'll get you the details.

It's somewhat documented at:
https://lists.fedoraproject.org/pipermail/ppc/2013-June/002291.html

Now I understand that the code in that area has changed a little.  so there wont be 100% match.

Thanks, Tony.

So it's python-blivet that does the checks ...

F19 versions are:
$ sudo repoquery anaconda python-blivet
anaconda-0:19.30.13-1.fc19.x86_64
python-blivet-0:0.17-1.fc19.noarch

Source tar files are here:
https://git.fedorahosted.org/git/anaconda.git
https://git.fedorahosted.org/git/blivet.git

$ grep -Rl '/proc/cpuinfo' blivet-0.17-1/
blivet-0.17-1/blivet/arch.py

There's too much to paste, so here is a link to the 0.17-1 arch.py in git:
https://git.fedorahosted.org/cgit/blivet.git/tree/blivet/arch.py?id=blivet-0.17-1

Can you boot a Live image?

Since anaconda is Python code, you can modify it as you like in the Live environment _before_ running the installer. I have done this a few times. To find your file in the Live environment run:

$ rpm -ql python-blivet | grep arch.py

You can also scp files on and off the Live environment, or just ssh to another system and copy and paste text. You have to install patch:

$ sudo yum install patch

Too many of the decisions of that anaconda needs to make regarding storage and bootloaders are platform dependent. If you are working on a new hardware platform, that means making modifications to the installer.

Suuuuure ... so rather than doing something sensible that has about 90% chances of being exactly what is needed, that is no bootloader install and a default
dos partition map for storage, let's instead throw a useless python backtrace in the face and die a horrible death.

I knew being a pile of crap used to be an Anaconda design point, I see that
hasn't changed.

(In reply to Benjamin Herrenschmidt from comment #21)
> Suuuuure ... so rather than doing something sensible that has about 90%
> chances of being exactly what is needed, that is no bootloader install and a
> default
> dos partition map for storage, let's instead throw a useless python
> backtrace in the face and die a horrible death.
> 
> I knew being a pile of crap used to be an Anaconda design point, I see that
> hasn't changed.

https://git.fedorahosted.org/cgit/anaconda.git/