moonman wrote:Yes i is safe to say 'y' to erase.
There is more to it and I have taken the time to write up on further issues I found with the initial instructions, documenting the expected outputs and interactions as well (IP address subject to each user's setup of course).
As actually there's no wget in Arch by default, and Internet not necessarily up&available all the time, you'll want the following first to avoid not getting the downloader or the download half way through rewriting NAND:
ssh root@192.168.2.94 wrote:[root@alarm ~]# cd ~
[root@alarm ~]# wget
https://dl.dropboxusercontent.com/u/15043728/ArchLinuxArm/kirkwood-rescue/rescue1.4.img.ubifs-bash: wget: command not found
[root@alarm ~]# pacman -S wget
resolving dependencies...
looking for conflicting packages...
Packages (1) wget-1.16.3-1
Total Download Size: 0.45 MiB
Total Installed Size: 2.29 MiB
:: Proceed with installation? [Y/n]
:: Retrieving packages ...
wget-1.16.3-1-arm 458.7 KiB 156K/s 00:03 [#########################] 100%
(1/1) checking keys in keyring [#########################] 100%
(1/1) checking package integrity [#########################] 100%
(1/1) loading package files [#########################] 100%
(1/1) checking for file conflicts [#########################] 100%
(1/1) checking available disk space [#########################] 100%
(1/1) installing wget [#########################] 100%
Optional dependencies for wget
ca-certificates: HTTPS downloads [installed]
[root@alarm ~]# wget
https://dl.dropboxusercontent.com/u/15043728/ArchLinuxArm/kirkwood-rescue/rescue1.4.img.ubifs--2015-03-21 07:27:50--
https://dl.dropboxusercontent.com/u/15043728/ArchLinuxArm/kirkwood-rescue/rescue1.4.img.ubifsResolving dl.dropboxusercontent.com (dl.dropboxusercontent.com)... 54.243.46.82, 54.243.255.237, 107.20.165.93, ...
Connecting to dl.dropboxusercontent.com (dl.dropboxusercontent.com)|54.243.46.82|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 120121344 (115M) [application/octet-stream]
Saving to: 'rescue1.4.img.ubifs'
rescue1.4.img.ubifs 100%[=======================>] 114.56M 1.14MB/s in 1m 41s s
2015-03-21 07:29:34 (1.14 MB/s) - 'rescue1.4.img.ubifs' saved [120121344/120121344]
There should be some sanity checks about addressing the proper devices&geometry too...
ssh root@192.168.2.94 wrote:[root@alarm ~]# dmesg | grep 0x00
[ 1.119689] 0x000000000000-0x000000100000 : "u-boot"
[ 1.125169] 0x000000100000-0x000008000000 : "rootfs"
[root@alarm ~]# fw_printenv mtdparts
mtdparts=mtdparts=orion_nand:1M(u-boot),-(rootfs)
...before proceeding to and all along the way of...
ssh root@192.168.2.94 wrote:[root@alarm ~]# ubiformat /dev/mtd1
ubiformat: mtd1 (nand), size 133169152 bytes (127.0 MiB), 1016 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 1015 -- 100 % complete
ubiformat: 936 eraseblocks are supposedly empty
ubiformat: warning!: 80 of 1016 eraseblocks contain non-UBI data
ubiformat: continue? (y/N) y
ubiformat: warning!: only 0 of 1016 eraseblocks have valid erase counter
ubiformat: erase counter 0 will be used for all eraseblocks
ubiformat: note, arbitrary erase counter value may be specified using -e option
ubiformat: continue? (y/N) y
ubiformat: use erase counter 0 for all eraseblocks
ubiformat: formatting eraseblock 1015 -- 100 % complete
[root@alarm ~]# ls -l /dev/ubi*
crw------- 1 root root 248, 0 Dec 10 22:16 /dev/ubi0
crw------- 1 root root 248, 1 Dec 10 22:16 /dev/ubi0_0
crw------- 1 root root 10, 58 Dec 10 22:16 /dev/ubi_ctrl
[root@alarm ~]# ubiattach -p /dev/mtd1
UBI device number 0, total 1016 LEBs (131088384 bytes, 125.0 MiB), available 992 LEBs (127991808 bytes, 122.1 MiB), LEB size 129024 bytes (126.0 KiB)
[root@alarm ~]# ubimkvol /dev/ubi0 -m -N rootfs
Set volume size to 127991808
Volume ID 0, size 992 LEBs (127991808 bytes, 122.1 MiB), LEB size 129024 bytes (126.0 KiB), dynamic, name "rootfs", alignment 1
[root@alarm ~]# ubiupdatevol /dev/ubi0_0 rescue1.4.img.ubifs
[root@alarm ~]# shutdown -h now
Connection to 192.168.2.94 closed by remote host.
Connection to 192.168.2.94 closed.
One will probably want to perform this clean shutdown at least (no sync and/or ubidetach BTW?) before considering it all...
moonman wrote:Done.
Recommendations:
Boot into rescue system by removing all external storage devices.
Presumably one's "production Arch" USB stick holding the active system shouldn't be pulled just like this, but rather considered safe to remove only after shutdown and preferably powering off.
moonman wrote:Install Arch u-boot. You will only have mtd0 and mtd1 with uboot environment setup the right way. If you want to keep bodhi's uboot you need to figure out too many things yourself.
Actually most readers won't anymore (to the extent that now I did), as per netconsole on...
nc -up 6666 192.168.2.94 6666 wrote:Hit any key to stop autoboot: 10
0
PogoE02> printenv
...shows what's missing from the more versatile bodhi uBoot's environment, and provides a chance to test the lines below before committing the environment to flash (and potentially brick if they were in error):
nc -up 6666 192.168.2.94 wrote:setenv fdt_addr 0x800000
setenv fdt_file /boot/dtbs/kirkwood-pogo_e02.dtb
setenv loadaddr 0x810000
setenv zimage /boot/zImage
setenv mountubi 'ubi part rootfs; ubifsmount ubi0:rootfs'
setenv loadubizimage 'ubifsload ${loadaddr} ${zimage}'
setenv loadubifdt 'ubifsload ${fdt_addr} ${fdt_file}'
setenv bootzubi 'echo Booting rescue Arch from NAND ...; run setargsubi; bootz ${loadaddr} - ${fdt_addr};'
setenv setargsubi 'setenv bootargs console=${console},${baudrate} ${optargs} ubi.mtd=1 root=ubi0:rootfs ro rootfstype=ubifs rootwait ${mtdparts}'
setenv loadubi 'echo Trying to boot rescue Arch from NAND ...;if run mountubi; then run loadubizimage;run loadubifdt;ubifsumount;run bootzubi;fi'
setenv bootcmd 'run bootcmd_uenv; run bootcmd_usb; run bootcmd_mmc; run bootcmd_sata; echo Trying to fall back to stock from NAND ...; fsload uboot-original-mtd0.kwb && go 0x800200; echo Assuming Arch NAND partitioning...; setenv mtdparts mtdparts=orion_nand:1M(u-boot),-(rootfs); setenv partition nand0,1; usb start; setenv letter 9;for type in usb; do for disk in 0 1 2 3; do if ${type} part ${disk};then setexpr letter $letter + 1;run load;fi;done;done;run loadubi; reset'
boot
With all USB media unplugged, then one can...
PogoE02> boot wrote: b o o t
(Re)start USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Unknown command 'mmc' - try 'help'
Unknown command 'ide' - try 'help'
no USB devices available
Unknown command 'mmc' - try 'help'
Unknown command 'ide' - try 'help'
(Re)start USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
** Bad device usb 0 **
** Bad device usb 0 **
Wrong Image Format for bootm command
ERROR: can't get kernel image!
Unknown command 'mmc' - try 'help'
** Bad device mmc 0 **
** Bad device mmc 0 **
Wrong Image Format for bootm command
ERROR: can't get kernel image!
Unknown command 'ide' - try 'help'
** Bad device ide 0 **
** Bad device ide 0 **
Wrong Image Format for bootm command
ERROR: can't get kernel image!
Trying to fall back to stock from NAND ...
### JFFS2 loading 'uboot-original-mtd0.kwb' to 0x810000
Scanning JFFS2 FS: get_fl_mem: unknown device type, using raw offset!
get_fl_mem: unknown device type, using raw offset!
... keeps repeating through mtd2 all NAND long ...
get_fl_mem: unknown device type, using raw offset!
done.
find_inode failed for name=uboot-original-mtd0.kwb
load: Failed to find inode
### JFFS2 LOAD ERROR<0> for uboot-original-mtd0.kwb!
Assuming Arch NAND partitioning...
(Re)start USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
no USB devices available
no USB devices available
no USB devices available
no USB devices available
Trying to boot rescue Arch from NAND ...
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 129024 bytes
UBI: smallest flash I/O unit: 2048
UBI: sub-page size: 512
UBI: VID header offset: 512 (aligned 512)
UBI: data offset: 2048
UBI: attached mtd1 to ubi0
UBI: MTD device name: "mtd=1"
UBI: MTD device size: 127 MiB
UBI: number of good PEBs: 1016
UBI: number of bad PEBs: 0
UBI: max. allowed volumes: 128
UBI: wear-leveling threshold: 4096
UBI: number of internal volumes: 1
UBI: number of user volumes: 1
UBI: available PEBs: 10
UBI: total number of reserved PEBs: 1006
UBI: number of PEBs reserved for bad PEB handling: 10
UBI: max/mean erase counter: 1/0
UBIFS: mounted UBI device 0, volume 0, name "rootfs"
UBIFS: mounted read-only
UBIFS: file system size: 126572544 bytes (123606 KiB, 120 MiB, 981 LEBs)
UBIFS: journal size: 9033728 bytes (8822 KiB, 8 MiB, 71 LEBs)
UBIFS: media format: w4/r0 (latest is w4/r0)
UBIFS: default compressor: zlib
UBIFS: reserved for root: 0 bytes (0 KiB)
Loading file '/boot/zImage' to addr 0x00810000 with size 4130248 (0x003f05c8)...
Done
Loading file '/boot/dtbs/kirkwood-pogo_e02.dtb' to addr 0x00800000 with size 10228 (0x000027f4)...
Done
Unmounting UBIFS volume rootfs!
Booting rescue Arch from NAND ...
Kernel image @ 0x810000 [ 0x000000 - 0x3f05c8 ]
## Flattened Device Tree blob at 00800000
Booting using the fdt blob at 0x800000
Starting kernel ...
Which looks good

but the chainload should still be tested on a machine with conventional 4-partition layout and working stock Pogo OS preserved.
Then
that would seem to handle fallbacks to traditional and Arch NAND gracefully, i.e. could be committed to the NAND environment at 0xc0000 by saveenv in bodhi's uBoot or by prepending the above setenv lines with fw_ each in Arch.
SSH security having been tightened, e.g. Ubuntu won't let you connect to the embedded rescue system, hence you'll need to make it either ignore the changed fingerprint...
- Code: Select all
ssh -o UserKnownHostsFile=/dev/null root@192.168.2.94
...or delete the known one (which will change again due to the procedure below) when switching between rescue and regular Arch:
- Code: Select all
ssh-keygen -f "/home/user/.ssh/known_hosts" -R 192.168.2.94
ssh -o 'StrictHostKeyChecking=no' root@192.168.2.94
Then the rescue system setup can be completed (optionally including the lines for fw_setenv as above after further testing):
- Code: Select all
.
/#\ _ _ _ _
/###\ __ _ _ __ ___| |__ | (_)_ __ _ ___ __| | _ ___ __ __
/#####\ / _` | '__/ __| '_ \ | | | '_ \| | | \ \/ /| | / \ | _ \ \/ |
/##.-.##\ | (_| | | | (__| | | || | | | | | |_| |> < | |/ ^ \| / |\/| |
/##( )##\ \__,_|_| \___|_| |_||_|_|_| |_|\__,_/_/\_\| /_/ \_\_|_\_| |_|
/#.-- --.#\ |_|
/' '\
(rescue)[root@alarm ~]# mount -o remount,rw /
(rescue)[root@alarm ~]# rm /etc/ssh/ssh_host*
(rescue)[root@alarm ~]# ssh-keygen -A
ssh-keygen: generating new host keys: RSA1 RSA DSA ECDSA ED25519
(rescue)[root@alarm ~]# passwd
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
(rescue)[root@alarm ~]# mount -o remount,ro /
(rescue)[root@alarm ~]# shutdown -h now
Thanks again to moonman for providing this really nice & powerful embedded rescue system!

Hopefully the above should help to keep all other OS options open as well:
Everyone please feel free to enhance, extend & refine - as well as most importantly integrate flexibility & backups with installers.