This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 971656 - Anacoda shouldn't throw exceptions on unknown machines
Anacoda shouldn't throw exceptions on unknown machines
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
19
ppc64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-07 01:46 EDT by Benjamin Herrenschmidt
Modified: 2014-03-11 05:16 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-03-10 17:52:28 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Benjamin Herrenschmidt 2013-06-07 01:46:36 EDT
Description of problem:

If Anaconda doesn't recognize the specific machine type from /proc/cpuinfo,
it throws an exception and completely refuses to launch.

This makes no sense. Why prevent people working on new HW platforms from
doing an install or forcing them to do it the really hard way ? It also
means it will refuse to install on a whole bunch of powerpc embedded
platforms such as the freescale ones.

Yes, the Fedora kernel will probably not work nor will it be able to
install a bootloader, neither of which should be preventing the overall
distro install, which we can then boot using a custom kernel (just like
we boot the installer in the first place).

The debian installer doesn't have that problem.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 1 Steve Tyler 2013-07-20 01:17:18 EDT
(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?
Comment 2 Benjamin Herrenschmidt 2013-07-21 01:54:34 EDT
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.
Comment 3 Steve Tyler 2013-07-21 03:12:33 EDT
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
Comment 4 Steve Tyler 2013-07-21 03:36:23 EDT
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
Comment 5 Benjamin Herrenschmidt 2013-07-21 03:59:01 EDT
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.
Comment 6 Steve Tyler 2013-07-21 10:26:48 EDT
Do you expect most ppc and ppc64 packages to be compatible without being rebuilt?
http://mirrors.kernel.org/fedora-secondary/releases/19/Everything/
Comment 7 Steve Tyler 2013-07-21 10:50:09 EDT
(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
Comment 8 Benjamin Herrenschmidt 2013-07-21 15:56:53 EDT
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).
Comment 9 Steve Tyler 2013-07-21 16:43:17 EDT
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.
Comment 10 Steve Tyler 2013-07-21 17:17:43 EDT
Adding a NEEDINFO for:
1. /proc/cpuinfo
2. Exception report
   (A screenshot or digital photo would be fine, if that is easier.)
Comment 11 Steve Tyler 2013-07-21 17:45:12 EDT
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
Comment 12 Benjamin Herrenschmidt 2013-07-21 17:49:58 EDT
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).
Comment 13 Steve Tyler 2013-07-22 11:38:39 EDT
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
Comment 14 Steve Tyler 2013-07-22 11:57:55 EDT
(In reply to Benjamin Herrenschmidt from comment #2)
> ... the fc19 dracut initrd. ...

Could you confirm that this is unmodified?
Comment 15 Steve Tyler 2013-07-22 12:48:45 EDT
(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' .
Comment 16 Benjamin Herrenschmidt 2013-07-22 18:00:15 EDT
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.
Comment 17 Tony Breeds 2013-07-23 00:28:52 EDT
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.
Comment 18 Steve Tyler 2013-07-23 02:10:34 EDT
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
Comment 19 Steve Tyler 2013-07-23 02:26:42 EDT
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
Comment 20 David Shea 2014-03-10 17:52:28 EDT
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.
Comment 21 Benjamin Herrenschmidt 2014-03-10 20:14:07 EDT
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.
Comment 22 Vratislav Podzimek 2014-03-11 05:16:45 EDT
(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/

Note You need to log in before you can comment on or make changes to this bug.