Ubuntu 15 on Precision 5810 No bootable device found

Just registering a slightly off-topic note: the Dell Precision Tower 5810 firmware revision A05 has bugs causing problems with the Ubuntu EFI boot loader.

After installing in EFI mode, the firmware does not find the boot loader, causing the error “No bootable device found“.

The cause of this error is that the firmware expects the boot loader to be \efi\boot\bootx64.efi. On the other hand, Ubuntu Grub boot loader installs a file which is \efi\ubuntu\grubx64.efi.

Worse, the firmware overrides any value specified using efibootmgr

For example:

efibootmgr -c -l \\EFI\\ubuntu\\grubx64.efi -L Ubuntu
efibootmgr -v
ubuntu HD(1,800, [..]) File(\EFI\ubuntu\grubx64.efi)

reboot
efibootmgr -v
ubuntu Vendor(99e2[..])

To complete, the firmware configuration utility is equally useless. It lets select the right boot loader but does not persist the selected path.

Fortunately, this problem can easily be solved installing an updated version of the Dell firmware. I installed version A07 and everything worked ok.

How did it succeed ?

This project was doomed to failure.

  • Client involvement was minimal. There was no clear requirements definition, the client only appointed a business unit manager as single point of contact. But this manager had many other things to do, more important to her than “taking care of the system”. There was no infrastructure to support the system in production.
  • Requirements were complex: the system to build was a customized ERP incorporating the client’s business processes and rules – which were very different from what commonly exists. This ERP should manage contracting and offering, clients and prospects relationships, invoicing and payments, stock and inventory, bar sales, accounting statements and much more. And it had to be used in a multi-tenant model, various geographically distributed business units using it independently.
  • There was no room for late or low quality delivery. Not without reason (see above) a previous attempt to build the same system went wrong and the client had already lost patience.

Despite of this, the project was a great success. It has been developed on budget and now runs smoothly 24×7.

And probably the most interesting: it has been developed by a single developer. Working half-time.

I could write about the details of the process used, but processes should be implemented for a reason. And there is two fundamental rationales less frequently mentioned.

  • Manage your client’s expectations. Or, in other words: client confidence through contractor accountability. We repeatedly delivered what we promised thanks to an incremental development approach based on the agile principles. And we were very, very careful with requirements and change management. Be prepared: you will someday have to gently prove to the client that he is the responsible for some problems or delays.
  • Manage your software architecture. We were really intransigent about architecture coherence and code quality. This is a sine qua non condition for the development to continue at a constant pace. The system was too big to live with a technical debt. One key there is probably: maintain the design clean enough to allow for constant refactoring.

Note that I have not mentioned any technology here. Actually, the technology used, as long as it is a good fit for the system under development, is irrelevant. JavaScript, Java, Scala, C#, LAMP… whatever.

Of course, there would be a lot more to say. Do not hesitate to leave questions or comments