The Questions That Come After the First Unit Arrives
The sourcing list is short: CPU, memory, I/O count, form factor, price. The deployment list is longer, and it is the one that decides whether the project is still running in year three.
Two categories come up repeatedly, across customers and across markets:
- The software stack — driver packages, BIOS defaults, watchdog behaviour, kernel version compatibility. None of this is a hardware problem. All of it determines whether the hardware that just arrived goes into production, or sits on a bench while someone works out the stack.
- The service model — where an RMA actually ships to, how long a replacement board takes, what happens in year four when the original SKU is no longer in production.
Neither list changes the price on the quotation. Both change whether the deployment survives.
1. The software stack
Driver package policy
The question that matters is not “do you supply drivers” — everyone says yes. It is whether the package is maintained for the life of the SKU, or frozen at the date the first unit shipped.
The failure mode is specific and common. A customer deploys on a validated kernel, runs for eighteen months, then updates the kernel for a security patch. In-tree drivers survive the update. Anything out-of-tree does not — and on an industrial board that typically means GPIO, the watchdog, SMBus and hardware monitoring. The Ethernet keeps working, so the failure looks unrelated to the driver package until someone traces it.
Ask:
- Which drivers are in-tree, and which are out-of-tree modules supplied by you?
- Is the package rebuilt when a new kernel branch appears, or frozen at ship date?
- What is the oldest and newest kernel version this board has been validated against?
- Is there a changelog, or a version number that identifies which package a unit shipped with?
BIOS defaults for unattended operation
A machine in a cabinet has nobody to press a key. A board configured with desktop defaults will eventually stop at a prompt and wait.
The settings that matter:
| Setting | Why |
|---|---|
| Power-on after power fail | Determines whether the unit restarts by itself. Three states are useful: always on, always off, last state |
| Halt on error | A desktop default stops boot on a non-critical error. An unattended system should continue |
| Boot order with no media present | A unit that drops to a boot menu when a USB stick is left plugged in is a site visit |
| Watchdog enable and timeout | Covered below |
| Wake-on-LAN | Needs NIC support, BIOS enablement, and the correct power state — all three, or it silently does not work |
| RTC wake / scheduled restart | For planned maintenance windows |
Ask whether these can be set at the factory and shipped as the default, rather than configured by hand on every unit on arrival. For a fleet of 200, that difference is real work.
Watchdog behaviour
“Supports watchdog” is not a specification. The useful questions:
- Is the watchdog reset by the BIOS, or does the application have to service it?
- What is the timeout range, and is it configurable?
- Does it reset the system, or only signal?
- Is there a driver for the OS you intend to run, and is it in-tree?
A watchdog the application cannot reach is not doing the job it was specified for.
Kernel version drift
A customer who has standardised on a specific kernel across their fleet will not change it for one board. The honest exchange is:
“We validated against kernel X. You are on kernel Y. Here is what we know works, here is what we have not tested, and here is what we expect to need rebuilding.”
A supplier who answers “it supports Linux” has not tested it on your kernel and is telling you so without meaning to.
2. The service model
Where does an RMA actually ship to?
For most industrial computers sourced from China, the honest answer is: back to the factory. That is not a problem in itself — but it has consequences that belong in the project plan rather than in a surprise.
The questions:
- What is the physical return address, and who arranges and pays freight in each direction?
- What is realistic turnaround, including freight and customs both ways — not bench time alone?
- Is there advance replacement, or is it repair-and-return?
The last one is the one that changes deployments. Repair-and-return means the machine is down for the entire cycle. Advance replacement means it is down for the outbound shipping time only. The difference is weeks, and it is usually negotiable at order time and not negotiable afterwards.
Spares, honestly
For most OEM deployments, the practical answer is not a service network — it is spare units or spare boards bought at order time and held locally.
A supplier who claims a European or North American repair capability at modest volume should be asked where it is and who operates it. The honest alternative — “there is no local depot; here is the advance-replacement process and here is what we recommend you hold as spares” — is more useful than a service network that exists on a slide.
Year four: end of life
Every platform ends. What distinguishes suppliers is what happens when it does.
- How much notice is given before a platform change?
- Is there a last-time-buy window, and how long?
- Is the replacement pin-compatible and mechanically identical, or does the chassis change?
- If the mechanical design changes, what re-certification does that trigger on your side?
That last question is the expensive one. An OEM who has certified a finished machine around a specific board carries the re-certification cost when the board changes shape. That cost belongs in the supplier evaluation, not in an email two years later.
For the related question of what to verify about a supplier before the first PO — manufacturing, certification evidence, customisation limits — see our supplier evaluation guide.
3. A short list worth asking before the PO goes out
Four questions. The answers are more revealing than the specification sheet.
1. What is the driver package policy — maintained for the lifetime of the SKU, or frozen at ship date? A good answer names which drivers are out-of-tree and what happens when a kernel branch changes. A vague answer means frozen.
2. What is realistic RMA turnaround, including freight both ways? A good answer is a range in weeks with the freight legs stated separately. A single optimistic number usually describes bench time only.
3. If this SKU goes end-of-life, what is the migration path and how much notice do we get? A good answer distinguishes between a component change, a pin-compatible replacement and a mechanical change — because those carry very different costs for you.
4. Who in your organisation answers an engineering question in year three — the sales rep who sold it, or someone else?
The fourth is usually the most revealing, and the answer is not always “a bigger company is better.” A large supplier has a documented escalation path and a ticket number. A small one often means the person who answers in year three is the same person who answered in year one, and they remember your configuration. Both can work. What does not work is a supplier who cannot describe the path at all — because it means the question has never been asked of them, and you will be the one who finds out.
What a supplier can honestly commit to
Being explicit, because overcommitment in this area is common and easy to spot:
- “Lifetime driver support” is not a meaningful commitment unless the lifetime is defined. A scoped answer — “maintained while the SKU is in production, plus X years” — is worth more than an unbounded one.
- Nobody can guarantee a CPU platform’s availability beyond what the silicon vendor commits to. What a supplier can commit to is notice period, last-time-buy terms and the migration path.
- A validated kernel list is a snapshot. It tells you what was tested, not what will work forever. That is a reasonable limitation, stated honestly.
- An RMA number is not a turnaround commitment. Ask for the range, in writing, with freight included.
Frequently asked questions
Why would a driver package break after a kernel update if the hardware has not changed? In-tree drivers are maintained with the kernel and survive updates. Out-of-tree modules — commonly GPIO, watchdog, SMBus and hardware monitoring on industrial boards — must be rebuilt against the new kernel headers. If the supplier’s package was frozen at ship date, there is nothing to rebuild from.
Is advance replacement normal for industrial PCs? It is common for OEM and volume accounts, and usually agreed at order time rather than requested after a failure. For small quantities, holding a spare unit locally often achieves the same result at lower cost.
How much end-of-life notice is reasonable? There is no universal figure, and it depends on what the silicon vendor commits to for the platform. What matters is that the supplier states a notice period and a last-time-buy policy rather than leaving it undefined.
Does a smaller supplier mean worse long-term support? Not necessarily — it means different support. A larger organisation offers a documented escalation path; a smaller one often offers continuity of the same engineers. The question to ask is whether they can describe the path, not how many people are in it.
Can BIOS settings be configured at the factory? On most industrial boards, yes — and for any fleet deployment it is worth requesting, since configuring unattended-boot behaviour by hand on every unit is avoidable work.
Working with VstrongTech
If you are specifying industrial computers for a deployment rather than a one-off build, send us the second list — your kernel version, your unattended-boot requirements, your fleet management approach and your service expectations — alongside the hardware specification.
We would rather answer those questions before the PO than after the first unit arrives.
Send your deployment requirements →
And a question back, for the engineers and procurement teams who have been through this: what is one question you learned to ask up front that you were not asking before it cost you? We read every reply.