Description of problem: anaconda puts the ks used for building into /root/*.ks and the logs into /var/log/anaconda. We should keep these artifacts for debugging, but should keep them elsewhere to hide them from the users. Probably a task for imgbase build --postprocess.
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.
/var/log/anaconda should be removed by imgbased
/root/anaconda-ks.cfg should also be removed
*** Bug 1371363 has been marked as a duplicate of this bug. ***
The logs should actually not get _removed_ but rather moved out of sight, i.e. into /var/log/anaconda-install/
*** Bug 1340490 has been marked as a duplicate of this bug. ***
The ks.cfg and anaconda logs are copied to the image after the post install scripts are finished, so we can't use imgbased to hide the logs. Instead of hiding the logs, perhaps we could use inst.nosave=all to avoid copying those files at all, if this is acceptable.
Interesting. You can use the arg to avoid the logs, but then you don't have them for debugging. Otherwise you could add a task to imgbase postprocessing to move them away. I'm not sure what the better solution is.
(In reply to Fabian Deutsch from comment #8) > Interesting. > > You can use the arg to avoid the logs, but then you don't have them for > debugging. > Otherwise you could add a task to imgbase postprocessing to move them away. > > I'm not sure what the better solution is. postprocess runs inside the kickstart's %post when building the image, and anaconda copies the logs to the image after kickstart's %post. The only way is either to not copy them at all (nosave), or in the first boot of the image.
There is no 4.2 build deliver to QE for testing, so move this bug to MODIFIED status.
After discussing this with qe, hiding all logs is not a good idea, considering an alternate solution.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Test Versions: ovirt-node-ng-installer-ovirt-4.2-pre-2017092713.iso Test Steps: 1. Install the iso 2. After installation finished, check: # ls /root # ls -al /var/log/anaconda Test Results: 1. There is no *ks* under /root 2. There is no build log under /var/log/anaconda: [root@dell-per730-34 ~]# ls -al /var/log/anaconda/ total 3252 drwxr-xr-x. 2 root root 4096 Oct 16 2017 . drwxr-xr-x. 19 root root 4096 Oct 16 09:55 .. -rw-------. 1 root root 23837 Oct 16 2017 anaconda.log -rw-------. 1 root root 49421 Oct 16 2017 ifcfg.log -rw-------. 1 root root 1946623 Oct 16 2017 journal.log -rw-------. 1 root root 0 Oct 16 2017 ks-script-9YPO5i.log -rw-------. 1 root root 0 Oct 16 2017 ks-script-DX1dU7.log -rw-------. 1 root root 2169 Oct 16 2017 ks-script-rrqSGw.log -rw-------. 1 root root 214 Oct 16 2017 packaging.log -rw-------. 1 root root 254897 Oct 16 2017 program.log -rw-------. 1 root root 551389 Oct 16 2017 storage.log -rw-------. 1 root root 456948 Oct 16 2017 syslog -rw-------. 1 root root 15905 Oct 16 2017 X.log In addition, checked ovirt-node-ng_ovirt-4.2-pre_build-artifacts, the anaconda-ks.cfg, original-ks.cfg and build logs are under exported-artifacts/image-logs, just as designed. So, set the bug status to VERIFIED.
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.