Hide Forgot
Disks using the OEMDRV label are now correctly ignored during automatic installation The OEMDRV disk label is used on driver update disks during installation. Due to a bug, disks with this label were being used by Anaconda as installation targets during automatic installations, which meant they were being erased and used as part of the installed system storage. This update ensures that Anaconda ignores disks with this label unless they are explicitly selected as installation targets, and the problem no longer occurs.
Description of problem: - drive with OEMDRV label contains kickstart file which is picked up by anaconda automatically during RHEL 7 installation but it erases/formats the drive during installation unless we mention OEMDRV drive in 'ignoredisk' (ignoredisk --drives=disk/by-label/OEMDRV) Version-Release number of selected component (if applicable): - Red Hat Enterprise Linux 7 How reproducible: - sda is a USB stick with the installation image. sdb labelled as OEMDRV is a USB stick providing the ks.cfg and sdc is the internal disk and desired installation target. ~~~ Name LABEL sda RHEL-7.3 Server.x86_64 ├─sda1 RHEL-7.3 Server.x86_64 └─sda2 ANACONDA sdb OEMDRV sdc └─sdc1 ~~~ Actual results: - after the installation, anaconda erases/formats the drive OEMDRV Expected results: - it should not delete/format OEMDRV drive as it contains the kickstart file and one should be able used for other server's installation Additional info:
https://github.com/rhinstaller/blivet/pull/565
The patch from comment #9 doesn't work for me. First, oemdrv.name should be added to ksdata.ignoredisk.ignoredisk and even then it is too late at this point because ignored disks have been already hidden few lines above in devicetree.populate <- devicetree.reset <- storage.reset, so we'd probably have to call storage.config.update(ksdata) to update also storage config and storage.devicetree.hide(oemdrv) to make the ksdata change effective. I am working on another solution that would update ksdata.ignoredisk.ingnoredisk early after kickstart is parsed in anaconda so I am also reassigning the BZ back to the anaconda component.
https://github.com/rhinstaller/anaconda/pull/1009
Created attachment 1274595 [details] anaconda.log
Created attachment 1274596 [details] ifcfg.log
Created attachment 1274597 [details] packaging.log
Created attachment 1274598 [details] program.log
Created attachment 1274599 [details] storage.log
Created attachment 1274600 [details] storage.state
Created attachment 1274601 [details] syslog
Created attachment 1274603 [details] X.log
Although I tried only with pxe, I am not able to reproduce the fail. I have a suspicion that you hit an unrelated race condition. Are you able to reproduce it consistently?
Yes, this happens every time in VM, I could try it also on bare metal with flash drive. I boot from DVD, use kickstart mentioned in comment 2 which is located on /dev/vdb (1GB large - no partitioning table) formatted as ext4 with OEMDRV label.
I even tried wipefs -a /dev/vda but nothing changed.
Okay, I'll try to reproduce in VM then.
(In reply to Radek Vykydal from comment #26) > Okay, I'll try to reproduce in VM then. Tried once without issues with http://download.eng.brq.redhat.com/pub/rhel/nightly/RHEL-7.4-20170424.n.1/compose/Server/x86_64/os/ DVD install, vda, 1GB /dev/vdb formatted as ext4 with OEMDRV label, kicstart from comment#2
I didn't do network install, but installation from DVD as it's described in this bug.
(In reply to Pavel Holica from comment #28) > I didn't do network install, but installation from DVD as it's described in > this bug. Neither did I in comment #27, the link was meant just as a reference to the compose, I used DVD install. Is /dev/vda really only 1GB as the logs seem to say if I am reading them correctly? (In reply to Pavel Holica from comment #19) > Created attachment 1274599 [details] > storage.log 11:56:23,324 INFO blivet: scanning vda (/sys/devices/pci0000:00/0000:00:07.0/virtio1/block/vda)... 11:56:23,325 DEBUG blivet: DeviceTree.getDeviceByName: hidden: False ; name: vda ; incomplete: False ; 11:56:23,326 DEBUG blivet: DeviceTree.getDeviceByName returned None 11:56:23,328 DEBUG blivet: DeviceTree.addUdevDiskDevice: name: vda ; 11:56:23,328 WARN blivet: device/model is not a valid attribute 11:56:23,329 INFO blivet: vda is a disk 11:56:23,330 DEBUG blivet: getFormat('None') returning DeviceFormat instance with object id 9 11:56:23,334 DEBUG blivet: DiskDevice._setFormat: vda ; current: None ; type: None ; 11:56:23,335 DEBUG blivet: DiskDevice.readCurrentSize: path: /dev/vda ; sysfsPath: /sys/devices/pci0000:00/0000:00:07.0/virtio1/block/vda ; exists: True ; 11:56:23,339 DEBUG blivet: updated vda size to 1024 MiB (1024 MiB) (In reply to Pavel Holica from comment #15) > Created attachment 1274595 [details] > anaconda.log 11:56:26,690 ERR anaconda: storage configuration failed: Not enough free space on disks for automatic partitioning
Ah, I found it! Sorry for reopening this bug, the issue is indeed fixed. I made OEMDRV on the larger disk 20G instead of the 1G. My fault. The OEMDRV disk is not touched, moving to verified.
anaconda-26.21.8-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-f8d6a1f05a
anaconda-26.21.8-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-f8d6a1f05a
anaconda-26.21.9-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-f8d6a1f05a
anaconda-26.21.9-1.fc26, pykickstart-2.35-1.fc26, python-blivet-2.1.9-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-f8d6a1f05a
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2293