On the darp6, a normal boot (from pushing the power button to seeing the decryption prompt) takes ~8 seconds. The first time booting after flashing firmware, it's normal to see the boot take ~28 seconds instead, where the extra delay happens before the System76 logo/splash screen appears.
On the current stable firmware, I'm able to make the boot take ~28 seconds again by performing the following testing procedure (there may be a faster way to make this occur, but this is a reliable method I know of right now):
- Plug in an NVMe enclosure to the back-left USB port, boot while holding down Esc, enter the One Time Boot menu to confirm the NVMe enclosure is showing up, then push the power button to turn the machine off (without finishing the boot.)
- Move the NVMe drive to the front-left USB port, repeat.
- Move the NVMe drive to the right USB port, repeat.
- Test the three ports a second time in the same order.
- Repeat the above process with a System76 flash drive, then with a generic flash drive.
- Boot to the decryption screen, then power off the machine (before decrypting.) Repeat this step until a long boot occurs (should happen on the second or third boot.)
On current stable, the long boot only happens once, then subsequent boots go back down to the normal time. On the master branch of firmware-open, once the long boot occurs, subsequent boots also take the longer amount of time, making this a more noticeable issue. I've tried reseating/changing out the RAM and SSD, resetting the CMOS, and clearing entries from NVRAM using efibootmgr, and I haven't found a way to stop the long boot time once this occurs short of re-flashing the firmware.
On the darp6, a normal boot (from pushing the power button to seeing the decryption prompt) takes ~8 seconds. The first time booting after flashing firmware, it's normal to see the boot take ~28 seconds instead, where the extra delay happens before the System76 logo/splash screen appears.
On the current stable firmware, I'm able to make the boot take ~28 seconds again by performing the following testing procedure (there may be a faster way to make this occur, but this is a reliable method I know of right now):
On current stable, the long boot only happens once, then subsequent boots go back down to the normal time. On the master branch of firmware-open, once the long boot occurs, subsequent boots also take the longer amount of time, making this a more noticeable issue. I've tried reseating/changing out the RAM and SSD, resetting the CMOS, and clearing entries from NVRAM using
efibootmgr, and I haven't found a way to stop the long boot time once this occurs short of re-flashing the firmware.