Add support for Iomega Storcenter ix4-200d

For Developers
62

or to one of these if you cant use submit it to github:

63

Can you share again the images? thanks.

64

ping

status on this?

65

I'm happy to see this thread still somewhat alive. I've recently acquired an ix4-200d. I've never used a solder gun, and the first step is attaching a header to CN4 so I can get serial console. Any tips from anyone will be appreciated.

I found one tutorial, so I’ll unbox my fresh soldering kit and give it a go tomorrow.

how to, how not to

image0
image0288×640 71.5 KB

66

use the install instruction from the wiki.

a current uboot is in the works at the doozan forums, but the original will work, too.

67

Thanks. I installed header on CN4 today, and power supply comes comes on Friday.

uart pin assignments on CN4

68

My original u-boot could only deal with MBR partitioning, and vfat or ext2 file systems.

I got the 2026.04 u-boot from doozan and finally got it flashed to my device, and using debian image for my ssd.

I'm debugging some issues in boot loader, and discovering how to create ubifs, then I will put openwrt into the NAND flash.

69

i mod all my NAS with an uart to usb-c outlet to have easier access. that is very handy from time to time when you NOT have to disassemble the whole units to get to the uart :wink:

70

Hi, the images are available here

openwrt kirkwood snapshots

71

Here's the trick, since your bootloader can still only parse MBR, but you want a real GPT layout for the Debian rootfs/data (GPT is what you need past 2TiB, and it's also just more robust):

  1. Boot partition stays MBR-visible. Keep partition 1 small (ext2, a few 100's MiB is plenty) so u-boot can find and read the kernel/initrd from it the way it always has. This is the one partition your bootloader actually touches, everything else on the disk is invisible to it and doesn't need to be MBR-compatible at all.

  2. Use sgdisk/gdisk to lay down (or recover) the GPT. Since sgdisk can read an existing MBR and convert it into GPT without destroying the partitions already there, you can point it at the disk, let it pick up the current MBR layout, and write that out as a proper GPT table. That's what preserves your boot + rootfs partitions while giving you a real GPT structure for the rest of the disk.

  3. Add the data partition under GPT. Once the disk has a valid GPT, just run gdisk/sgdisk again to carve out the remaining space as a new partition (n in gdisk, or sgdisk -n from the command line). Debian will see it as a normal GPT partition; your u-boot never needs to know it exists, since it only ever looks at partition 1.

The important gotcha (learned the hard way): if you ever re-flash or re-image the disk and the GPT gets damaged, gdisk will ask whether to trust the MBR or the (corrupt) GPT, pick MBR only if you're starting fresh; pick GPT if you're recovering an existing install and want to keep your data partition intact. Picking wrong will nuke the data partition.

I actually documented this exact flow (MBR boot partition → gdisk/sgdisk conversion → GPT data partition) when I did this on a WD MyBookLive with a similarly MBR-only u-boot — worth a look since it's the same pattern:

Once you're happy with the Debian side, the NAND/UBIFS step for OpenWRT is a separate concern, that partition lives in flash, not on the SSD's GPT/MBR at all, so it won't interfere with what you set up here.