Description of problem: When user performs kickstart text mode installation, it stops with exception: 08:18:12 Not asking for VNC because of an automated install 08:18:12 Not asking for VNC because text mode was explicitly asked for in kickstart Starting automated install.. Generating updated storage configuration Checking storage configuration... ================================================================================ ================================================================================ Installation 1) [x] Installation source 2) [x] Timezone settings (http://download.eng.brq.redhat (America/New_York timezone) .com/pub/fedora/fedora-alt/stag 4) [x] Set root password e/19-RC2/Fedora/x86_64/os/) (Password is set.) 3) [x] Install Destination 6) [x] Software selection (Automatic partitioning selecte (GNOME Desktop) d) 5) [x] Create user Exception (No user will be created) yum.Errors.RepoError: RepoError() in <bound method YumSqlitePackageSack.__del__ of <yum.sqlitesack.YumSqlitePackageSack object at 0x7f524011ef90>> ignored Please make your choice from above ['q' to quit | 'c' to continue | 'r' to refresh]: Version-Release number of selected component (if applicable): anaconda-19.30.12-1 fedora-19-RC2 How reproducible: always Steps to Reproduce: 1. Start kickstart text mode installation, for example with following kickstart file: install lang en_US.UTF-8 keyboard us reboot text rootpw redhat timezone --utc America/New_York # partitioning: autopart bootloader --location=mbr zerombr clearpart --all --initlabel autopart %packages @standard %end Actual results: Automated kickstart installation stops with Exception, manual step is required from the user. yum.Errors.RepoError: RepoError() in <bound method YumSqlitePackageSack.__del__ of <yum.sqlitesack.YumSqlitePackageSack object at 0x7f524011ef90>> ignored Expected results: Installation should continue according to kickstart file, no action should be required from user Additional info:
Created attachment 765990 [details] anaconda.log
Created attachment 765991 [details] ifcfg.log
Created attachment 765992 [details] packaging.log
Created attachment 765993 [details] program.log
Created attachment 765994 [details] storage.log
Created attachment 765995 [details] storage.state
Created attachment 765996 [details] syslog
Proposing as a blocker. https://fedoraproject.org/wiki/Fedora_19_Beta_Release_Criteria#Unattended_installation "Unattended installation Any installation method or process designed to run unattended must do so. There should be no prompts requiring user intervention. "
The problem here is not in the exception that is written out. It happens every time and it is an internal yum exception that doesn't affect anaconda in any way. I'm not sure where the actual problem is, but it may be in the '@standard' group listed in the kickstart file which I'm not sure really exists.
Hello, It happens also with following kickstart, so this seems not to be problem with '@standard' package group install lang en_US.UTF-8 keyboard us reboot text rootpw redhat timezone --utc America/New_York # partitioning: autopart bootloader --location=mbr zerombr clearpart --all --initlabel autopart %packages vim %end
The problem (maybe bigger) is that the TUI software spoke overrides the kickstart package selection with GNOME. Thus the automatic installation stops and when continued by entering "c" it installs GNOME even if e.g. only 'vim' has been specified in the kickstart file. Patch sent to anaconda-patches. It can be tested with the following updates image: http://vpodzime.fedorapeople.org/978852_updates.img
Hi, Thanks for the updates.img, it seems it fixes the issue. There's no more "Gnome Desktop", but "Custom software selected".
I also tried some basic tests (interactive GUI + TUI installation, kickstart GUI + TUI installation), and all of them works well with the updates.img.
Same here, confirmed, the fix works, both interactive and non-interactive TUI installation. Patch https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-June/004788.html touches only tui software spoke and is pretty small.
That's a bug in Yum cleanup. My guess is that when Yum tries to close sqlite databases, some sqlite exception is raised. The @catchSqliteException decorator changes this to RepoError and re-raises. But we don't see the original exception, neither the full traceback. Is it possible to reproduce the bug with this patch applied, so the exception is printed in full? diff --git a/yum/sqlitesack.py b/yum/sqlitesack.py index 65401a9..98f7501 100644 --- a/yum/sqlitesack.py +++ b/yum/sqlitesack.py @@ -516,7 +516,6 @@ class YumSqlitePackageSack(yumRepo.YumPackageSack): } misc.unshare_data() - @catchSqliteException def close(self): self.dropCachedData() diff --git a/yum/yumRepo.py b/yum/yumRepo.py index 9e17753..7139b29 100644 --- a/yum/yumRepo.py +++ b/yum/yumRepo.py @@ -115,7 +115,11 @@ class YumPackageSack(packageSack.PackageSack): self.added = {} def __del__(self): - self.close() + try: + self.close() + except: + import traceback; traceback.print_exc() + raise def close(self): self.added = {} The __del__() method often runs too late, when extension modules are already unloaded. That's a design issue in Python. Does Kickstart store a YumBase() reference in a global variable, and does not delete it before shutdonw?
Confirmed with http://www.happyassassin.net/ks/ordered_unattended.ks with text. Also tested cmdline, which breaks worse: it hits the traceback, then throws a fit because 'Can't have a question in command line mode!' and goes to the crash handler. Given that we apparently have no non-graphical workaround for this, I'm afraid it might have to be a blocker. Count me +1 at this point.
confirmed the updates.img fixes this for both cmdline and text.
+1 blocker
+1 blocker here.
Setting acceptedblocker. time for a hero rc3, folks.
As I stated above - the change has limited scope of TUI and with mbanas we already covered a few tests with updates.img, not related only to TUI non-interactive test case.
python-blivet-0.17-1.fc19, anaconda-19.30.13-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/FEDORA-2013-11679/python-blivet-0.17-1.fc19,anaconda-19.30.13-1.fc19
rc3 works for me.
Fix looks to be confirmed in RC3.
python-blivet-0.17-1.fc19, anaconda-19.30.13-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.