Comment 9 for bug 775281

https://certification.canonical.com/hardware/201009-6529/submission/l3QUR5NHfYRxeDE

According to a dmidecode run on that system back in December:

https://certification.canonical.com/attachment/A9UFZArJUiCqzyi

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
 Vendor: Dell Inc.
 Version: W06
 Release Date: 10/06/2010
 Address: 0xF0000
 Runtime Size: 64 kB
 ROM Size: 2112 kB
 Characteristics:
  ISA is supported
  PCI is supported
  PC Card (PCMCIA) is supported
  PNP is supported
  BIOS is upgradeable
  BIOS shadowing is allowed
  Boot from CD is supported
  Selectable boot is supported
  3.5"/720 KB floppy services are supported (int 13h)
  Print screen service is supported (int 5h)
  8042 keyboard services are supported (int 9h)
  Serial services are supported (int 14h)
  Printer services are supported (int 17h)
  CGA/mono video services are supported (int 10h)
  ACPI is supported
  USB legacy is supported
  AGP is supported
  Smart battery is supported
  BIOS boot specification is supported
  Function key-initiated network boot is supported
  Targeted content distribution is supported
 BIOS Revision: 0.6
 Firmware Revision: 0.6

So looks like W06? Is that down-rev from where it should be? Either way, it's running the BIOS that was on it when it came through enablement. Does this imply that a system in enablement that has an issue that's resolved by a BIOS update from the vendor may not actually have that update installed and verified as fixing the issue before it's pushed out of enablement and into certification?

Just trying to get a grasp on the process and whether this is something we need to be more concerned with regarding enablement systems that are being certified.