When we're doing vuln hunting on internet appliances, we often want a shell in order to figure out what's going on. For the F5 research we were lucky, you could just SSH into the box and immediately get access to relevant config files and binaries. Lots of other appliances don't like to give out that access, they might give some kind of restricted/custom shell, or maybe they just don't expose anything at all.
In order to get around this, we'll often grab VM images and then boot from a live cd / alternate linux install and mount the disks. More recent Sonicwall appliances prevent this behavior, however. Their disk partitions are all LUKS encrypted, which prevents nosey researchers like myself from being able to mount them via another OS that doesn't have the encryption keys.
What's interesting though, is that if you boot from the base image (as intended), it just works. GRUB does have a mechanism for embedding decryption keys into the boot process, but this often means just leaving the decryption key in the boot partition, which is pretty easy to grab. This is not what Sonicwall NSV appliances do.
The TL;DR is that Sonicwall modified their GRUB bootloader to perform decryption key derivation based off of the partition metadata. This is very much NOT default GRUB behavior (as far as I'm aware), so someone at Sonicwall went out of their way to bake this into the bootloader. It was a fun RE experience though, definitely got to learn a lot!