Monthly Archives: June 2019

GRUB_CMDLINE_LINUX_DEFAULT

Posted on by

I had a system which failed to boot. The last lines printed to the screen, which were not relevant to the problem, were:

 [19.957783] async_tx: api initialized (async)
 [20.899732] Btrfs loaded, crc32c=crc32c-intel

Then a little bit later:

 [32.469926] random: crng init done
 [32.470551] random: 7 urandom warning(s) missed due to ratelimiting

The full problem description is here. And the solution is here (careful about the typo on that page, the only relevant setting is GRUB_CMDLINE_LINUX_DEFAULT).

Basically the problem was a bogus GRUB_CMDLINE_LINUX_DEFAULT setting in /etc/default/grub applied by my salt config. I fixed the setting which fixed the issue.

ata5: SATA link down (SStatus 1 SControl 300)

Posted on by

So I was getting error messages like this:

Jun 15 02:56:45 trust kernel: [  127.165096] ata5: SATA link down (SStatus 1 SControl 300)
Jun 15 02:56:45 trust kernel: [  127.165105] ata5: EH complete
Jun 15 02:56:45 trust kernel: [  127.174488] ata5: exception Emask 0x10 SAct 0x0 SErr 0x4040000 action 0xe frozen
Jun 15 02:56:45 trust kernel: [  127.178637] ata5: irq_stat 0x00000040, connection status changed
Jun 15 02:56:45 trust kernel: [  127.182700] ata5: SError: { CommWake DevExch }
Jun 15 02:56:45 trust kernel: [  127.186842] ata5: hard resetting link

The ‘ata5’ indicated SATA disk 5, being /dev/sde. Depending on which disk is affected you might see ‘ata1’, ‘ata2’, ‘ata3’, ‘ata4’, etc.

The problem seemed to be a loose cable. I have removed that drive (and its cables) and the problem has gone away.

Omitting date completed from MySQL dump file

Posted on by

By default when you run a dump with ‘mysqldump’ the date of the dump is appended to the file, e.g.:

jj5@love:~/desktop/experiment$ udiff *
--- dbt__jj_dev_1__svn_jdrepo.1.sql     2019-06-11 18:11:13.267758230 +1000
+++ dbt__jj_dev_1__svn_jdrepo.2.sql     2019-06-11 18:12:03.856075974 +1000
@@ -32,4 +32,4 @@
 /*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
 /*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;

--- Dump completed on 2019-06-10 21:59:44
+-- Dump completed on 2019-06-10 12:06:49

This causes dumps for a single database that has not changed to have two dumps which differ. It’s better to have dumps from the same unchanged database to be the same. To facilitate that add the –skip-dump-date option when running ‘mysqldump’.

See here for the back-story.

Fixing character encoding issue in ViewVC

Posted on by

So I was having an issue with ViewVC wherein UTF-8 content (a copyright symbol) was being garbled in the web browser.

I chased a number of red herrings (Content-Type headers, http-equiv, XHTML vs HTML5) but eventually found the culprit in the viewvc.conf settings.

I needed to change the ‘detect_encoding’ setting from ‘1’ to ‘0’. Once that was done my content was presented correctly:

## detect_encoding: Should we attempt to detect versioned file
## character encodings?  [Requires 'chardet' module, and is currently
## used only by the syntax coloration logic -- if enabled -- for the
## 'markup' and 'annotate' views; see 'enable_syntax_coloration'.]
##
# 2019-06-02 jj5 - OLD: this was bollocksing things up...
#detect_encoding = 1
# 2019-06-02 jj5 - NEW: so I changed it...
detect_encoding = 0
# 2019-06-02 jj5 - END