# Unlocking a DS1812+ that will not boot a modern Linux > Publication copy: network addresses, MACs, serials, UUIDs and host identities > are anonymized examples. Historical validation refers to the original lab > artifacts; configure and validate your own hardware before use. A 2012 Synology DS1812+ will not start a normal Linux installer. The firmware only boots a USB stick with vendor and product ID `F400:F400`, and the bootloader on that stick is a GRUB so old that the usual “chainload this program” menu does not actually run the program. Getting from that box to Debian 13 and OpenMediaVault 8 took a chain of small, wrong theories. Each one was tested, and most of them were not the reason the machine came back to the factory kernel. This is the record of what the hardware actually does, and of the path that got a current Debian userspace onto the existing data volume without rewriting that volume or the RAID. ## The box Eight 3 TB disks, an Atom D2700, two Intel 82574L network ports, and a dead onboard NIC. The disks already held a Debian system on a RAID6 logical volume. The job was to boot that system with a kernel new enough to run systemd, then move it to Debian 13 and OpenMediaVault 8. OpenMediaVault 7’s support had already ended. Staying on Debian 12 was not the goal. Linux 6.1 was allowed only as a way to get a shell. The case stays closed. The only boot medium is the rear USB port beside the first network socket. ## A week of boots that never ran the new program The menu said `chainloader` of a GRUB2 image, then a factory `kernel` line with a unique token. Every cold boot came back as Linux 3.10 with that token. It looked like GRUB2 was starting and then giving up. It was not. On this GRUB 0.97, `chainloader` loads an EFI image and returns. It does not start it. The following `kernel` line replaces that loaded image, and the implicit boot at the end of the menu starts the factory kernel. The token only proved which factory command line ran. The fix is one word. `boot` has to sit immediately after `chainloader`, before any `kernel` line. Once that is true, the child program runs, and when it returns the factory loader does not continue. It loops. There is no fall-through to the rescue entry, and `fallback` does not provide one. A one-shot helper therefore rewrites the menu back to the factory entries before it starts the experiment. If the experiment never comes up, the next power button press is the factory kernel. kexec looked like a way to jump from that factory kernel into a new one. The NIC enable does not survive the jump. kexec is a dead end here. ## The network was a separate bug The cable is in the first 82574L, PCI `0000:01:00.0`. The onboard 82567 is dead and will steal DHCP if something offers it a lease. With the disks unplugged, the machine answers at `192.0.2.32` on the NIC’s own MAC, not on the sticker address. The first 6.1 ramdisk did bring the link up and did get a lease, and then nothing on port 80 answered. BusyBox `udhcpc` was running a script path that does not exist. The script that sets the address lives in `/usr/share/udhcpc/default.script`, and `udhcpc` has to be told that with `-s`. Telnet had the same shape of bug: the daemon was running, and the shell had no terminal until devpts was mounted. ## Six disks, then eight The Intel disk controller on this board has six ports. The data array is eight disks. The other two bays sit on a pair of Silicon Image 3132 chips. Until `sata_sil24` is loaded they do not exist, and `mdadm` will refuse to start a dirty RAID6 that is two members short. Forcing that start is how a RAID6 loses data. The activity lights stay off the whole time. They are driven by the Synology board controller, which this kernel does not load. Dark lights do not mean the disks are unpowered. The disk list does. With all eight visible, the array starts. It then begins a resync that reports 0 KB/s and a finish time measured in years. That resync has to be frozen before anything mounts the volume. ## The filesystem a modern kernel will not mount The Debian volume is ext4. The superblock is valid. Linux 6.1, and every mainline kernel since 4.7, still refuses to mount it: the volume reserves 7492 group-descriptor blocks, and the kernel’s sanity check allows only 1024 on a 4 KiB filesystem. That check was added to stop a corrupt superblock from overflowing a bitmap. On this volume the number is large because the filesystem is large and old, not because it is corrupt. The 3.10 kernel mounts it. The 3.10 kernel cannot be the system that runs OpenMediaVault 8. The volume was not rewritten. The ext4 driver in the ramdisk has that one comparison skipped. The bitmap path still has its own guard. A read-only mount then showed Debian 12.15 and a systemd `/sbin/init`. ## The upgrade, and the clock The release upgrade has to run on the volume, in a chroot, while the diagnostic kernel is still PID 1. The first attempt did not upgrade anything. The chassis clock was January 2001, so APT rejected every repository as not yet valid. A cleanup script from the upgrade then removed OpenMediaVault 7, because the new packages had never arrived. Set the clock, point APT at Debian 13 and the OpenMediaVault 8 repository, and run the upgrade noninteractively. This Atom has no SSE4.2, and Debian’s `sse4.2-support` package aborts unless `IGNORE_ISA=1` is set. After that, the volume is Debian 13.7 and OpenMediaVault 8.5.9, hostname still `storage`, and the installed kernel package is 6.12.107. That 6.12 kernel is 12 MB. The EFI partition is 16 MB and already holds the factory loader. The kernel and the ramdisk therefore live on the second FAT partition, under the filenames GRUB2 already uses, and the selector hands GRUB2 that partition as its disk. ## What is still one power cycle away systemd has not yet been PID 1. The 6.12 kernel has not yet cold-booted on this chassis. The stick is prepared so the next power-on assembles the eight-disk array, freezes the resync, mounts the volume with the patched ext4 driver, and switches into Debian 13. If that boot stays dark, the one-shot menu returns to the factory kernel on the power-on after that. The ramdisk, the selector, and the init script are in `release/ds1812-unlock/`. The short procedure is `docs/ds1812-unlock-guide.md`.