HowTo: openWrt on OXNAS boxes

Quote

6. Install to NAND

Finally, we can perform a sysupgrade of OpenWrt/LEDE either using the LUCI WIF (Web Interface) or the command line.

< text about removing all USB drives here>

Since we are already logged in via ssh, I only describe the latter option, while the former may be found, e.g., in step 4.b of Jörg's original post for the Kirkwoods. We must do:
opkg update
opkg install ca-certificates
cd /tmp
wget <URL of our desired sysupgrade file>
sysupgrade <name of our desired sysupgrade file>
The desired upgrade file may be found the same way as we found the image in step 2 above starting from the release page (but, ideally, you kept the browser tab open in step 2). There you can just copy the link address to the sysupgrade file (tar or bin depending on the release) and paste it into the ssh window.

Remark: Coresponding to the above uImages, the concrete files for the sysupgrade were
this upgrade file for the classic Pogoplug v3
this upgrade file for the Pogoplug Pro

remove: The upgrade process will result in an automatic reboot (during which I removed the USB stick, but that may not be necessary).

To make it foolproof, you should recommend removing all USB drives (in case the box was booted into Debian on USB before, and then users installing OpenwWrt). Also, it's serving as a rescue system, so seeing it booted without Debian would be a nice proof of concept.

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



Edited 1 time(s). Last edit at 08/14/2022 04:47PM by bodhi.

Now in step 7, you would talk about setting up the envs. And mention that it is not writeable.

Quote

7. Boot from NAND and log in to OpenWrt

.......

generate or modify /etc/fw_env.config
Check whether the file /etc/fw_env.config has the following contents (which is easily calculated from the above MTD layout in comparison to bodhi's):
/dev/mtd1 0xc0000 0x20000 0x20000
If not or if the file does not exist at all, the easiest way to modify/generate it is
echo '/dev/mtd1 0xc0000 0x20000 0x20000' > /etc/fw_env.config

Afterwards, check that the uBoot environment is found by printing the variables to screen using
fw_printenv

...

=====

Rationale:

The installation for OpenWrt on OXNAS and Kirkwood are different in step 5 and step 7. It is because we have no way of passing mtdparts into the system, so in Step 5 the envs are not used at all. In Step 7, we want to see if we can read the envs while OpenWrt is running. And possibly will implement something to make it writeable later.

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



Edited 1 time(s). Last edit at 08/14/2022 04:50PM by bodhi.

OK, that's all I have for now!

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

bodhi,

thanks for taking the time to critically appraise my first post. I have implemented your suggestions and hope that we are now good to go searching for a solution.

Cheers,

chessplayer

---
Standart ist der Standardfehler

bodhi,

since I had not touched my Pogoplug Pro for a while, I tried the first post on it and, as expected, got as far as we had gotten on the classic before. So then I looked at your proposed tests again and decided to modify them a bit, not quite knowing whether that would be what you really needed, but at least it got me some more info. In principle, the idea was to leave the mtdparts definition from the uBoot-env alone and start from there.

Here is the result:

OX820> printenv mtdparts
printenv mtdparts
mtdparts=mtdparts=41000000.nand:14m(boot),-(data)
OX820> setenv partition 'nand0,0'
setenv partition 'nand0,0'
OX820> ubi part data
ubi part data
UBI: attaching mtd1 to ubi0
UBI: scanning is finished
UBI: attached mtd1 (name "mtd=1", size 114 MiB) to ubi0
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 512
UBI: VID header offset: 512 (aligned 512), data offset: 2048
UBI: good PEBs: 912, bad PEBs: 0, corrupted PEBs: 0
UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 3797175681
UBI: available PEBs: 0, total reserved PEBs: 912, PEBs reserved for bad PEB handling: 20
OX820> ubi info
ubi info
UBI: MTD device name:            "mtd=1"
UBI: MTD device size:            114 MiB
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    129024 bytes
UBI: number of good PEBs:        912
UBI: number of bad PEBs:         0
UBI: smallest flash I/O unit:    2048
UBI: VID header offset:          512 (aligned 512)
UBI: data offset:                2048
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:             0
UBI: total number of reserved PEBs: 912
UBI: number of PEBs reserved for bad PEB handling: 20
UBI: max/mean erase counter: 2/1
OX820> ubi info layout
ubi info layout
Volume information dump:
	vol_id          0
	reserved_pebs   888
	alignment       1
	data_pad        0
	vol_type        3
	name_len        6
	usable_leb_size 129024
	used_ebs        888
	used_bytes      114573312
	last_eb_bytes   129024
	corrupted       0
	upd_marker      0
	name            rootfs
Volume information dump:
	vol_id          2147479551
	reserved_pebs   2
	alignment       1
	data_pad        0
	vol_type        3
	name_len        13
	usable_leb_size 129024
	used_ebs        2
	used_bytes      258048
	last_eb_bytes   2
	corrupted       0
	upd_marker      0
	name            layout volume
OX820> ubifsmount ubi0:rootfs
ubifsmount ubi0:rootfs
OX820> ubifsls /
ubifsls /
<DIR>	     3984  Sat Apr 16 12:59:34 2022  bin
<DIR>	      160  Sat Apr 16 12:59:34 2022  dev
<DIR>	     4032  Fri Jan 29 20:20:40 2021  etc
<DIR>	     1904  Sat Apr 16 12:59:34 2022  lib
<DIR>	      160  Sat Apr 16 12:59:34 2022  mnt
<DIR>	      224  Sat Apr 16 12:59:34 2022  rom
<DIR>	      160  Sat Apr 16 12:59:34 2022  tmp
<DIR>	      160  Sat Apr 16 12:59:34 2022  sys
<LNK>	        3  Sat Apr 16 12:59:34 2022  var
<DIR>	      480  Tue Aug 02 18:04:25 2022  usr
<DIR>	      368  Sat Apr 16 12:59:34 2022  www
<DIR>	      160  Sat Apr 16 12:59:34 2022  proc
<DIR>	     3736  Sat Apr 16 12:59:34 2022  sbin
<DIR>	      160  Sat Apr 16 12:59:34 2022  root
<DIR>	      160  Sat Apr 16 12:59:34 2022  overlay
OX820> ubifsls /etc
ubifsls /etc
<LNK>	        7  Sat Apr 16 12:59:34 2022  TZ
	       70  Sat Apr 16 12:59:34 2022  udhcpc.user
<DIR>	      296  Fri Jan 29 20:20:40 2021  ssl
	       34  Mon Aug 15 12:12:37 2022  fw_env.config
<LNK>	       12  Sat Apr 16 12:59:34 2022  mtab
<DIR>	      376  Sat Apr 16 12:59:34 2022  opkg
<DIR>	     2320  Mon Aug 15 12:09:27 2022  rc.d
	      305  Sat Apr 16 12:59:34 2022  hotplug-preinit.json
<LNK>	       21  Sat Apr 16 12:59:34 2022  os-release
<DIR>	      376  Sat Apr 16 12:59:34 2022  iproute2
	      170  Sat Apr 16 12:59:36 2022  board.json
<DIR>	     1696  Sat Apr 16 12:59:34 2022  init.d
<DIR>	      328  Sat Apr 16 12:59:50 2022  dropbear
	     1522  Sat Apr 16 12:59:34 2022  hotplug.json
	       18  Sat Apr 16 12:59:34 2022  openwrt_version
<DIR>	      552  Sat Apr 16 12:59:34 2022  rc.button
<DIR>	      160  Sat Apr 16 12:59:34 2022  udhcpc.user.d
	      664  Sat Apr 16 12:59:36 2022  uhttpd.crt
	      121  Sat Apr 16 12:59:36 2022  uhttpd.key
	     3233  Sat Apr 16 12:59:34 2022  rc.common
<DIR>	      424  Sat Apr 16 12:59:34 2022  hotplug.d
<DIR>	      232  Sat Apr 16 12:59:34 2022  luci-uploads
	      948  Sat Apr 16 12:59:34 2022  diag.sh
	      352  Sat Apr 16 12:59:34 2022  firewall.user
	      320  Sat Apr 16 12:59:34 2022  passwd
	       80  Sat Apr 16 12:59:34 2022  sysctl.conf
<DIR>	      312  Sat Apr 16 12:59:34 2022  board.d
	       61  Sat Apr 16 12:59:34 2022  fstab
	      189  Sat Apr 16 12:59:34 2022  group
	      110  Sat Apr 16 12:59:34 2022  hosts
	      106  Sat Apr 16 12:59:34 2022  inittab
<DIR>	      824  Sat Apr 16 12:59:34 2022  modules-boot.d
<DIR>	     1960  Sat Apr 16 12:59:34 2022  modules.d
<DIR>	      312  Sat Apr 16 12:59:34 2022  sysctl.d
	      180  Sat Apr 16 12:59:34 2022  shadow
	        9  Sat Apr 16 12:59:34 2022  shells
	     1120  Sat Apr 16 12:59:34 2022  shinit
	      461  Sat Apr 16 12:59:34 2022  banner.failsafe
	      123  Sat Apr 16 12:59:34 2022  device_info
	      512  Sat Apr 16 12:59:54 2022  urandom.seed
<LNK>	       14  Sat Apr 16 12:59:34 2022  localtime
	      397  Sat Apr 16 12:59:34 2022  banner
	     2541  Sat Apr 16 12:59:34 2022  protocols
<DIR>	      160  Sat Apr 16 12:59:37 2022  uci-defaults
<DIR>	      160  Sat Apr 16 12:59:34 2022  crontabs
	      132  Sat Apr 16 12:59:34 2022  rc.local
<DIR>	      304  Sat Apr 16 12:59:34 2022  capabilities
<LNK>	       16  Sat Apr 16 12:59:34 2022  resolv.conf
<DIR>	      968  Mon Aug 15 12:11:00 2022  config
	      213  Sat Apr 16 12:59:34 2022  openwrt_release
	      128  Sat Apr 16 12:59:34 2022  sysupgrade.conf
	      609  Sat Apr 16 12:59:34 2022  preinit
	     1046  Sat Apr 16 12:59:34 2022  profile
	      108  Sat Apr 16 12:59:34 2022  opkg.conf
	      130  Sat Apr 16 12:59:34 2022  ethers
	     3073  Sat Apr 16 12:59:34 2022  services
OX820> ubifsls /etc/config
ubifsls /etc/config
	      973  Mon Aug 15 12:09:27 2022  luci
	      167  Sat Apr 16 12:59:34 2022  rpcd
	      521  Mon Aug 15 12:11:00 2022  network
	      788  Sat Apr 16 12:59:34 2022  ucitrack
	      134  Sat Apr 16 12:59:34 2022  dropbear
	      151  Sat Apr 16 12:59:36 2022  fstab
	      445  Sat Apr 16 12:59:34 2022  mdadm
	      449  Mon Aug 15 12:09:10 2022  system
	      783  Sat Apr 16 12:59:36 2022  uhttpd
	      352  Sat Apr 16 12:59:35 2022  wireless
	     4632  Sat Apr 16 12:59:34 2022  firewall
	      132  Sat Apr 16 12:59:37 2022  ubootenv

Hope this helps. Is there a command to show the contents of a file using ubifs<something>? My naive try ubifscat did not do the job ...

Cheers,

chessplayer

---
Standart ist der Standardfehler

chessplayer,

>. I have implemented your suggestions
> and hope that we are now good to go searching for
> a solution.

I don't see the updates in the 1st post ?

> Is there a command to show the contents of a file using ubifs<something>? My naive try ubifscat did not do the job ...

I don't think there is cat command for ubifs in u-boot. Usually you would just load a file to memory for some purpose, but no need to print the content.

So now we have proven that the user settings area could be accessed.

I'm still thinking of a better way to do this. So for now, please update the instruction and let it stew for a day or 2.

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

bodhi,

the first post is definitely updated:

Edited 3 time(s). Last edit at 08/15/2022 01:44PM by chessplayer.

Do you need to refresh the page, maybe?

Cheers,

chessplayer

---
Standart ist der Standardfehler

I guess I was not very clear in my post. I suggested that the text in blue should be moved to Step 7. And delete the text in red.

We know the envs are not useable yet. And there is no way to adjust mtdparts. So everything about the envs should be discussed in Step 7. What remain in Step 5 is a sanilty check.

Quote

5. Log in to OpenWrt

Find the IP address of your box and ssh into it (user root without password). The following step is absolutely crucial but does not yet quite work the way we would expect.

Verify your mtd layout.

Ideally, (see bodhi's u-Boot post) it should be:
root@OpenWrt:# cat /proc/mtd

dev: size erasesize name
mtd0: 00e00000 00020000 "boot"
mtd1: 07200000 00020000 "data"

Instead, what it will probably be (at least it was for me) is:

root@OpenWrt:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00020000 "stage1"
mtd1: 00380000 00020000 "u-boot"
mtd2: 00080000 00020000 "u-boot-env"
mtd3: 009c0000 00020000 "kernel"
mtd4: 07200000 00020000 "ubi"

This means that for OpenWrt, the boot-section is further subdivided, while the ubi-/data-section is the same - so that is promising. However, since apparently our mtdparts-definition from step 1 was not picked up, we will have to calculate a bit in order to specify where fw_printenv should find the uBoot environment.

Temporarily generate or modify /etc/fw_env.config
Check whether the file /etc/fw_env.config has the following contents (which is easily calculated from the above MTD layout in comparison to bodhi's):
/dev/mtd1 0xc0000 0x20000 0x20000
If not or if the file does not exist at all, the easiest way to modify/generate it is
echo '/dev/mtd1 0xc0000 0x20000 0x20000' > /etc/fw_env.config

Afterwards, check that the uBoot environment is found by printing the variables to screen using
fw_printenv

Remarks:
Since OpenWrt only runs in RAM at the moment, this is a temporary change. If you want to be able to access the uBoot environment from the OpenWrt rescue system later on, this step will most likely have to be repeated (see step 7 below).
If you would rather modify an existing file, you can do so using vim (which is pre-installed in OpenWrt). If, like me, you do not want to learn vim and prefer nano, you can instead do
opkg update && opkg install nano

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

bodhi,

sorry, but that does not make too much sense to me and I cannot really see the added value in this. In my eyes, the instructions are consistent and do make sense as they are. Also, it is steps 5 and 7 where we have a difference to the Kirkwood instructions, so I believe it is at these points where the issues should be mentioned.

Cheers,

chessplayer

---
Standart ist der Standardfehler

Hey chessplayer,

It's your instruction after all. So if you feel that what it should be then keep it.

But the whole point about seeing the envs is a bit counterproductive at Step 5. You cannot really change them, and the new envs setup in Step 1 is applicable to u-boot only. OpenWrt does not use them at all.

If one looks at the mtdparts env and comparing that with output of cat /proc/mtd, one would be in doubt whether it is going to work :) Not setting up the envs would eliminate that confusion.

In the Kirkwood installation it is good to see envs, because the cat /proc/mtd is shown to have a layout consistent with the env mtdparts used in u-boot. And users can change envs at that point.

So we would only need to see the OpenWrt MTD layout to make sure that the subsequent Steps will succeed. If the MTD layout is different from what in the instruction, then everything will fail afterward.


=====

If you want some parallell with the Kirwood instruction, which I think a really good point, then I would just saying something like:

"At this point the u-boot envs are not modifiable due to the OpenWrt kernel configuration restriction. See further set up and explanation later in Step 7"

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



Edited 2 time(s). Last edit at 08/15/2022 09:32PM by bodhi.

So after thinking a bit about this envs issue, there are a couple approaches that would work, but I don't really like either one :) they are not foolproof.

The uEnv.txt method is really more appropriate when booting with rootfs on USB or SATA. If a mistake is introduced in this uEnv.txt file (quite easy to mess up the envs), and causes a semi-brick, we would be able to remove it easily from the drive. OTOH, if this file is in UBIFS, then we would need to either use net/serial console to unbrick it. Or boot back to Debian and mount the UBI partition to fix it.

So at this point, we will just live with the restriction that envs can be changed only in net/serial console.

=====

If this box has not been frozen in OpenWrt, I could try to send a pull request to add the bootloader commandline capability to the kernel. I think it must have been an oversight, because the Kirkwood kernel in OpenWrt included this capabilty, but the OXNAS kernel does not. However, we don't know whether it will be accepted.

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



Edited 1 time(s). Last edit at 08/17/2022 02:54PM by bodhi.

Added to the Wiki thread.

Quote
https://forum.doozan.com/read.php?2,23630
Rescue Systems

Rescue System V2 (Original)
MacPlug & SMBPLug
Rescue System Pogo V3
Rescue System V4, using a custom LEDE firmware (BETA)
Rescue System for Pogo E02 using LEDE/OpenWrt (Install with Serial Console)
Rescue System for Pogo V4/Mobile using OpenWrt (Install with NetConsole)
Rescue System using OpenWrt on Kirkwood boxes
Rescue System using OpenWrt on OXNAS (Pogoplug V3 Classic and Pro)

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

And thanks for your contribution chessplayer!

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

bodhi Wrote:
-------------------------------------------------------
[snip ...]
>
> =====
>
> If this box has not been frozen in OpenWrt, I
> could try to send a pull request to add the
> bootloader commandline capability to the kernel. I
> think it must have been an oversight, because the
> Kirkwood kernel in OpenWrt included this
> capabilty, but the OXNAS kernel does not. However,
> we don't know whether it will be accepted.

[...snap]

bodhi,

thanks go mainly to you and I would say that sending this pull request probably makes the most sense. At least for 22.03 it should still be possible, since that is still in rc state (but then I have no idea how these release decisions are taken).

Cheers,

chessplayer

---
Standart ist der Standardfehler