This turns out to be because the sql in openvas-manager depends on a newer version of sqlite than what's in hardy. (hardy has 3.4, 3.6 works) backporting that, and the rebuilding openvas-manger solves that problem.
Things seem to be running, but it'll take awhile for this scan to finish. For others, my various debian packaging scripts are all hanging off http://github.com/directionless with obvious names. seph seph <[email protected]> writes: > But, trying to actually start a job through GSA still produces sqlite > errors in the openvasmd log: > > md main: DEBUG:2010-04-07 18h44.11 utc :2591: sql: SELECT oid, > version, name, summary, description, copyright, cve, bid, xref, tag, > sign_key_ids, category, family FROM nvts WHERE family = 'Service > detection' EXCEPT SELECT oid, version, nvts.name, summary, description, > copyright, cve, bid, xref, tag, sign_key_ids, category, nvts.family FROM > nvt_selectors, nvts WHERE nvts.family = 'Service detection' AND > nvt_selectors.name = '54b45713-d4f4-4435-b20d-304c175ed8c5' AND > nvt_selectors.family = 'Service detection' AND nvt_selectors.type = 2 > AND nvt_selectors.exclude = 1 AND nvts.oid == > nvt_selectors.family_or_nvt ORDER BY nvts.name ASC; > > md main:WARNING:2010-04-07 18h44.11 utc :2591: init_iterator: > sqlite3_prepare failed: ORDER BY term number 1 does not match any result > column _______________________________________________ Openvas-discuss mailing list [email protected] http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss
