Bug 1507676

Summary: AArch64 disk images include '/etc/sysconfig/network-scripts/ifcfg-enp1s0'
Product: [Fedora] Fedora Reporter: Paul Whalen <pwhalen>
Component: spin-kickstartsAssignee: Peter Robinson <pbrobinson>
Status: CLOSED DEFERRED QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 27CC: admiller, awilliam, bruno, dustymabe, gmarr, kevin, pbrobinson, vanmeeuwen+fedora, vpavlin
Target Milestone: ---   
Target Release: ---   
Hardware: aarch64   
OS: Linux   
Whiteboard: AcceptedFreezeException
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-11-10 15:24:52 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 245418, 1396705    

Description Paul Whalen 2017-10-30 21:54:28 UTC
Description of problem:
AArch64 disk images include '/etc/sysconfig/network-scripts/ifcfg-enp1s0'. This configuration file should be removed from the image after creation to avoid conflicts.

cat ./etc/sysconfig/network-scripts/ifcfg-enp1s0
# Generated by dracut initrd
NAME="enp1s0"
DEVICE="enp1s0"
ONBOOT="yes"
NETBOOT="yes"
UUID="1f4fa52a-765b-467d-be98-2ac3fdb49490"
IPV6INIT="yes"
BOOTPROTO="dhcp"
TYPE="Ethernet"
PROXY_METHOD="none"
BROWSER_ONLY="no"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_FAILURE_FATAL="no"


Version-Release number of selected component (if applicable):
Latest disk images in F27.

Comment 1 Peter Robinson 2017-11-03 18:26:52 UTC
https://pagure.io/fedora-kickstarts/pull-request/313

Comment 2 Paul Whalen 2017-11-03 18:31:59 UTC
Proposed FE for final.

Comment 3 Adam Williamson 2017-11-03 19:09:11 UTC
This sounds worth an FE, though I'm *slightly* worried that the change will apply to all disk images (some of which are release-blocking). It looks both safe and correct (until the name of the interface changes due to some change in ImageFactory or systemd or kernel, of course...), but there's always the chance...

Comment 4 Peter Robinson 2017-11-04 11:46:17 UTC
(In reply to Adam Williamson from comment #3)
> This sounds worth an FE, though I'm *slightly* worried that the change will
> apply to all disk images (some of which are release-blocking). It looks both

It doesn't affect anything except aarch64 images, if you grep for the includes you'll see the only included ones are used currently for aarch64:

fedora-disk-base.ks:# fedora-disk-base.ks
fedora-disk-minimal.ks:%include fedora-disk-base.ks
fedora-disk-server.ks:%include fedora-disk-base.ks
fedora-disk-workstation.ks:%include fedora-disk-base.ks

> safe and correct (until the name of the interface changes due to some change
> in ImageFactory or systemd or kernel, of course...), but there's always the
> chance...

Sure, but it actually doesn't just come down to interface name (which is static due to PCI buses/slots) but also the HWADDR generated by libvirt/qemu for the virtual NIC, and yes these happen in a range allowed for allocation but it's extremely unlikely, even if a device (and there are somee) has a pci attached NIC on BUS 1 slot 0, that it'll have the same MAC address of that which was automatically generated and network manager/initial-setup can recreate the file.

All those words to justify I feel this is a safe operation :)

Comment 5 Adam Williamson 2017-11-06 17:56:48 UTC
"if you grep for the includes you'll see the only included ones are used currently for aarch64:"

but they're not *only* used for aarch64, are they? they're also used for generating the cloud and 32-bit ARM disk images, aren't they?

Comment 6 Peter Robinson 2017-11-06 18:18:52 UTC
(In reply to Adam Williamson from comment #5)
> "if you grep for the includes you'll see the only included ones are used
> currently for aarch64:"
> 
> but they're not *only* used for aarch64, are they? they're also used for
> generating the cloud and 32-bit ARM disk images, aren't they?

Yes they *only* used in <= F27 (and currently rawhide but this is out of scope for this bug):

[perobins@neo fedora-kickstarts (f27 %)]$ grep fedora-disk-base.ks *
grep: custom: Is a directory
fedora-disk-base.ks:# fedora-disk-base.ks
fedora-disk-minimal.ks:%include fedora-disk-base.ks
fedora-disk-server.ks:%include fedora-disk-base.ks
fedora-disk-workstation.ks:%include fedora-disk-base.ks
grep: l10n: Is a directory
grep: snippets: Is a directory
grep: templates: Is a directory
grep: tools: Is a directory
[perobins@neo fedora-kickstarts (f27 %)]$ 


Then if you reference the fedora pungi config:
https://pagure.io/pungi-fedora/blob/f27/f/fedora.conf#_405

You'll see that fedora-disk* is only referenced with aarch64 users

Comment 7 Geoffrey Marr 2017-11-06 19:39:28 UTC
Discussed during the 2017-11-06 blocker review meeting: [1]

The decision to classify this bug as an AcceptedFreezeException was made as the bug cannot be fixed with an update and only affects aarch64 images.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2017-11-06/f27-blocker-review.2017-11-06-17.00.txt

Comment 8 Adam Williamson 2017-11-09 22:19:03 UTC
Well, this was granted an FE but the PR was never merged, apparently...what's the status?

Comment 9 Peter Robinson 2017-11-10 15:24:52 UTC
(In reply to Adam Williamson from comment #8)
> Well, this was granted an FE but the PR was never merged,
> apparently...what's the status?

Not sure who was meant to merge it. I'll just add it now as a common bugs entry so it's documented.