MAX Error Log SD Caching?

[Hooovahh]

So I'm struggling to build some code that I've built many times before but things just aren't working out.  The code will always build just fine, but after it is deployed it isn't running.  In troubleshooting my issue I've tried rolling by SCC to something that was working and I started seeing log errors and was wondering what they meant and if they are related.  The exceptions are:

2018-03-30T17:49:49.646-04:00 NI-cDAQ-9132-002 kernel: [ 1.822961] Warning: unable to open an initial console.
2018-03-30T17:49:49.650-04:00 NI-cDAQ-9132-002 kernel: [ 3.645041] sd 2:0:0:0: [sdb] No Caching mode page found
2018-03-30T17:49:49.650-04:00 NI-cDAQ-9132-002 kernel: [ 3.645045] sd 2:0:0:0: [sdb] Assuming drive cache: write through

Attached is the whole log.  I don't need NI looking into the whole why it will build but doesn't work issue just yet.  I haven't isolated it, and I have lots of various SCC and reuse revisions giving me issues.  At the moment all I'm really interested in is this exception.  Is it something I should worry about?  I do have a 32GB SD card but I've never been logging to it.  It just contains some data that my RT application may read from.  For that reason I thought about just making the card read only (the switch on the card).  Thanks.

Oh this is LabVIEW 2017 SP1 32-bit, uses DAQmx, VISA, and XNet.  Host is Windows 7 x64, controller is cDAQ-9136.

[BradM · Accepted solution]

The warnings you're seeing are OK, the first (on the inability to open an initial console) is a harmless (if incorrect) configuration of the kernel commandline parameters, the second is a warning that's printed for most USB storage devices noting that the device does not describe its caching scheme, so the kernel makes a safe default assumption.

[Hooovahh]

Thanks, BTW my issue with a successful build, that was broken, was resolved by clearing the compile cache, closing and reopening the project, and building again.  As you can imagine this takes a long time with large projects.  Is this an issue that you think is Linux RT related, or RT in general?  It would be quite hard to reproduce this and isn't seen all the time.

[BradM]

"Good" to hear that the issue resolved itself with a clean rebuild. The issue that you ran into is likely somewhere in LV or how RT plugs in with LV. If you do manage to get it in a similar state again, it may make sense to try to zip up the contents of your project while LV is still running.