Bug 1272953 - QA:Testcase install repository HTTP/FTP variation failed for ppc64 and f23 TC1
Summary: QA:Testcase install repository HTTP/FTP variation failed for ppc64 and f23 TC1
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 23
Hardware: ppc64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-19 09:56 UTC by Menanteau Guy
Modified: 2015-10-23 13:01 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-23 13:01:18 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
screen log capture (50.54 KB, text/plain)
2015-10-19 09:56 UTC, Menanteau Guy
no flags Details

Description Menanteau Guy 2015-10-19 09:56:01 UTC
Created attachment 1084316 [details]
screen log capture

install f23 TC1 on ppc64 and ppc64le failed when using grub command with inst.repo  

I am using VM machines and run following command on grub (for ppc64):
linux /ppc/ppc64/vmlinuz inst.repo=http://ppc.koji.fedoraproject.org/compose/23_TC1/23_TC1/Server/ppc64/os/ ip=:::::eth0:dhcp;
initrd /ppc/ppc64/initrd.img;
boot

Installation start but got a "localhost dracut-initqueue[572]: Warning: Could not boot." at the end.

I was not able to get the /run/initramfs/rdsosreport.txt so I capture screen thru
a script command but I am not sure all screen lines have been catched.

Comment 1 Menanteau Guy 2015-10-19 14:09:51 UTC
problem seems triggered by the ip setting.
ip=:::::eth0:dhcp
 
Following command (without ip setting) works fine and install go to the end:
linux /ppc/ppc64/vmlinuz inst.repo=http://ppc.koji.fedoraproject.org/compose/23_TC1/23_TC1/Server/ppc64/os/;
initrd /ppc/ppc64/initrd.img;
boot

note that with same VM (and same network), installing a f22 in same condition works fine with the "ip=:::::eth0:dhcp" set in the grub command.

Comment 2 Peter Robinson 2015-10-20 10:09:18 UTC
Is it a new clean virtual disk or is there already an installation there? I've seen this before when there's been an incorrect command using a kickstart and it tries to do an upgrade

Comment 3 Menanteau Guy 2015-10-23 13:01:18 UTC
I found that ip interface defined in VM machine before install is not eth0 but enp0s0. I am not sure what have changed but using now ip=:::::enp0s0:dhcp;(or even ip=::::::dhcp) instead of ip=:::::eth0:dhcp; works fine.
Based on this, I assume my problem was a user problem and I close this bug.


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