Welcome! Log In Create A New Profile

Advanced

[BETA] Rescue System V4, using a custom LEDE firmware

Posted by bobafetthotmail 
[BETA] Rescue System V4, using a custom LEDE firmware
September 09, 2016 05:11PM
After some work and many Thanks Obama since LEDE devs don't cough up their secrets even after waterboarding, I present you Rescue System V4, with support for all kirkwoods (theoretically, I tested only nsa310)!

It's a custom-built LEDE/OpenWRT firmware.
it needs only 2MiB of space for the kernel and 11MiB of space for the rootfs on the NAND (will use more if available and allows writing on it).

But it is packed of goodies:

root@lede:/# ls /bin 
ash              egrep            mknod            sed
board_detect     false            mktemp           sh
busybox          fgrep            mount            sleep
cat              fsync            mv               sync
chgrp            grep             netmsg           tar
chmod            gunzip           netstat          touch
chown            gzip             nice             true
config_generate  ipcalc.sh        pidof            ubus
cp               kill             ping             uclient-fetch
date             ln               ping6            umount
dd               lock             ps               uname
df               login            pwd              vi
dmesg            ls               rm               wget
echo             mkdir            rmdir            zcat
root@lede:/# ls /sbin 
askfirst           init               mtd                sysupgrade
block              ip                 netifd             ubusd
cgdisk             jffs2mark          pivot_root         uci
devstatus          jffs2reset         poweroff           udevtrigger
firstboot          kmodloader         procd              udhcpc
gdisk              led.sh             reboot             upgraded
halt               logd               reload_config      urandom_seed
hotplug-call       logread            route              validate_data
hwclock            mdadm              sgdisk             wifi
ifconfig           mkfs.xfs           start-stop-daemon  xfs_db
ifdown             mkswap             swconfig           xfs_growfs
ifstatus           mmc                switch_root        xfs_repair
ifup               mount_root         sysctl
root@lede:/# ls /usr/bin 
[                  du                 mkfifo             tar
[[                 env                mkfs.btrfs         tee
ar                 expr               mount              test
attr               file               mountpoint         time
awk                find               nano               top
basename           findmnt            nc                 tr
bc                 flock              ncdu               traceroute
btrfs              free               nslookup           traceroute6
btrfs-debug-tree   fsck.btrfs         passwd             umount
btrfs-find-root    funzip             perl               uniq
btrfs-image        getfacl            perl5.22.1         unlzma
btrfs-map-logical  getfattr           pgrep              unxz
btrfs-show-super   getrandom          pkg-config         unzip
btrfs-zero-log     head               printf             unzipsfx
btrfsck            hexdump            readlink           uptime
btrfstune          id                 reset              usign
bunzip2            jshn               rsync              uuidgen
bzcat              jsonfilter         scp                vim
bzip2              killall            seq                wc
chacl              ldd                setfacl            wget
chattr             less               setfattr           wget-ssl
chroot             lftp               sha1sum            which
clear              logger             sha256sum          xargs
cmp                lsattr             signify            xz
crontab            lsblk              sort               xzcat
cut                lsof               spi-config         yes
dbclient           lzcat              spi-pipe           zipgrep
dc                 lzma               ssh                zipinfo
dirname            mc                 strings
dmesg              mcedit             systool
dropbearkey        md5sum             tail
root@lede:/# ls /usr/sbin 
atftp              fsck.ext4          mkfs.fat           swaplabel
atftpd             fsck.f2fs          mkfs.msdos         swapoff
badblocks          fsck.fat           mkfs.vfat          swapon
blkid              fsck.msdos         mkswap             tune2fs
brctl              fsck.vfat          modinfo            ubiattach
chroot             fw_printenv        modprobe           ubiblock
crond              fw_setenv          mtdinfo            ubicrc32
debootstrap        insmod             nanddump           ubidetach
dnsmasq            ip6tables          nandtest           ubiformat
dosfsck            ip6tables-restore  nandwrite          ubimkvol
dropbear           ip6tables-save     ntpd               ubinfo
dump.f2fs          iptables           ntpd-hotplug       ubinize
e2fsck             iptables-restore   odhcp6c            ubirename
f2fstat            iptables-save      odhcpd             ubirmvol
fatlabel           lsmod              odhcpd-update      ubirsvol
fdisk              mke2fs             resize2fs          ubiupdatevol
fibmap.f2fs        mkfs.ext2          rmmod              wipefs
findfs             mkfs.ext3          sensors            xtables-multi
fsck.ext2          mkfs.ext4          sensors-detect
fsck.ext3          mkfs.f2fs          smartctl

It supports ext2-3-4, btrfs, f2fs, FAT32, XFS (also ubifs and jffs2 and squashfs but these aren't usually used by Debian). (theoretically, not all have been tested)

It has fdisk for MBR partitioning and gdisk/sgdisk/cgdisk for GPT partitioning.

It also has mdadm and is able to read raid arrays (theoretically, not tested), and debootstrap/pkg-config so it can (theoretically, not tested) generate a debian rootfs on its own.

Since this is a rescue system, the opkg (expansion) functionality has been removed.

If you think there are crucial tools or drivers I've missed, please post and I'm updating the image. Serial connection is recommended as I might have not included the ethernet driver for your device (I should have).


I will add this to the installer script Soon(TM) so that you can automatically install a powerful recovery on your device's NAND instead of wasting it with a dead firmware the new uboot cannot use.


Installation (for testing purposes, so I'm not providing easy info, must use nand_erase then nandwrite):
-write the uimage of your device in the kernel partition on flash.
-write the rootfs image in a suitably large nand partition.
-change the name of the mtdpart where you flash the rootfs to "rootfs".
-write the envs to boot this recovery system in your uboot.

I'm providing my envs as examples (nsa310):

These are the bootargs
recovery_bootargs=setenv bootargs console=ttyS0,115200 rootdelay=10 $mtdparts_lede

These are the bootcommands
bootcmd_recovery=run recovery_bootargs; nand read 0x800000 nand0,7 ; bootm 0x800000
bootcmd=run bootcmd_uenv; run scan_disk; run set_bootargs; run bootcmd_exec; run bootcmd_recovery;
here the "nand0" is the NAND chip onboard, and "nand0,7" is like saying mtd7, or whatever hex offsets the partition sits in and none really feels like figuring out on this side.
Adjust that to fit the partition you flash the kernel image into.

This is mtdparts_lede, the last one is the rootfs (mtd8):
mtdparts_lede=mtdparts=orion_nand:0x100000(uboot),0x80000(uboot_env),0x80000(key_store),0x80000(info),0xA00000(etc),0xA00000(nope_kernel_1),0x2FC0000(nope_rootfs1),0xA00000(kernel),0x2FC0000(rootfs)

usage:
No webinterface is available, only way to connect is through ssh. user is "root", password is empty or "".

Let the device settle for 5 minutes after booting and trying to connect with ssh (if you don't have serial connection), or if you see serial output wait until there is a long message that says "jffs2 created successully with 0 errors" before pressing return and activating the serial console.
This happens only on first boot as it needs to generate the read-write partition.


for the curious ones:

If someone is wondering why this hacking around the mtdparts, it's because LEDE firmware's kernel looks for partitions called "rootfs" or "rootfs_data" and acts on them automatically.

In our case it splits on its own the "rootfs" partition in a first part with a squashfs filesystem and the rest of the space becomes another mtd partition where it creates a jffs2 (read-write) filesystem that then mounts as overlay on the squashfs (so you can write anywhere, and you can easily reset to defaults by erasing the jffs2 partition).

This system allows them to hard-code mtdparts in the dtb file so their kernel will ignore what uboot gives them, and their rootfs will be able to occupy the whole flash space instead of using only a pre-made mtd partition and wasting most of the NAND.
For this recovery system and for kirkwoods in general it's not that necessary, so I just rename an existing mtd partition in the kernel command line I send from uboot and call it a day.


Download link:

Here is the download package, https://www.dropbox.com/s/firggx4vzl6v4a4/kirkwood_recoveryV4-beta.7z?dl=0
I provide also "sources" and some instructions in the package so you can build the same on your own if you grab the LEDE sources from their git. (for the sake of openness).

EDIT: Now with fixed download link.



Edited 2 time(s). Last edit at 04/15/2017 10:13AM by bobafetthotmail.
Re: [BETA] Rescue System V4, using a custom LEDE firmware
September 09, 2016 08:27PM
> After some work and many Thanks Obama since LEDE
> devs don't cough up their secrets even after
> waterboarding,

:))


> This system allows them to hard-code mtdparts in
> the dtb file so their kernel will ignore what
> uboot gives them, and their rootfs will be able to
> occupy the whole flash space instead of using only
> a pre-made mtd partition and wasting most of the
> NAND.

> For this recovery system and for kirkwoods in
> general it's not that necessary, so I just rename
> an existing mtd partition in the kernel command
> line I send from uboot and call it a day.

Yes. This is the way to do it. People hard code the mtdparts in DTS because they think that should be default. But we are customizing u-boot and rootfs, that would be a limitation.

-bodhi
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner
Re: [BETA] Rescue System V4, using a custom LEDE firmware
September 10, 2016 07:34AM
bodhi Wrote:
-------------------------------------------------------
>
> Yes. This is the way to do it. People hard code
> the mtdparts in DTS because they think that
> should be default. But we are customizing u-boot
> and rootfs, that would be a limitation.

Well, I didn't do that because I'm not going to modify like 20 dts with custom mtdparts figuring out myself the hex offsets of things (assuming I know what are the stock mtdparts at all, and I don't, and I don't feel like wasting another week tracking down that info) while I have very easy access to bootloader settings through the script, and the bootloader is friendly and powerful as u-boot usually is.

LEDE does not usually have access to bootloader configuration when installing through the stock firmware, and even if they do they prefer not risking a softbrick.

I can see why stock firmwares would do the same. In case they decide to change on-flash partitions they only need to change dts and push a firmware update, without touching the bootloader. As long as the kernel image is in the same place (usually just after uboot and wifi calibration firmware), it will still boot fine.
Re: [BETA] Rescue System V4, using a custom LEDE firmware
September 10, 2016 04:58PM
> I can see why stock firmwares would do the same.
> In case they decide to change on-flash partitions
> they only need to change dts and push a firmware
> update, without touching the bootloader. As long
> as the kernel image is in the same place (usually
> just after uboot and wifi calibration firmware),
> it will still boot fine.

Right. They only deal with one box. So they just need to replace uImage.

-bodhi
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner
Re: [BETA] Rescue System V4, using a custom LEDE firmware
September 14, 2016 10:21AM
Bobaffetthotmail,

Outstanding project. Thank you for highlighting this fantastic distribution in this project. I look forward to installing, using and exploring.

Paul
Re: [BETA] Rescue System V4, using a custom LEDE firmware
October 02, 2016 01:19PM
Quick update:

I've added the "announce" LEDE package (a simple zeroconf server), this allows people to ssh into the recovery by hostname:
ssh root@lede.local
If their firewall allows that to happen (on Windows/OSX should work fine as both are heavy users of similar systems), my OpenSUSE's firewall required me to set internal interfaces first before It let me connect.

in my own testing version I've also added a new user with root privileges, "recovery". This user is special as its default shell is a script and not a shell.

This allows me to integrate in the recovery a script to deal with the most common use-cases (filesystem check, update uboot/recovery, make a new rootfs with latest rootfs/kernel, maybe make a RAID setup too).

root account is of course preserved because I'd like to not lock advanced users out of the recovery.
Re: [BETA] Rescue System V4, using a custom LEDE firmware
October 26, 2016 08:31AM
bobafetthotmail Wrote:
-------------------------------------------------------
> It's a custom-built LEDE/OpenWRT firmware.
> it needs only 2MiB of space for the kernel and
> 11MiB of space for the rootfs on the NAND (will
> use more if available and allows writing on it).
>
I suppose this is based on the new image generation that abandons the uImage kernel file.
Re: [BETA] Rescue System V4, using a custom LEDE firmware
October 26, 2016 01:34PM
habibie Wrote:
-------------------------------------------------------
> bobafetthotmail Wrote:
> --------------------------------------------------
> -----
> > It's a custom-built LEDE/OpenWRT firmware.
> > it needs only 2MiB of space for the kernel and
> > 11MiB of space for the rootfs on the NAND (will
> > use more if available and allows writing on
> it).
> >
> I suppose this is based on the new image
> generation that abandons the uImage kernel file.

nope. Kirkwoods are still using uImages like most other devices.

If your devices (oxynas I suppose) are still using wrong boot file for the bootloader they have (so they can't boot), open a bug ticket in the bug tracker https://bugs.lede-project.org/
Re: [BETA] Rescue System V4, using a custom LEDE firmware
April 14, 2017 10:10PM
perfect!! long awaited nanddump nandwrite
Re: [BETA] Rescue System V4, using a custom LEDE firmware
April 15, 2017 12:53AM
file does not exist.please upload again.
Re: [BETA] Rescue System V4, using a custom LEDE firmware
April 15, 2017 03:17AM
Can someone re-upload this please?!
Re: [BETA] Rescue System V4, using a custom LEDE firmware
April 15, 2017 10:16AM
Fixed link.

Dropbox updated the way they let their users share stuff so old links became invalid.
Re: [BETA] Rescue System V4, using a custom LEDE firmware
April 15, 2017 12:41PM
I got it to work on my pogoplug V4. Many thanks!

This is what I did:
1)write uimage to kernel partition
2)write lede-kirkwood-generic-squashfs.img to rootfs partition
3)change the env

Before I did this, my mtd only has uboot, kernel, rootfs partition

After I did this:
root@lede:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00200000 00020000 "kernel"
mtd2: 07d00000 00020000 "rootfs"
mtd3: 072a0000 00020000 "rootfs_data"

Is this the right way to do this?!



Edited 3 time(s). Last edit at 04/15/2017 01:03PM by protocold.
Re: [BETA] Rescue System V4, using a custom LEDE firmware
April 15, 2017 02:07PM
Yes, on first start the LEDE firmware splits the original rootfs partition into two partitions. All space not occupied by the squashfs (read-only root) will become rootfs_data which is read-write.
umd
Re: [BETA] Rescue System V4, using a custom LEDE firmware
May 09, 2017 02:24PM
Hello,

I have a pogo v4 that I was going to install this rescue on. I have run into something that is stopping me. I first setup mtdparts to include a kernel and rootfs. Reboot. Verify the mtd looks good then I did this.

flash_erase /dev/mtd2 0 0
Erasing 128 Kibyte @ 2e0000 -- 100 % complete 
nandwrite /dev/mtd2 uImage-kirkwood-pogoplug_v4


and that gives me this:

Input file is not page-aligned. Use the padding option.
nandwrite: error!: Data was only partially written due to error
           error 0 (Success)

Not sure what to do.

Edit:

Figured it out. Used this. nandwrite -b 1 -n /dev/mtd2 -p uImage-kirkwood-pogoplug_v4


Netconsole giving me this error upon boot to recovery:

** Bad device usb 0 **
loading DTB /boot/dts/kirkwood-pogoplug_v4.dtb ...
** Bad device usb 0 **
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   recovery-pogoplug_v4
   Created:      2016-09-09  19:17:21 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1871182 Bytes = 1.8 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!

NAND read: device 0 offset 0x500000, size 0x300000
NAND read from offset 500000 failed -74
 0 bytes read: ERROR
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   recovery-pogoplug_v4
   Created:      2016-09-09  19:17:21 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1871182 Bytes = 1.8 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!
Pogov4>



Edited 3 time(s). Last edit at 05/09/2017 04:15PM by umd.
Re: [BETA] Rescue System V4, using a custom LEDE firmware
May 09, 2017 04:40PM
nandwrite -b 1 -n /dev/mtd2 -p uImage-kirkwood-pogoplug_v4

I'm pretty sure you should not use the "-n", that option is used to flash special dumps of flash that have ECC info in them already.

The uimage is just a plain file, so it must be written with flash ecc enabled.

I think you should not need the "-b 1" option too.

the error is saying to use padding option, which is "-p"



Edited 1 time(s). Last edit at 05/09/2017 04:45PM by bobafetthotmail.
umd
Re: [BETA] Rescue System V4, using a custom LEDE firmware
May 09, 2017 05:04PM
Yep! That was it. When I started looking at what some of those other parameters were, -n stuck out as a culprit. I just kept the -p and eliminated the other variables and it booted right up. Thanks for your help and by the way, nice work on the project.



Edited 1 time(s). Last edit at 05/09/2017 05:04PM by umd.
Re: [BETA] Rescue System V4, using a custom LEDE firmware
May 11, 2017 04:59AM
continuing from https://forum.lede-project.org/t/installing-lede-on-nsa325/3611/2

The u-boot from LEDE doesn't work at all I only get
/e-data/ # nandwrite /dev/mtd0 kirkwood/generic/u-boot-nsa325/u-boot.kwb
Input file is not page aligned
Data did not fit into device, due to bad blocks
: Success

/e-data/tools # dmesg | grep -i bad 
Scanning device for bad blocks
Author:

Your Email:


Subject:


Spam prevention:
Please, enter the code that you see below in the input field. This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right. If you enter the wrong code, a new image is created and you get another chance to enter it right.
Message: