HowTo: openWrt on OXNAS boxes
Posted by chessplayer
|
Re: HowTo: openWrt on OXNAS boxes August 02, 2022 07:20PM |
Registered: 11 years ago Posts: 144 |
bodhi Wrote:
-------------------------------------------------------
> Hold on.
>
> By " with the calculated file I can read from, but
> not write to uBoot-env."
>
> Do you mean the envs from my u-boot installation?
I mean using
(which was calculated from the OpenWrt MTD-layout) instead of this
(OpenWrt original) in fw_env.config
Cheers,
chessplayer
P.S.: Awake - not fully anymore, so anything else will have to happen tomorrow ...
---
Standart ist der Standardfehler
-------------------------------------------------------
> Hold on.
>
> By " with the calculated file I can read from, but
> not write to uBoot-env."
>
> Do you mean the envs from my u-boot installation?
I mean using
/dev/mtd1 0xc0000 0x20000 0x20000
(which was calculated from the OpenWrt MTD-layout) instead of this
/dev/mtd2 0x0 0x20000 0x20000
(OpenWrt original) in fw_env.config
Cheers,
chessplayer
P.S.: Awake - not fully anymore, so anything else will have to happen tomorrow ...
---
Standart ist der Standardfehler
|
Re: HowTo: openWrt on OXNAS boxes August 03, 2022 01:56PM |
Registered: 11 years ago Posts: 144 |
|
Re: HowTo: openWrt on OXNAS boxes August 03, 2022 02:29PM |
Registered: 11 years ago Posts: 144 |
chessplayer Wrote:
-------------------------------------------------------
> Ok, one more thing: I now made this
> mtdparts-definition permanent and had a look at
> what we see in debian then:
>
> Maybe this is also of interest. I will now check
> what this does in OpenWrt. And, to answer my own
> question, the result is the same as above
> (Bootloader command line (ignored) ).
Actually, I would like to come back to this with a question: Should there not be a modified MTD-layout here as well after passing it in the uBoot-env? The debian MTD-layout is also not influenced by the setting in the uBoot-env, it seems to me...
As I said before: confused!
Cheers,
chessplayer
---
Standart ist der Standardfehler
-------------------------------------------------------
> Ok, one more thing: I now made this
> mtdparts-definition permanent and had a look at
> what we see in debian then:
>
root@debian ~ $ uname -a Linux debian 5.4.179-oxnas-tld-1 #1.0 SMP PREEMPT Mon Feb 14 21:50:21 PST 2022 armv6l GNU/Linux root@debian ~ $ cat /proc/cmdline console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 mtdparts=41000000.nand:0x100000@0x0(u-boot),0x20000@0x100000(u-boot-env-main),0x80000@0x3c0000(u-boot-env),0x440000@0x9C0000(kernel),-(ubi) root@debian ~ $ cat /proc/mtd dev: size erasesize name mtd0: 00e00000 00020000 "boot" mtd1: 07200000 00020000 "data" root@debian ~ $ dmesg | grep -i 0x0 [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Kernel command line: console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 mtdparts=41000000.nand:0x100000@0x0(u-boot),0x20000@0x100000(u-boot-env-main),0x80000@0x3c0000(u-boot-env),0x440000@0x9C0000(kernel),-(ubi) [ 8.477432] 0x000000000000-0x000000e00000 :"boot" [ 8.485373] 0x000000e00000-0x000008000000 :"data" root@debian ~ $ fw_printenv | tail -n 5 partition=nand0,0 set_bootargs_owrt=setenv bootargs console=ttyS0,115200 $mtdparts bootcmd_owrt=run set_bootargs_owrt; nboot 60500000 0 440000; bootm bootcmd=run bootcmd_uenv; run scan_disk; run set_bootargs; run bootcmd_exec; run bootcmd_owrt mtdparts=mtdparts=41000000.nand:0x100000@0x0(u-boot),0x20000@0x100000(u-boot-env-main),0x80000@0x3c0000(u-boot-env),0x440000@0x9C0000(kernel),-(ubi) root@debian ~ $>
> Maybe this is also of interest. I will now check
> what this does in OpenWrt. And, to answer my own
> question, the result is the same as above
> (Bootloader command line (ignored) ).
Actually, I would like to come back to this with a question: Should there not be a modified MTD-layout here as well after passing it in the uBoot-env? The debian MTD-layout is also not influenced by the setting in the uBoot-env, it seems to me...
As I said before: confused!
Cheers,
chessplayer
---
Standart ist der Standardfehler
|
Re: HowTo: openWrt on OXNAS boxes August 03, 2022 04:27PM |
Admin Registered: 11 years ago Posts: 16,644 |
chessplayer,
What you see in Debian is a better implementation. We have new u-boot defines the envs location at 1MB in flash. The DTS has mtd0 as writeable. And the Debian kernel was configured to accept the bootargs (command line arguments). So everything works.
On OpenWrt side, it's the other way around. The envs are at a different location. The MTDs are protected by read-only property in the DTS. And the OPenWrt kernel was not configured to accept the command line arguments. So we cannot change the envs at all.
Note that the only hurdle here is the command line arguments. If the OpenWrt kernel had this configured in, then we would be able to pass mtdparts into the kernel and everything will fall into place. But we don't want to recompile the kernel, or try to marry the Debian DTB file to OpenWrt kernel. Sysupgrade will wipe that out each time, and things will be confusing for the users.
So that where your confusion was.
====
OK, so now you guys have found a work around to specify the location of the envs from my u-boot. And can read them. It's half of the solution. Let me write in the next post the other half. To complete a relatively cookie cutter process.
-bodhi
===========================
Forum Wiki
bodhi's corner
What you see in Debian is a better implementation. We have new u-boot defines the envs location at 1MB in flash. The DTS has mtd0 as writeable. And the Debian kernel was configured to accept the bootargs (command line arguments). So everything works.
On OpenWrt side, it's the other way around. The envs are at a different location. The MTDs are protected by read-only property in the DTS. And the OPenWrt kernel was not configured to accept the command line arguments. So we cannot change the envs at all.
Note that the only hurdle here is the command line arguments. If the OpenWrt kernel had this configured in, then we would be able to pass mtdparts into the kernel and everything will fall into place. But we don't want to recompile the kernel, or try to marry the Debian DTB file to OpenWrt kernel. Sysupgrade will wipe that out each time, and things will be confusing for the users.
So that where your confusion was.
====
OK, so now you guys have found a work around to specify the location of the envs from my u-boot. And can read them. It's half of the solution. Let me write in the next post the other half. To complete a relatively cookie cutter process.
-bodhi
===========================
Forum Wiki
bodhi's corner
|
Re: HowTo: openWrt on OXNAS boxes August 03, 2022 05:28PM |
Admin Registered: 11 years ago Posts: 16,644 |
This is my current thinking. A bit of experiement needed to script the u-boot envs during boot so that it can attach and read the ubi rootfs and load a text file from it.
It sounds overkilled, but this is probably the only way, given the limitation of OpenWrt put on us. And we dont want to recompile its kernel.
==========
Reference to the u-boot installation instruction: 2015.10 U-Boot for Pogoplug V3 (OXNAS OX820).
To be able to "set" envs in OpenWrt and let the new u-boot read it, we need to use uEnv.txt capability. This was mentioned in the installation Section A.
==========
Testing steps
1. Log in to OpenWrt and create uEnv.txt with the initial content as below
Use nano to edit this file (to ensure it is a proper text file)
Add this single line
2. Reboot
2.1 Attach ubi partition
(TBD)
2.2 List the OpenWrt directory to find the exact location of uEnv.txt.
(TBD) The UBIFS volume is probably the first letter, and eventually down that path, we'll find uEnv.txt.
2.3 Setup u-boot env to load it.
(TBD) The current bootcmd_uenv scans and loads uEnv.txt from disk storage. So we need to adjust this to load from the UBIFS volume.
2.4 Test print
-bodhi
===========================
Forum Wiki
bodhi's corner
Edited 1 time(s). Last edit at 08/03/2022 05:30PM by bodhi.
It sounds overkilled, but this is probably the only way, given the limitation of OpenWrt put on us. And we dont want to recompile its kernel.
==========
Reference to the u-boot installation instruction: 2015.10 U-Boot for Pogoplug V3 (OXNAS OX820).
To be able to "set" envs in OpenWrt and let the new u-boot read it, we need to use uEnv.txt capability. This was mentioned in the installation Section A.
Quote
A. How to use the uEnv.txt script (Optional)
This uEnv.txt script can be used to further customizing u-boot envs without saving to NAND or to boot with a completely different set of u-boot envs.
Create a text file in /boot directory with the content in the format that u-boot envs are listed.
==========
Testing steps
1. Log in to OpenWrt and create uEnv.txt with the initial content as below
mkdir -p /boot cd /boot
Use nano to edit this file (to ensure it is a proper text file)
nano uEnv.txt
Add this single line
loaded_envs=See_uEnv.txt_from_rootfsExit and save the file.
2. Reboot
2.1 Attach ubi partition
(TBD)
2.2 List the OpenWrt directory to find the exact location of uEnv.txt.
(TBD) The UBIFS volume is probably the first letter, and eventually down that path, we'll find uEnv.txt.
2.3 Setup u-boot env to load it.
(TBD) The current bootcmd_uenv scans and loads uEnv.txt from disk storage. So we need to adjust this to load from the UBIFS volume.
2.4 Test print
printenv loaded_envs
-bodhi
===========================
Forum Wiki
bodhi's corner
Edited 1 time(s). Last edit at 08/03/2022 05:30PM by bodhi.
|
Re: HowTo: openWrt on OXNAS boxes August 03, 2022 05:33PM |
Registered: 11 years ago Posts: 144 |
bodhi Wrote:
-------------------------------------------------------
> This is my current thinking. A bit of experiement
> needed to script the u-boot envs during boot so
> that it can attach and read the ubi rootfs and
> load a text file from it.
>
> It sounds overkilled, but this is probably the
> only way, given the limitation of OpenWrt put on
> us. And we dont want to recompile its kernel.
>
> ==========
>
> Reference to the u-boot installation instruction:
> 2015.10
> U-Boot for Pogoplug V3 (OXNAS OX820).
>
> To be able to "set" envs in OpenWrt and let the
> new u-boot read it, we need to use uEnv.txt
> capability. This was mentioned in the installation
> Section A.
>
>
> ==========
>
> Testing steps
>
> 1. Log in to OpenWrt and create uEnv.txt with the
> initial content as below
>
>
> Use nano to edit this file (to ensure it is a
> proper text file)
>
> Add this single line
>
>
> 2. Reboot
>
> 2.1 Attach ubi partition
>
> (TBD)
>
> 2.2 List the OpenWrt directory to find the exact
> location of uEnv.txt.
>
> (TBD) The UBIFS volume is probably the first
> letter, and eventually down that path, we'll find
> uEnv.txt.
>
> 2.3 Setup u-boot env to load it.
>
> (TBD) The current bootcmd_uenv scans and loads
> uEnv.txt from disk storage. So we need to adjust
> this to load from the UBIFS volume.
>
> 2.4 Test print
>
>
Anything I can do to help?
Cheers,
chessplayer
---
Standart ist der Standardfehler
-------------------------------------------------------
> This is my current thinking. A bit of experiement
> needed to script the u-boot envs during boot so
> that it can attach and read the ubi rootfs and
> load a text file from it.
>
> It sounds overkilled, but this is probably the
> only way, given the limitation of OpenWrt put on
> us. And we dont want to recompile its kernel.
>
> ==========
>
> Reference to the u-boot installation instruction:
> 2015.10
> U-Boot for Pogoplug V3 (OXNAS OX820).
>
> To be able to "set" envs in OpenWrt and let the
> new u-boot read it, we need to use uEnv.txt
> capability. This was mentioned in the installation
> Section A.
>
>
>Quote
A. How to use the uEnv.txt script
> (Optional)
>
> This uEnv.txt script can be used to further
> customizing u-boot envs without saving to NAND or
> to boot with a completely different set of u-boot
> envs.
>
> Create a text file in /boot directory with the
> content in the format that u-boot envs are
> listed.
> ==========
>
> Testing steps
>
> 1. Log in to OpenWrt and create uEnv.txt with the
> initial content as below
>
>
> mkdir -p /boot > cd /boot >>
> Use nano to edit this file (to ensure it is a
> proper text file)
>
> nano uEnv.txt >>
> Add this single line
>
> loaded_envs=See_uEnv.txt_from_rootfs >> Exit and save the file.
>
> 2. Reboot
>
> 2.1 Attach ubi partition
>
> (TBD)
>
> 2.2 List the OpenWrt directory to find the exact
> location of uEnv.txt.
>
> (TBD) The UBIFS volume is probably the first
> letter, and eventually down that path, we'll find
> uEnv.txt.
>
> 2.3 Setup u-boot env to load it.
>
> (TBD) The current bootcmd_uenv scans and loads
> uEnv.txt from disk storage. So we need to adjust
> this to load from the UBIFS volume.
>
> 2.4 Test print
>
>
> printenv loaded_envs >
Anything I can do to help?
Cheers,
chessplayer
---
Standart ist der Standardfehler
|
Re: HowTo: openWrt on OXNAS boxes August 03, 2022 06:49PM |
Admin Registered: 11 years ago Posts: 16,644 |
chessplayer,
Sure,
1. Make sure the uEnv.txt will survive a sysupgrade. Most important to find out first! if it does not, then that will need to be a caveat for users to save the file and restore.
2. Boot with serial/neconsole. Interrupt u-boot and
Mount it
List files in /boot
-bodhi
===========================
Forum Wiki
bodhi's corner
Edited 1 time(s). Last edit at 08/03/2022 06:55PM by bodhi.
Sure,
1. Make sure the uEnv.txt will survive a sysupgrade. Most important to find out first! if it does not, then that will need to be a caveat for users to save the file and restore.
2. Boot with serial/neconsole. Interrupt u-boot and
setenv mtdparts 'mtdparts=orion_nand:0x100000@0x0(u-boot),-@0x100000(ubi)' setenv partition 'nand0,0' ubi part ubi ubi infovolume name should be in the output.
Mount it
ubifsmount <volume name>
List files in /boot
ubifsls boot
-bodhi
===========================
Forum Wiki
bodhi's corner
Edited 1 time(s). Last edit at 08/03/2022 06:55PM by bodhi.
|
Re: HowTo: openWrt on OXNAS boxes August 03, 2022 06:54PM |
Admin Registered: 11 years ago Posts: 16,644 |
Other thought: we can also file a "bug" report at OpenWrt site to request for this OXNAS kernel processes the bootargs passed into by u-boot :)
-bodhi
===========================
Forum Wiki
bodhi's corner
-bodhi
===========================
Forum Wiki
bodhi's corner
|
Re: HowTo: openWrt on OXNAS boxes August 04, 2022 01:50PM |
Registered: 11 years ago Posts: 144 |
bodhi Wrote:
-------------------------------------------------------
> chessplayer,
>
> Sure,
>
> 1. Make sure the uEnv.txt will survive a
> sysupgrade. Most important to find out first! if
> it does not, then that will need to be a caveat
> for users to save the file and restore.
>
I am pretty sure that nothing survives a sysupgrade except for files in /etc/config (see the output of 'sysupgrade -v' in David's post further up). So, here is my test, which I performed with an addition. Booted into OpenWrt and then:
Additionally:
Now the sysupgrade (went back to the latest stable version)
As you can see (green line), uEnv.txt in /etc/config can be expected to survive (and forget about the red line - the sysupgrade works). Let's test that:
Conclusion: The /boot-directory did not survive. Thus, if the file absolutely has to be in /boot, it should be symlinked. However, since the uBoot-env will have to be customized anyway, why not just read it from /etc/config right away for the OpenWrt boot?
> 2. Boot with serial/neconsole. Interrupt u-boot
> and
>
>
First of all, I think this has to start with:
So, this is as far as I got, since I am obviously too stupid to specify the volume name:
This did not help either (as you can see at the bottom of the above code).
Please advise!
Cheers,
chessplayer
---
Standart ist der Standardfehler
-------------------------------------------------------
> chessplayer,
>
> Sure,
>
> 1. Make sure the uEnv.txt will survive a
> sysupgrade. Most important to find out first! if
> it does not, then that will need to be a caveat
> for users to save the file and restore.
>
I am pretty sure that nothing survives a sysupgrade except for files in /etc/config (see the output of 'sysupgrade -v' in David's post further up). So, here is my test, which I performed with an addition. Booted into OpenWrt and then:
mkdir -p /boot cd /boot nano uEnv.txt # wrote loaded_envs=See_uEnv.txt_from_rootfs
Additionally:
# this should survive cp uEnv.txt /etc/config/
Now the sysupgrade (went back to the latest stable version)
cd /tmp wget https://downloads.openwrt.org/releases/21.02.3/targets/oxnas/ox820/openwrt-21.02.3-oxnas-ox820-cloudengines_pogoplug-series-3-squashfs-sysupgrade.tar sysupgrade -v openwrt-21.02.3-oxnas-ox820-cloudengines_pogoplug-series-3-squashfs-sysupgrade.tar root@OpenWrt:/tmp# sysupgrade -v openwrt-21.02.3-oxnas-ox820-cloudengines_pogoplug-series-3-squashfs-sysupgrade.tar Thu Aug 4 17:52:47 UTC 2022 upgrade: Saving config files... etc/config/dropbear etc/config/firewall etc/config/fstab etc/config/luci etc/config/mdadm etc/config/network etc/config/rpcd etc/config/system etc/config/uEnv.txt etc/config/ubootenv etc/config/ubootenv_bodhi etc/config/ubootenv_owrt etc/config/ubootenv_test1 etc/config/ubootenv_test2 etc/config/ucitrack etc/config/uhttpd etc/dropbear/dropbear_ed25519_host_key etc/dropbear/dropbear_rsa_host_key etc/fw_env.config etc/group etc/hosts etc/inittab etc/luci-uploads/.placeholder etc/opkg/keys/2f8b0b98e08306bf etc/opkg/keys/4d017e6f1ed5d616 etc/passwd etc/profile etc/rc.local etc/shadow etc/shells etc/shinit etc/sysctl.conf etc/uhttpd.crt etc/uhttpd.key etc/uhttpd.key etc/uhttpd.crt Thu Aug 4 17:52:47 UTC 2022 upgrade: Commencing upgrade. Closing all shell sessions. Command failed: Connection failed root@OpenWrt:/tmp# Connection to 192.168.XXX.YYY closed by remote host.
As you can see (green line), uEnv.txt in /etc/config can be expected to survive (and forget about the red line - the sysupgrade works). Let's test that:
BusyBox v1.33.2 (2022-04-16 12:59:34 UTC) built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 21.02.3, r16554-1d4dea6d4f
-----------------------------------------------------
=== WARNING! =====================================
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
--------------------------------------------------
root@OpenWrt:~# cd /boot
-ash: cd: can't cd to /boot: No such file or directory
root@OpenWrt:~# cat /etc/config/uEnv.txt
loaded_envs=See_uEnv.txt_from_rootfs
root@OpenWrt:~#
Conclusion: The /boot-directory did not survive. Thus, if the file absolutely has to be in /boot, it should be symlinked. However, since the uBoot-env will have to be customized anyway, why not just read it from /etc/config right away for the OpenWrt boot?
> 2. Boot with serial/neconsole. Interrupt u-boot
> and
>
>
> setenv mtdparts > 'mtdparts=orion_nand:0x100000@0x0(u-boot),-@0x100000(ubi)' > setenv partition 'nand0,0' > ubi part ubi > ubi info >> volume name should be in the output.
First of all, I think this has to start with:
setenv mtdparts 'mtdparts=41000000.nand:0x100000@0x0(u-boot),-@0x100000(ubi)'
So, this is as far as I got, since I am obviously too stupid to specify the volume name:
U-Boot 2015.10-tld-2 (Oct 21 2017 - 22:00:02 -0700)
OXNAS OX820
gcc (Debian 6.3.0-18) 6.3.0 20170516
GNU ld (GNU Binutils for Debian) 2.28
Hit any key to stop autoboot: 8
0
OX820> setenv mtdparts 'mtdparts=41000000.nand:0x100000@0x0(u-boot),-@0x100000(ubi)'
setenv mtdparts 'mtdparts=41000000.nand:0x100000@0x0(u-boot),-@0x100000(ubi)'
OX820> setenv partition 'nand0,0'
setenv partition 'nand0,0'
OX820> ubi part ubi
ubi part ubi
UBI: attaching mtd1 to ubi0
UBI: scanning is finished
UBI: attached mtd1 (name "mtd=1", size 127 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: 1016, bad PEBs: 0, corrupted PEBs: 0
UBI: user volume: 2, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 6/3, WL threshold: 4096, image sequence number: 834073264
UBI: available PEBs: 104, 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: 127 MiB
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 129024 bytes
UBI: number of good PEBs: 1016
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: 2
UBI: available PEBs: 104
UBI: total number of reserved PEBs: 912
UBI: number of PEBs reserved for bad PEB handling: 20
UBI: max/mean erase counter: 6/3
OX820> ubifsmount /dev/mtd1
ubifsmount /dev/mtd1
Error reading superblock on volume '/dev/mtd1' errno=-22!
ubifsmount - mount UBIFS volume
Usage:
ubifsmount <volume-name>
- mount 'volume-name' volume
OX820> ubifsmount mtd=1
ubifsmount mtd=1
Error reading superblock on volume 'mtd=1' errno=-22!
ubifsmount - mount UBIFS volume
Usage:
ubifsmount <volume-name>
- mount 'volume-name' volume
OX820> ubifsmount mtd1
ubifsmount mtd1
Error reading superblock on volume 'mtd1' errno=-22!
ubifsmount - mount UBIFS volume
Usage:
ubifsmount <volume-name>
- mount 'volume-name' volume
OX820> ubifsmount ubi0
ubifsmount ubi0
Error reading superblock on volume 'ubi0' errno=-22!
ubifsmount - mount UBIFS volume
Usage:
ubifsmount <volume-name>
- mount 'volume-name' volume
OX820> ubifsmount ubi0_0
ubifsmount ubi0_0
Error reading superblock on volume 'ubi0_0' errno=-22!
ubifsmount - mount UBIFS volume
Usage:
ubifsmount <volume-name>
- mount 'volume-name' volume
OX820> ubifsmount ubi:mtd1
ubifsmount ubi:mtd1
Error reading superblock on volume 'ubi:mtd1' errno=-19!
ubifsmount - mount UBIFS volume
Usage:
ubifsmount <volume-name>
- mount 'volume-name' volume
OX820> ubifsmount ubi:mtd=1
ubifsmount ubi:mtd=1
Error reading superblock on volume 'ubi:mtd=1' errno=-19!
ubifsmount - mount UBIFS volume
Usage:
ubifsmount <volume-name>
- mount 'volume-name' volume
OX820>
OX820>
This did not help either (as you can see at the bottom of the above code).
Please advise!
Cheers,
chessplayer
---
Standart ist der Standardfehler
|
Re: HowTo: openWrt on OXNAS boxes August 04, 2022 03:57PM |
Admin Registered: 11 years ago Posts: 16,644 |
Quote
Conclusion: The /boot-directory did not survive. Thus, if the file absolutely has to be in /boot, it should be symlinked. However, since the uBoot-env will have to be customized anyway, why not just read it from /etc/config right away for the OpenWrt boot?
No it does not have to be in /boot. /etc/config is fine!
Have you tried
ubifsmount ubi0:mdt1
-bodhi
===========================
Forum Wiki
bodhi's corner
|
Re: HowTo: openWrt on OXNAS boxes August 04, 2022 04:09PM |
Registered: 11 years ago Posts: 144 |
bodhi Wrote:
-------------------------------------------------------
>
> No it does not have to be in /boot. /etc/config is
> fine!
Great!
>
> Have you tried
>
No, seems like this is the one combination I haven't tried ;-)
Anyway, it looks like the last sysupgrade broke something, since the box is not picked up anymore by netconsole during boot and it does not boot OpenWrt anymore ... I am currently trying to boot your debian from stick and hope for the best - if it does not work, I might have to try reinstalling the rescue system, but then I do not know how to update the envs ...
Just realized that this won't work either, since I cannot install OpenWrt without access to nc ..
Will get back once this is sorted out but it may take some time, since I will be out of town tomorrow!
Cheers,
chessplayer
---
Standart ist der Standardfehler
Edited 1 time(s). Last edit at 08/04/2022 04:12PM by chessplayer.
-------------------------------------------------------
>
>Quote
Conclusion: The /boot-directory did not
> survive. Thus, if the file absolutely has to be in
> /boot, it should be symlinked. However, since the
> uBoot-env will have to be customized anyway, why
> not just read it from /etc/config right away for
> the OpenWrt boot?
> No it does not have to be in /boot. /etc/config is
> fine!
Great!
>
> Have you tried
>
> ubifsmount ubi0:mdt1 >
No, seems like this is the one combination I haven't tried ;-)
Anyway, it looks like the last sysupgrade broke something, since the box is not picked up anymore by netconsole during boot and it does not boot OpenWrt anymore ... I am currently trying to boot your debian from stick and hope for the best - if it does not work, I might have to try reinstalling the rescue system, but then I do not know how to update the envs ...
Just realized that this won't work either, since I cannot install OpenWrt without access to nc ..
Will get back once this is sorted out but it may take some time, since I will be out of town tomorrow!
Cheers,
chessplayer
---
Standart ist der Standardfehler
Edited 1 time(s). Last edit at 08/04/2022 04:12PM by chessplayer.
|
Re: HowTo: openWrt on OXNAS boxes August 07, 2022 05:13PM |
Registered: 11 years ago Posts: 144 |
bodhi Wrote:
-------------------------------------------------------
[snip ...]
[...snap]
>
> Have you tried
>
So, after unbricking the OXNAS box, I tried this suggestion, but without success (preliminary steps as before):
Now, in OpenWrt, I checked the available blocks beforehand:
That made me wonder (but not enough, apparently):
What now (or rather: tomorrow ...)?
Cheers,
chessplayer
P.S.: These commands apparently bricked the device again! So, I have to be extremely careful when performing the tests, it would seem ... I am confused!
---
Standart ist der Standardfehler
-------------------------------------------------------
[snip ...]
[...snap]
>
> Have you tried
>
> ubifsmount ubi0:mdt1 >
So, after unbricking the OXNAS box, I tried this suggestion, but without success (preliminary steps as before):
OX820> ubifsmount ubi0:mdt1
ubifsmount ubi0:mdt1
Error reading superblock on volume 'ubi0:mdt1' errno=-19!
ubifsmount - mount UBIFS volume
Usage:
ubifsmount <volume-name>
- mount 'volume-name' volume
OX820>
Now, in OpenWrt, I checked the available blocks beforehand:
root@OpenWrt:~# blkid /dev/ubi0_1: UUID="eaa436ab-920d-454c-b47b-de15f9a5db60" TYPE="ubifs" /dev/ubi0_0: TYPE="squashfs" /dev/mtdblock4: UUID="834073264" TYPE="ubi" /dev/ubiblock0_0: TYPE="squashfs" root@OpenWrt:~#
That made me wonder (but not enough, apparently):
OX820> ubifsmount ubi0_0:mdt1
ubifsmount ubi0_2:mdt1
Error reading superblock on volume 'ubi0_0:mdt1' errno=-22!
ubifsmount - mount UBIFS volume
Usage:
ubifsmount <volume-name>
- mount 'volume-name' volume
OX820> ubifsmount ubi0_1:mtd1
ubifsmount ubi0_1:mtd1
Error reading superblock on volume 'ubi0_1:mtd1' errno=-22!
ubifsmount - mount UBIFS volume
Usage:
ubifsmount <volume-name>
- mount 'volume-name' volume
OX820>
What now (or rather: tomorrow ...)?
Cheers,
chessplayer
P.S.: These commands apparently bricked the device again! So, I have to be extremely careful when performing the tests, it would seem ... I am confused!
---
Standart ist der Standardfehler
|
Re: HowTo: openWrt on OXNAS boxes August 07, 2022 07:00PM |
Admin Registered: 11 years ago Posts: 16,644 |
Hi chessplayer,
> P.S.: These commands apparently bricked the
> device again!
Arghhh :)
Let's regroup. I think we are trying too much to get around this limitation without examining the flash structure created by OpenWrt installation and sysupgrade.
For now it's a caveat in the installation: that you can only read from the envs inside Openwrt, but can only update it in serial/net console.
I have to boot up my Pogo V3 (it's on the shelf). I need to build new Debian stable kernel anyway. So will see what I will find out.
-bodhi
===========================
Forum Wiki
bodhi's corner
> P.S.: These commands apparently bricked the
> device again!
Arghhh :)
Let's regroup. I think we are trying too much to get around this limitation without examining the flash structure created by OpenWrt installation and sysupgrade.
For now it's a caveat in the installation: that you can only read from the envs inside Openwrt, but can only update it in serial/net console.
I have to boot up my Pogo V3 (it's on the shelf). I need to build new Debian stable kernel anyway. So will see what I will find out.
-bodhi
===========================
Forum Wiki
bodhi's corner
|
Re: HowTo: openWrt on OXNAS boxes August 07, 2022 08:53PM |
Registered: 7 years ago Posts: 339 |
bodhi Wrote:
-------------------------------------------------------
> For now it's a caveat in the installation: that
> you can only read from the envs inside Openwrt,
> but can only update it in serial/net console.
>
Curious as to why you can't update envs in OpenWrt? The uboot-env partition is not set read-only.
This should allow editing the environment after installing the uboot-envtools package and creating the appropriate config file.
-------------------------------------------------------
> For now it's a caveat in the installation: that
> you can only read from the envs inside Openwrt,
> but can only update it in serial/net console.
>
Curious as to why you can't update envs in OpenWrt? The uboot-env partition is not set read-only.
+ partition@3c0000 {
+ label = "u-boot-env";
+ reg = <0x003c0000 0x00080000>;
+ };
This should allow editing the environment after installing the uboot-envtools package and creating the appropriate config file.
|
Re: HowTo: openWrt on OXNAS boxes August 07, 2022 10:28PM |
Admin Registered: 11 years ago Posts: 16,644 |
rayknight,
You should read the whole thread!
I will boot up my Pogo V3 and see for myself. But it does make sense to me from what I've seen in this thread that OpenWrt can not write to it currenly.
-bodhi
===========================
Forum Wiki
bodhi's corner
You should read the whole thread!
I will boot up my Pogo V3 and see for myself. But it does make sense to me from what I've seen in this thread that OpenWrt can not write to it currenly.
-bodhi
===========================
Forum Wiki
bodhi's corner
|
Re: HowTo: openWrt on OXNAS boxes August 12, 2022 07:37PM |
Admin Registered: 11 years ago Posts: 16,644 |
Hi chessplayer,
I've not been able to boot up my Pogo V3 yet. But I've looked at my old notes. Wow 5,6 years ago :) I created a Kirkwood rescue system but never release it.
If you see the volume rootfs_data from the layout, try mounting it. It seems to be OpenWrt standard naming convetion used also in Kirkwood boards.
That should be the overlay part of the system (formatted in ubifs). The rootfs volume cannot be mounted, since it is a squashfs. I don't believe this u-boot even knows squash.
Boot into OpenWrt and
-bodhi
===========================
Forum Wiki
bodhi's corner
I've not been able to boot up my Pogo V3 yet. But I've looked at my old notes. Wow 5,6 years ago :) I created a Kirkwood rescue system but never release it.
ubi part ubi ubi info ubi info layout
If you see the volume rootfs_data from the layout, try mounting it. It seems to be OpenWrt standard naming convetion used also in Kirkwood boards.
ubifsmount ubi0:rootfs_data
That should be the overlay part of the system (formatted in ubifs). The rootfs volume cannot be mounted, since it is a squashfs. I don't believe this u-boot even knows squash.
Boot into OpenWrt and
mountIt should show the rootfs mounted with squashfs. And the /overlay is ubifs. The upper layer of the root file system is etc. (it's overlaid on top) So that's why /etc/config is sticky and not got overwritten by sysupgrade.
-bodhi
===========================
Forum Wiki
bodhi's corner
