{"id":973,"date":"2012-12-08T20:13:35","date_gmt":"2012-12-09T01:13:35","guid":{"rendered":"http:\/\/scripts.mit.edu\/~zong\/wpress\/?p=973"},"modified":"2012-12-08T20:13:35","modified_gmt":"2012-12-09T01:13:35","slug":"disgusting-linux-package-installation-issues","status":"publish","type":"post","link":"https:\/\/blog.yhuang.org\/?p=973","title":{"rendered":"disgusting linux package installation issues"},"content":{"rendered":"<p>Was installing a package on Linux and ran into huge problems.<\/p>\n<p>First, the package &#8212; let&#8217;s call it &#8216;somecrap&#8217; &#8212; contained a post-installation configuration. Linux has this terminal pseudo-GUI used sometimes for configuration of packages. You may have seen it, it looks like ASCII art. Unfortunately it&#8217;s so brittle that when you Ctrl-Z out of it there is no way to get it back. So I had to just Ctrl-C out of it. Turns out the process that runs it (&#8216;whiptail&#8217;) is stuck using 100% of CPU. So that&#8217;s fine, it too can be killed, but how to get a configuration do-over? The package thinks it&#8217;s already configured &#8212; and indeed, wrote out a default configuration file. There is no way to get a redo short of removing and reinstalling the package. Right? And that&#8217;s where the real problem starts.<br \/>\n<!--more--><br \/>\nThe package uses &#8216;dbconfig-common&#8217;. When you remove the package, the database modifications are not reverted (understandable), but the database configuration file &#8216;\/etc\/dbconfig-common\/somecrap.conf&#8217; that was generated by this pseudo-GUI was also not removed. When you remove and reinstall the package, it refuses to reconfigure that file, probably because dbconfig-common thinks everything is already configured! So then I just deleted &#8216;somecrap.conf&#8217;, in the quite natural belief that the package will then rerun the configuration to generate it, like on a fresh install.<\/p>\n<p>Turns out no. Every installation gives<\/p>\n<p>dbconfig-common: writing config to \/etc\/dbconfig-common\/somecrap.conf<br \/>\nNot replacing deleted config file \/etc\/dbconfig-common\/somecrap.conf<br \/>\nunable to read input file \/etc\/dbconfig-common\/somecrap.conf<\/p>\n<p>And the configuration fails. It&#8217;s really unbelievable how fatuous &#8216;dbconfig-common&#8217; is here. Somewhere it&#8217;s tracking that &#8216;somecrap.conf&#8217; is supposed to exist, instead of determining whether it actually does, from the ground truth.<\/p>\n<p>All the ideas about removing, purging packages, reinstalling are not going to help here. The thing that worked was to reinstall dbconfig-common, to get it to fix itself:<\/p>\n<p>apt-get install &#8211;reinstall dbconfig-common<\/p>\n<p>debconf then screeches about &#8216;possible database corruption&#8217; and &#8216;adding back missing question&#8217; w.r.t. &#8216;dbconfig-common&#8217;. Reinstalling &#8216;somecrap&#8217; at this point finally brings back the original pseudo-GUI configuration process.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Was installing a package on Linux and ran into huge problems. First, the package &#8212; let&#8217;s call it &#8216;somecrap&#8217; &#8212; contained a post-installation configuration. Linux has this terminal pseudo-GUI used sometimes for configuration of packages. You may have seen it, it looks like ASCII art. Unfortunately it&#8217;s so brittle that when you Ctrl-Z out of [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[28,2592,2893,2889,2895,2285,2890,1130,2896],"class_list":["post-973","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-call","tag-conf","tag-database-configuration-file","tag-default-configuration-file","tag-installation","tag-linux","tag-linux-package","tag-package","tag-reinstall"],"_links":{"self":[{"href":"https:\/\/blog.yhuang.org\/index.php?rest_route=\/wp\/v2\/posts\/973","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.yhuang.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.yhuang.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.yhuang.org\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.yhuang.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=973"}],"version-history":[{"count":0,"href":"https:\/\/blog.yhuang.org\/index.php?rest_route=\/wp\/v2\/posts\/973\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.yhuang.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=973"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.yhuang.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=973"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.yhuang.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=973"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}