Debian on Synology RS816 (Armada 385)

Richard,

> I think this is the correct fork
> HERE
>

That does not look like the u-boot you were running with kwboot.

Quote

> U-Boot 2013.01 (May 18 2017 - 16:37:44) Marvell
> version: 2015_T1.QA.0p16

The version above is from the same tree as the Thecus N2350 and NSA326 stock u-boot.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@bodhi
> U-Boot 2013.01 (May 18 2017 - 16:37:44) Marvell
> version: 2015_T1.QA.0p16

Good catch

I later found another u-boot which apparently was lifted from Lynksys GPL (I haven't verified this) it was labelled as uboot-wrt3200acm_wrt32x.bin and ran to the same result. Now that you have highlighted the discrepancy I have rerun it and note that this one also has the same u-boot version as you noted above. It is odd that the name of this one suggests wrt3200acm and wrt32x are the same hardware. I have now run the standalone WRT3200ACM_uboot_1.0.0.bin (linked from OpenWrt site) which does not boot. Next I will build from the repo I linked and see what happens. It does seem though that the successful ones are from a separate effort to the one I found.

I haven't, yet, been able to find another source but I have been snowed under with work so haven't spent that much time looking . I am tied up today as well but Sunday I should, hopefully, be able to bottom this one out.

EDIT
Built from the WRT3200ACM u-boot src I linked above, end result on 3 kwboot runs was it crapped out at 26%. 3 tries download-serial.sh failed to get a nack I will retry tomorrow when I have more time.



Edited 1 time(s). Last edit at 06/14/2019 07:29PM by richjn.

Richard,

Don't need to find it. Let me see if I can upload my Marvell xxx 38x u-boot GPL tarball that I got from the manufacturer for you to try to compile later. I'm also swamped right now with works so cannot spend much time to do this.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Richard,

It is too big (1.4GB). And I have a very slow Internet connection :)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@bodhi

I have downloaded two tarballs from Lynksys published gpl specifically for the WRT32X

1) WRT32X_gpl_v1.0.180130.36-HK.tar.gz
2) WRT32X_v1.0.180404.58.tar.gz

Both contain two u-boot tarballs

1) u-boot-2014.10.tar.bz2
2) u-boot-2015.10.tar.bz2

There are a number of patches relating to u-boot which are held outside of the u-boot tarballs, I have not spent much time with it yet but first impression is that you are meant build the entire router firmware from the root directory. I will need to split out the bits relevant to us then build u-boots / test and I suspect modify from there. The fact this one gets as far as it does I'm hoping will lead to not many changes required to get a Marvel>> prompt from which we already know we can recover.

Richard,

> There are a number of patches relating to u-boot
> which are held outside of the u-boot tarballs, I
> have not spent much time with it yet but first
> impression is that you are meant build the entire
> router firmware from the root directory. I

Usually their top level script also sets up the build environment. So you might need to run their script to make everything available.

But when you actually build, only u-boot is needed to be compiled in the subtree, so not too bad.

> to get a Marvel>> prompt from which we already
> know we can recover.

Home free when you see the prompt!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@bodhi

The top level script uses git to download updates to all of the components for the firmware build and then checks to see if you have the appropriate development files installed, missing items are ignored till the end of the checks before exiting as I don't have them installed. Because I'm building on an in-production server I don't want to install all of the requirements (there are lots) even though I know I could uninstall them afterwards.

Instead I will try to track down the bits I need to build their customized u-boot and go from there.

Richard,

> The top level script uses git to download updates
> to all of the components for the firmware build
> and then checks to see if you have the appropriate
> development files installed, missing items are
> ignored till the end of the checks before exiting
> as I don't have them installed. Because I'm
> building on an in-production server I don't want
> to install all of the requirements (there are
> lots) even though I know I could uninstall them
> afterwards.

That's why this should be done inside a VM to avoid polluting your real box. In a VM, you'd just run their script and be done with the build environment.

> Instead I will try to track down the bits I need
> to build their customized u-boot and go from
> there.

This will take longer to do.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 06/15/2019 10:15PM by bodhi.

@bodhi
I suspect I am in the minority but I prefer not to cross compile if I can avoid it. I did setup a native armhf qemu a while back but it was dog slow :(

Richard,

> I suspect I am in the minority but I prefer not to
> cross compile if I can avoid it.

Nope. You are not in the minority. I always compile natively using a plug farm and distcc. The only kernel I cross compile is this MVEBU kernel (so to be able to compile both Kirkwood and MVEBU kernels at the same time).

> I did setup a
> native armhf qemu a while back but it was dog slow
> :(

IMO, that's not the right way to do it.

In a Linux VM (Ubuntu, for example), you would install Linaro toochain (been too long I need to dig out the notes to see the simple 1 or 2 apt-get commands to do this), and be done with the build environment.

And then set you envs to point to the compiler.

ARCH=arm
CROSS_COMPILE=arm-linux-gnueabihf-

That's it to cross compile the kernel.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 06/16/2019 02:44AM by bodhi.

@bodhi

I think your advise is sound as usual and if I were running a mainline Linux OS where a couple of apt-get's would see me up and running I would probably go that route but compiling / installing everything required to run a Ubuntu KVM is to add more packages to my own system than I want to and generally would mess with my zen. I did compile a bare minimum Qemu for the armhf VM but when that proved unsatisfactory I blew it all away.

I will come back to this but for now with my day job increasingly getting in the way (I know you are very busy too) I think I need to park this until I get back from my extended leave (1st July - 12th August) at which point I might press a spare box into service to act as a build slave for all of this.

Richard,

> I think your advise is sound as usual and if I
> were running a mainline Linux OS where a couple of
> apt-get's would see me up and running I would
> probably go that route but compiling / installing
> everything required to run a Ubuntu KVM is to add
> more packages to my own system than I want to and
> generally would mess with my zen.

I see.

> I did compile a
> bare minimum Qemu for the armhf VM but when that
> proved unsatisfactory I blew it all away.
>
> I will come back to this but for now with my day
> job increasingly getting in the way (I know you
> are very busy too) I think I need to park this
> until I get back from my extended leave (1st July
> - 12th August) at which point I might press a
> spare box into service to act as a build slave for
> all of this.

Sounds like a good plan!

One possible way to avoid polluting your system is to use Linux Mint image on USB to boot you x86 laptop/desktop. And do everything on that USB to see if you can install and compile. The kernel is too big a job to compile on USB, but compiling u-boot is quite feasible even using USB rootfs.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Richard,

Debian Buster release is slated for July 6th:

https://www.phoronix.com/scan.php?page=news_item&px=Debian-10.0-Buster-Release-Date

Shall we meet again to work on the RS816 instruction about mid August? July 6th is very close to my bi-annual sabatical.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@bodhi
> Debian Buster release is slated for July 6th:

I'm away from 1st July to 15th August so any time after that would be good for me.

I was just about to pack away the bricked rs816 and decided to have one last try before I did and to my utter disbelief it booted to Marvel>> using the rs816.stock.uboot.kwb we had taken from the other rs816 conversion. If you recall this had worked once before for me but literally hundreds of attempts since then had failed.

Because I wasn't sure if I had upset the flash areas with my "dud" attempt to update u-boot I opted to re-flash the backups we had taken previously so I booted from Marvel with

setenv mtdparts 'mtdparts=mtdparts=spi0.0:4m(boot),-(spi-rootfs)'

And the usual usb rootfs env

setenv ipaddr 192.168.1.250
setenv serverip 192.168.1.1
setenv usb_setup 'setenv usbActive 1; setenv usbType 3; usb start;'                
setenv load_dtb_addr 0x1000000
setenv load_initrd_addr 0x3000000
setenv load_image_addr 0x02000000
setenv load_image 'echo loading zImage from tftpserver ...; tftpboot $load_image_addr zImage'
setenv load_initrd 'echo loading uInitrd from tftpserver ...; tftpboot $load_initrd_addr uInitrd'
setenv load_dtb 'echo loading DTB from tftpserver ...; tftpboot $load_dtb_addr armada-385-synology-rs816-rj.dtb'
setenv set_bootargs 'setenv bootargs "console=ttyS0,115200 root=LABEL=rootfs rootdelay=20 $mtdparts earlyprintk=serial"'
setenv bootcmd_exec 'echo Booting Debian . . .; run usb_setup;  run set_bootargs; setenv fdt_skip_update yes; setenv initrd_high 0xffffffff; run load_image; run load_initrd; run load_dtb; bootz $load_image_addr $load_initrd_addr $load_dtb_addr'
setenv bootcmd 'run bootcmd_exec; run bootspi'
boot

Once booted in I restored /dev/mtd0 and mtd1 from the backups

flashcp -v mtd0.stock.rs816 /dev/mtd0
flashcp -v mtd1.stock.rs816 /dev/mtd1

Rebooted with the same as above a did a saveenv which in hindsight I can't actually think why I thought that was a good idea.

Reboot again and interupt

run bootspi

And synology dsm is back up and running :-)

The only bit I need to work out now is how to restore the original envs so it will autoboot synology (any tips gratefully received)

Best bit is we can now use this box to do the trial rather than take down the original converted box which is working well in production.

EDIT
A few awful typos... too many shiraz = fat fingers



Edited 1 time(s). Last edit at 06/20/2019 06:41AM by richjn.

Good works Richard :)

Many shiraz = win !!! :))

Will be back tomorrow to look at restoring stock envs.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@bodhi
>Will be back tomorrow to look at restoring stock envs.

Thanks I will wait till you are back then rather than risk messing it up.

Info you probably need

From Marvel>>
printenv

Marvell>> printenv
CASset=max
MALLOC_len=5
MPmode=SMP
ata_hdd_detect=syno_hdd_detect=39,39,39,39
ata_hdd_enable=syno_hdd_enable=37,37,37,37
autoload=no
baudrate=115200
boot_order=hd_scr usb_scr mmc_scr hd_img usb_img mmc_img pxe net_img net_scr
bootargs=
bootargs_dflt=$console $nandEcc $mtdparts_lgcy $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel
bootargs_end=:10.4.50.254:255.255.255.0:Armada38x:eth0:none
bootargs_root=root=/dev/nfs rw
bootcmd=run bootcmd_exec; run bootspi
bootcmd_auto=stage_boot $boot_order
bootcmd_exec=echo Booting Debian . . .; run usb_setup;  run set_bootargs; setenv fdt_skip_update yes; setenv initrd_high 0xffffffff; run load_image; run load_initrd; run load_dtb; bootz $load_image_addr $load_initrd_addr $load_dtb_addr
bootcmd_fdt=tftpboot 0x2000000 $image_name;tftpboot $fdtaddr $fdtfile;setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_fdt_boot=tftpboot 0x2000000 $image_name; setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_fdt_edit=tftpboot $fdtaddr $fdtfile; fdt addr $fdtaddr; setenv bootcmd $bootcmd_fdt_boot
bootcmd_lgcy=tftpboot 0x2000000 $image_name;setenv bootargs $console $nandEcc $mtdparts_lgcy $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end  video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel;  bootm $loadaddr;
bootdelay=3
bootftp=run syno_bootargs;tftpboot $loadaddr_kernel $file_kernel;tftpboot $loadaddr_rootfs $file_rootfs;sf probe; sf read $loadaddr_dt $spi_pt_addr_dt $spi_pt_size_dt;fdt addr $loadaddr_dt;bootm $loadaddr_kernel $loadaddr_rootfs $loadaddr_dt;
bootspi=run syno_bootargs;sf probe 0 50000000;sf read $loadaddr_kernel $spi_pt_addr_kernel $spi_pt_size_kernel;sf read $loadaddr_rootfs $spi_pt_addr_rootfs $spi_pt_size_rootfs;sf read $loadaddr_dt $spi_pt_addr_dt $spi_pt_size_dt;bootm $loadaddr_kernel $loadaddr_rootfs $loadaddr_dt;
cacheShare=no
clean_env=sf probe; sf erase $spi_pt_addr_env $spi_pt_size_env;
console=console=ttyS0,115200
device_partition=0:1
disaMvPnp=no
eeeEnable=no
enaClockGating=no
enaCpuStream=no
enaFPU=yes
enaMonExt=no
enaWrAllo=no
eth1addr=00:50:43:1c:24:27
eth1mtu=1500
eth2addr=00:50:43:1c:1c:27
eth2mtu=1500
eth3addr=00:50:43:24:1c:1c
eth3mtu=1500
ethact=egiga0
ethaddr=00:50:43:1c:24:27
ethmtu=1500
ethprime=egiga0
fdt_addr=2040000
fdt_skip_update=yes
fdtaddr=0x1000000
fdtfile=armada-38x.dtb
file_flash=armada38x/flash.bin
file_kernel=armada38x/uImage
file_rootfs=armada38x/rd.bin
file_uboot=armada38x/uboot.bin
ide_path=/
image_name=uImage
initrd_high=8000000
initrd_name=uInitrd
ipaddr=192.168.1.250
kernel_addr_r=2080000
lcd0_enable=0
lcd0_params=640x480-16@60
lcd_panel=0
limit_dram_size=yes
load_dtb=echo loading DTB from tftpserver ...; tftpboot $load_dtb_addr armada-385-synology-rs816-rj.dtb
load_dtb_addr=0x1000000
load_image=echo loading zImage from tftpserver ...; tftpboot $load_image_addr zImage
load_image_addr=0x02000000
load_initrd=echo loading uInitrd from tftpserver ...; tftpboot $load_initrd_addr uInitrd
load_initrd_addr=0x3000000
loadaddr=0x02000000
loadaddr_dt=0x1000000
loadaddr_kernel=0x2000000
loadaddr_rootfs=0x3000000
loads_echo=0
mtdids=spi0=spi_flash
mtdparts=mtdparts=mtdparts=spi0.0:4m(boot),-(spi-rootfs)
mtdparts_lgcy=mtdparts=spi_flash:4m(boot),-(spi-rootfs)
mvNetConfig=mv_net_config=4,(00:50:43:11:11:11,0:1:2:3),mtu=1500
mv_pon_addr=00:50:43:27:1c:1c
netbsd_en=no
netretry=no
pcieTune=no
pexMode=RC
pxe_files_load=:default.arm-armadaxp-db:default.arm-armadaxp:default.arm
pxefile_addr_r=3100000
ramdisk_addr_r=2880000
rootpath=/srv/nfs/
run_script=no
sata_delay_reset=0
sata_dma_mode=yes
script_addr_r=3000000
script_name=boot.scr
sd_detection_dat3=no
serverip=192.168.1.1
set_bootargs=setenv bootargs "console=ttyS0,115200 root=LABEL=rootfs rootdelay=20 $mtdparts earlyprintk=serial"
spi_pt_addr_dt=0x0E0000
spi_pt_addr_env=0x7e0000
spi_pt_addr_kernel=0x0F0000
spi_pt_addr_rootfs=0x3C0000
spi_pt_size_dt=0x010000
spi_pt_size_env=0x010000
spi_pt_size_kernel=0x2D0000
spi_pt_size_rootfs=0x410000
standalone=fsload 0x2000000 $image_name;setenv bootargs $console $nandEcc $mtdparts_lgcy root=/dev/mtdblock0 rw ip=$ipaddr:$serverip$bootargs_end; bootm 0x2000000;
stderr=serial
stdin=serial
stdout=serial
syno_boot_dev=/dev/md0
syno_bootargs=setenv bootargs console=ttyS0,115200 ip=off initrd=$loadaddr_rootfs root=$syno_boot_dev rw $syno_extra_args syno_hw_version=$syno_hw_version hd_power_on_seq=$syno_hdd_powerup_seq ihd_num=$syno_hdd_powerup_seq netif_num=$syno_net_if_num $ata_hdd_detect $ata_hdd_enable flash_size=8
syno_extra_args=HddHotplug=4 sata_remap=0>4:4>0
syno_hdd_powerup_seq=4
syno_hw_version=RS816
syno_net_if_num=2
upd_flash=setenv tftpfile $file_flash; tftpboot $loadaddr $tftpfile; if test $? -eq 0; then echo "This may take a while, please be patient..."; sf probe; sf erase 0 +$filesize; sf write $loadaddr 0 $filesize; echo "\
Flash Update Done"; fi;
upd_kernel=setenv tftpfile $file_kernel; mw.b $loadaddr 0xFF $spi_pt_size_kernel; tftpboot $loadaddr $tftpfile; if test $? -eq 0; then sf probe; sf erase $spi_pt_addr_kernel $spi_pt_size_kernel; sf write $loadaddr $spi_pt_addr_kernel $spi_pt_size_kernel; echo "\
Kernel Update Done"; fi;
upd_rootfs=setenv tftpfile $file_rootfs; mw.b $loadaddr 0xFF $spi_pt_size_rootfs; tftpboot $loadaddr $tftpfile; if test $? -eq 0; then sf probe; sf erase $spi_pt_addr_rootfs +$filesize; sf write $loadaddr $spi_pt_addr_rootfs $filesize; echo "\
Rootfs Update Done"; fi;
upd_uboot=setenv tftpfile $file_uboot; tftpboot $loadaddr $tftpfile; if test $? -eq 0; then sf probe; sf erase 0 +$filesize; sf write $loadaddr 0 $filesize; echo "\
Uboot Update Done"; fi;
usb0Mode=host
usbActive=0
usbType=2
usb_setup=setenv usbActive 1; setenv usbType 3; usb start;
vxworks_en=no
yuk_ethaddr=00:00:00:EE:51:81

Environment size: 6534/65532 bytes

From Debian rootfs
fw_printenv

root@debian:~# fw_printenv
Warning: Bad CRC, using default environment
bootcmd=run distro_bootcmd
bootdelay=2
baudrate=115200
stdin=serial,cros-ec-keyb,usbkbd
stdout=serial,vidconsole
stderr=serial,vidconsole
ethaddr=00:00:11:22:33:44
eth1addr=00:00:11:22:33:45
eth3addr=00:00:11:22:33:46
eth5addr=00:00:11:22:33:47
ipaddr=1.2.3.4
host_boot=if host dev ${devnum}; then setenv devtype host; run scan_dev_for_boot_part; fi
sata_boot=if sata dev ${devnum}; then setenv devtype sata; run scan_dev_for_boot_part; fi
scsi_init=if ${scsi_need_init}; then setenv scsi_need_init false; scsi scan; fi
scsi_boot=run scsi_init; if scsi dev ${devnum}; then setenv devtype scsi; run scan_dev_for_boot_part; fi
virtio_boot=if virtio dev ${devnum}; then setenv devtype virtio; run scan_dev_for_boot_part; fi
boot_prefixes=/ /boot/
boot_scripts=boot.scr.uimg boot.scr
boot_script_dhcp=boot.scr.uimg
boot_targets=host1 host0
boot_syslinux_conf=extlinux/extlinux.conf
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}${boot_syslinux_conf}
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${boot_syslinux_conf}; then echo Found ${prefix}${boot_syslinux_conf}; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done
bootcmd_host1=setenv devnum 1; run host_boot
bootcmd_host0=setenv devnum 0; run host_boot
distro_bootcmd=setenv scsi_need_init; for target in ${boot_targets}; do run bootcmd_${target}; done
bootm_size=0x10000000
kernel_addr_r=0x1000000
fdt_addr_r=0xc00000
ramdisk_addr_r=0x2000000
scriptaddr=0x1000
pxefile_addr_r=0x2000

cat /proc/mtd

root@debian:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 000f0000 00001000 "RedBoot"
mtd1: 002d0000 00001000 "zImage"
mtd2: 00410000 00001000 "rd.gz"
mtd3: 00010000 00001000 "vendor"
mtd4: 00010000 00001000 "RedBoot config"
mtd5: 00010000 00001000 "FIS directory"

cat /etc/fw_config.env (these were added to this rootfs as part of our first conversion)

root@debian:~# cat /etc/fw_env.config
# MTD device name       Device offset   Env. size       Flash sector size       Number of sectors
/dev/mtd1               0x3E0000        0x10000      0x00001000

Richard,

Quote

The only bit I need to work out now is how to restore the original envs so it will autoboot synology (any tips gratefully received)

To boot directly to stock Synology and ignore the Debian rootfs on USB or HDD. If that's what you want?

Power up, interrupt serial console and

setenv bootcmd 'mw 0xf10a2620 0x251;mw 0xf10a2e20 0x251;usb xhciinit; run bootspi'
boot

After it works, reboot and interrupt serial console and,

setenv bootcmd 'mw 0xf10a2620 0x251;mw 0xf10a2e20 0x251;usb xhciinit; run bootspi'
saveenv

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@bodhi

Thanks for the env's

I'm out at the moment but will post once I get back and apply them.

Yes, I was looking to get it back to stock so we can do the tutorial on it. Once the tutorial is done I will probably re-configure it to be the same as my other rs816 i.e zImage on flash.

@bodhi

Env's worked fine and the box is now effectively "stock"

I have 4 x 2TB drives with the latest DSM-6.2.2 installed all ready for mid August when we both get back from our respective holidays. I am completely at your disposal for how you want to configure things but as a rack server I suspect most users would want to setup raid.

Was also wondering what level of user experience you wanted to pitch at i.e. start to finish copy & paste or making an assumption that anyone following the guide probably has a reasonable skill level to attempt to do so, just thinking about blowing away Synology raids and creating new ones etc and making sure we have all the tools required in your upcoming Buster rootfs.

Richard,

> Env's worked fine and the box is now effectively
> "stock"

Cool!

> I have 4 x 2TB drives with the latest DSM-6.2.2
> installed all ready for mid August when we both
> get back from our respective holidays. I am
> completely at your disposal for how you want to
> configure things but as a rack server I suspect
> most users would want to setup raid.
>
> Was also wondering what level of user experience
> you wanted to pitch at i.e. start to finish copy &
> paste or making an assumption that anyone
> following the guide probably has a reasonable
> skill level to attempt to do so, just thinking
> about blowing away Synology raids and creating new
> ones etc and making sure we have all the tools
> required in your upcoming Buster rootfs.

Basically the installation has 3 parts.

I. Install kernel in HDD raw sector on an HDD Debian rootfs. uImage and uInitrd.
II. Install kernel in flash and Debian rootfs on USB (HDD rootfs is basically the same instruction). zImage only.
III. Install kernel in flash and Debian rootfs on RAID. zImage only

Both types of installation starting point is inside stock OS.

So to prepare, we'd want to check the following tools in stock (mtd-utils, u-boot-tools).

fw_setenv
fw_printenv
flash_unlock
flashcp

I'm rebuilding new kernel versions (both Kirkwood and MVEBU) to pick up security patch for TCPSACK PANIC, and also enable RAID LVM in kernel.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@bodhi

>> Basically the installation has 3 parts.
Sounds good :)

>> So to prepare, we'd want to check the following tools in stock (mtd-utils, u-boot-tools).
None of those are in stock if by stock you meant Synology DSM ? u-boot-tools was in your previous rootfs but not mtd-utils.

The other thing I was thinking about in my last post was a decent partitioning tool for gpt disks, I prefer parted but I know its a matter of preference thing so maybe gdisk instead or both, if there is already a tool in the rootfs you prefer but I am not aware of I'm obviously happy to use it.

EDIT
Maybe scrap my last comment, I have been using parted for so long I had no idea fdisk could now handle gpt partitions (just did a man fdisk). I will probably always use parted but for the purposes of the tutorials that's irrelevant.



Edited 1 time(s). Last edit at 06/24/2019 04:09AM by richjn.

Hi Richard,

> None of those are in stock if by stock you meant
> Synology DSM ? u-boot-tools was in your previous
> rootfs but not mtd-utils.

I think it is OK. I did mean Synology DSM. But all I need to do is to make sure mtd-utils is installed in the new rootfs.

>
> The other thing I was thinking about in my last
> post was a decent partitioning tool for gpt disks,
> I prefer parted but I know its a matter of
> preference thing so maybe gdisk instead or both,
> if there is already a tool in the rootfs you
> prefer but I am not aware of I'm obviously happy
> to use it.
>
> EDIT
> Maybe scrap my last comment, I have been using
> parted for so long I had no idea fdisk could now
> handle gpt partitions (just did a man fdisk). I
> will probably always use parted but for the
> purposes of the tutorials that's irrelevant.

I think we don't need to instruct users how to partition disks. I intended the rootfs instruction will simply point to the Debian rootfs release thread. That's the first thing to do, and the beginner users should learn how to do that as a separated topic. The least common denominator is used for installation: Ext3, single partition.

And we'll expand that in the 3rd part, where RAID is concerned. You will be the authority for anything related to RAID.

BTW, the recent kernels has a mode bootarg.

dm-mod.create

Quote

dm: add support to directly boot to a mapped device
Add a "create" module parameter, which allows device-mapper targets to
be configured at boot time. This enables early use of DM targets in the
boot process (as the root device or otherwise) without the need of an
initramfs.

The syntax used in the boot param is based on the concise format from
the dmsetup tool to follow the rule of least surprise:

dmsetup table --concise /dev/mapper/lroot

Which is:
dm-mod.create=<name>,<uuid>,<minor>,<flags>,<table>[,<table>+][;<name>,<uuid>,<minor>,<flags>,<table>[,<table>+]+]

Where,
<name> ::= The device name.
<uuid> ::= xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | ""
<minor> ::= The device minor number | ""
<flags> ::= "ro" | "rw"
<table> ::= <start_sector> <num_sectors> <target_type> <target_args>
<target_type> ::= "verity" | "linear" | ...

For example, the following could be added in the boot parameters:
dm-mod.create="lroot,,,rw, 0 4096 linear 98:16 0, 4096 4096 linear 98:32 0" root=/dev/dm-0

Only the targets that were tested are allowed and the ones that don't
change any block device when the device is create as read-only. For
example, mirror and cache targets are not allowed. The rationale behind
this is that if the user makes a mistake, choosing the wrong device to
be the mirror or the cache can corrupt data.

The only targets initially allowed are:
* crypt
* delay
* linear
* snapshot-origin
* striped
* verity

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@bodhi

I think we might need to get our hands a bit dirty on this particular unit when it comes to tutorial III for a raid setup simply because we need to make sure all the Synology raid super blocks are blown away and making sure /boot is sat on the correct raid meta etc. I hear what you are saying re: users should look things up themselves but it wouldn't add many steps if in the raid tutorial we actually do the disk setup steps as well.

If you would consider adding parted to the rootfs it would make life simpler for me to provide the above steps if you wish to go that route.

>>dm-mod.create

Interesting, I will take a look into it but to be honest I don't use device-mapper much apart from the odd encrypted USB. I need to have a bit of a google but I'm assuming this will only work for non-raid lvm's etc but if it somehow manages raid as well that's a whole different prospect! basically I'm not sue if the target "* striped" means raid or something else.

EDIT
Answering my own question striped is a lvm function where writes are applied to multiple disks a bit like raid0 there is no redundancy available in this function as far as I can see.



Edited 1 time(s). Last edit at 06/24/2019 08:52PM by richjn.

Richard,

Installation is easier to break down for the users when we have too many complicated steps.

> I think we might need to get our hands a bit dirty
> on this particular unit when it comes to tutorial
> III for a raid setup simply because we need to
> make sure all the Synology raid super blocks are
> blown away and making sure /boot is sat on the
> correct raid meta etc.

It will make the tutorial more complicated than necessary. We only need 1 HDD or USB to do a simple installation. And that the main goal. We'll call that section a of part III.

And then,

The b section of part III is where after the user have gone through section a, and has booted with the rootfs on a pristine USB or HDD. And then you'd instruct how to deal with the existing Synology RAID on the HDDs. So basically, either the HDDs should be removed before section a, and then plug in after section a is completed. Or we instruct the users to "wipe out the super blocks". Or we'll have to tell u-boot to ignore everything else but the rootfs if the HDDs are not removed.

So for the above to happen seamlessly, I think the USB rootfs should be used in this part III.


> If you would consider adding parted to the rootfs
> it would make life simpler for me to provide the
> above steps if you wish to go that route.

Sure, adding parted is good for general usage, too.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@bodhi

Very happy to go any route you like and certainly for a single HDD install we don't need to do any of the other stuff. I suspect though that most users will have this unit running as a 4 HDD setup with DSM and just want to convert it to native Debian.

In all cases I was assuming we would boot from rootfs on a USB and install to HDD from there. What I have been doing regardless of whether its a single HDD install or a 4 HDD raid install is to create the USB rootfs with a copy of the rootfs tarball placed in /root on it. Following USB boot I would then partition the disk mount them to /mnt and extract the tarball there. Once done I chroot into /mnt and setup anything else I need to.

The steps for dealing with old partitions and Synology raids is not complicated and requires no more than manually stopping the array (which Debian USB rootfs would have automatically started) clear the super-blocks and re-partition.

Seriously though from my perspective I am very grateful for all the help you provided me so please view the above as just my thoughts, ultimately all these decisions are your call and I'm happy to go along with whatever you wish to do.

Richard,

> In all cases I was assuming we would boot from
> rootfs on a USB and install to HDD from there.
> What I have been doing regardless of whether its a
> single HDD install or a 4 HDD raid install is to
> create the USB rootfs with a copy of the rootfs
> tarball placed in /root on it. Following USB boot
> I would then partition the disk mount them to /mnt
> and extract the tarball there. Once done I chroot
> into /mnt and setup anything else I need to.

Sounds good!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@bodhi

My last 'working' day today before I start packing for my extended leave so just wanted to sign out and say I will post on my return.

One thing I forgot to comment on in my previous email was the use of Ext3. In recent kernels Ext3 is no longer present as a standalone item with Ext3 filesystems being handled by the Ext4 kernel module simply to provide backwards compatibility. As we are extracting the rootfs tarball to the target system I know it doesn't matter what file system a user selects for the HDD's I was just curious why you wish to go Ext3 rather than Ext4 ?

Lastly I just wanted to wish you well for your own upcoming holiday :)

Richard,

> One thing I forgot to comment on in my previous
> email was the use of Ext3. In recent kernels Ext3
> is no longer present as a standalone item with
> Ext3 filesystems being handled by the Ext4 kernel
> module simply to provide backwards compatibility.

That's the intent of Linux maintainers. Only Ext2 is still avalable as a separate module. Ext4 dirver is handling both Ext3 and Ext4.

> As we are extracting the rootfs tarball to the
> target system I know it doesn't matter what file
> system a user selects for the HDD's I was just
> curious why you wish to go Ext3 rather than Ext4
> ?

As I've mentioned, Ext3 is the least common denominator. This will work with all u-boot versions. Even one that's really old that does not have Ext3, it will treat the Ext3 rootfs as Ext2 without problem.

Using Ext4 as rootfs is, of course, recommended for experienced Linux users who know for a fact that the stock u-boot in certain box supports Ext4. Or in the Kirkwood boxes that I have released modern u-boots for. And such users must also know about the issue of Ext4 lazy init (which IMO is a bad default for file system creation, this option should be opt-in). Ext4 is problem-prone for beginner users to use as rootfs. So the installation procedure needs to eliminate as many pitfalls as possible.

>
> Lastly I just wanted to wish you well for your own
> upcoming holiday :)

You too :) have a good holidays!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@bodhi

Just posting on the off chance you haven't started your own holiday yet. I will be returning to my holiday tomorrow.

I got called back for an "emergency" with our firewall (the converted RS816) which irritatingly, for my holiday, proved to be nothing more serious than a miss-configured firewall rule by someone who shouldn't have been meddling with it in the first place. To add to my displeasure the second RS816 I left on my desk has gone 'missing'

To avoid further holiday disruption I have re-installed the pre rs816 firewall and thought I'd use the rest of my day getting the remaining RS816 back to stock ready for the tutorials but I have bumped into an issue.

When booted into Debian we currently have the following.

root@server:~# cat /proc/mtd   
dev:    size   erasesize  name
mtd0: 000e0000 00001000 "u-boot"
mtd1: 00010000 00001000 "dtb"
mtd2: 006f0000 00001000 "kernel"
mtd3: 00020000 00001000 "env"

All as it should be. To return it to stock and flash the backup mtd0 and mtd1 we took I set mtdparts as

setenv mtdparts 'mtdparts=mtdparts=spi0.0:4m(boot),-(spi-rootfs)'

followed by the usual USB boot process but once booted into the usb rootfs I get

root@debian:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 000f0000 00001000 "RedBoot"
mtd1: 002d0000 00001000 "zImage"
mtd2: 00410000 00001000 "rd.gz"
mtd3: 00010000 00001000 "vendor"
mtd4: 00010000 00001000 "RedBoot config"
mtd5: 00010000 00001000 "FIS directory"

which I believe is the stock mtd layout.

Am I doing something wrong ?

Richard,

> Just posting on the off chance you haven't started
> your own holiday yet. I will be returning to my
> holiday tomorrow.

Not yet :) but even on my vacation, I still posts and answer questions every few days. Just that I cannot do much more than that (I'm away from my rig). And for urgent questions, I will answer within a day.

> followed by the usual USB boot process but once
> booted into the usb rootfs I get
>
>

> root@debian:~# cat /proc/mtd
> dev:    size   erasesize  name
> mtd0: 000f0000 00001000 "RedBoot"
> mtd1: 002d0000 00001000 "zImage"
> mtd2: 00410000 00001000 "rd.gz"
> mtd3: 00010000 00001000 "vendor"
> mtd4: 00010000 00001000 "RedBoot config"
> mtd5: 00010000 00001000 "FIS directory"
>

> which I believe is the stock mtd layout.
>
> Am I doing something wrong ?

1. Check your kernel command line to see if the mtdparts is passed in

cat /proc/cmdline

2. Whenever you see stock MTDs definition, then either the new mtdparts env was not passed in as kernel args correctly, or the DTB was embedded inside uImage.

dmesg | grep -8 MTD

What you would expect to see from the output of dmesg grep above is something like

[    2.370320] 1 cmdlinepart partitions found on MTD device .......

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 07/08/2019 01:51AM by bodhi.