fvdw-sl on WD My Cloud

[fvdw]

If you do that also please erase partition 5 to be sure the boot doesn't use the kernel that was in partition 5.
erasing partiton 5 could be done as follow

Code: Select all

dd if=/dev/null of=/dev/sdb5

assuming sdb is your wd disk

[matt_max]

Ok so that is the output from the serial console before I made any changes.

And here we have the same output but after I cleared sda5 partition and put the new image on partition sda7 and sda8. System was not able to start.

P.S. I wasn't sure if partition sda5 was wipped out...

Code: Select all

WDMyCloud:~# dd if=/dev/null of=/dev/sda5
0+0 records in
0+0 records out
0 bytes (0 B) copied, 0.000396285 s, 0.0 kB/s


...so I zeroed it.

Code: Select all

WDMyCloud:~# sudo dd if=/dev/zero of=/dev/sda5
dd: writing to `/dev/sda5': No space left on device
204801+0 records in
204800+0 records out
104857600 bytes (105 MB) copied, 4.4391 s, 23.6 MB/s


[fvdw]

Well from the outputs I learn that the change we made on partition 7 and 8 seems to be ok, no crc error when reading partition 7, also no problem to load and start the kernel from partition 6. (Note you should check if partition 5 is still empty and if part 7 and are unchanged, meaning have the content of the one I have sent you.(To check that they are not overwritten at boot by barebox).
The reason why the wd firmware failed to load after making the changes is because the root file system could not be mounted.
Looking to the kernel command line in the unchanged version the rootfs is set to i/dev/md1, and in adapted version it is set /dev/md0. It seems on your test disk the raid array was defined as /dev/md1.
That is strange as in this post https://plugout.net/viewtopic.php?f=4&t=3635&start=10#p36915 from you /dev/md0 is mentioned, and I assume you copied the images if the original disk :scratch
Did you make a change in the raid setup of your test disk?
Anyhow if we change part 7 to use /dev/md1 (and again afdapt crc check values) I expect firmware will load. Also recreating on your test dis the raid array as //dev/md0 should do it.
But reason must be found why md0 was changed in md1in the first place on your test disk.

[matt_max]

That is correct - I have made one small change.
When I have done "Full restore" procedure I noticed that there were 2 arrays:

md0 with sda1 and missing sda2 member

and

md1 with sda2 and missing sda1 member

When I've checked that md0 wasn't mount (and md1 was mounted) I stopped array with

Code: Select all

mdadm --stop /dev/md0

and then added missing member to md1 with

Code: Select all

mdadm --add /dev/md1 /dev/sda2

P.S. Maybe newer version of Barebox check crc :scratch As you can see from logs wd use old version (2011.06.0) when the last one was made yesterday (2022.08.0).

[fvdw]

P.S. Maybe newer version of Barebox check crc :scratch As you can see from logs wd use old version (2011.06.0) when the last one was made yesterday (2022.08.0

No, the old one also checks crc. Of course when there is no crc error detected, boot goes on, in case of a crc error barebox will report it and will try to load partition 8. As this doesn't happen on our modified partition 7 it means the correct crc values were used.

What I don't understand is how the original partition 7 changed md0 to md1.
Probably this is done by barebox in case an update of rootfs is installed. (Did you install an upfate)
It also means that the raid1 only uses one partition sda1 or sda2.
The directories are used to make installation of updated firmware possible.

[fvdw]

I modified my previous post

[Jocko]

If I understand the current test, it is done with a cloned disk partitions (just reduce the data partition).

if the OS uses mdadm.conf file to save the raid information. It may detect a raid md0 is in use and then define a new one (so md1).

So we have to find if there is somewhere this file. usually it is in the folder etc (or etc/mdadm/ or usr/etc/ or usr/etc/mdadm/)

[fvdw]

the question how partition 7 (and probably 8) are changed.
I think when the wd firmware is running and when an updated firmware is installed that the running firmware adapt partition 7 and 8 to swap boot partition

[fvdw]

@matt_max you still have to check this

(Note you should check if after boot partition 5 is still empty and if part 7is unchanged, meaning have the content of the one I have sent you.(To check that they are not overwritten at boot by barebox).

ps I will not be available until next week wednesday

[fvdw]

some interesting info for the weekend
In the wd firmware there are two files in /usr/local/share
k1m0.env and k1m1.env
This files have the content that we found in partition 7 and 8
The difference between the two is roofs name k1m0.env contains /dev/md0 the other file /dev/md1

there is a bash script in /var/lib/dpkg/info/kernel-mindspeed-sequoia.postinst
In there the change is made when upgrading the firmware

Code: Select all

<snip>
kernel_copy ()
{
    kernelFile=${upgradePath}/boot/uImage
    if [ -e "${kernelFile}" ]; then
        ## TBD: Add multi drive support
        #dd if=${kernelFile}  of=${kernelPart1}
        #dd if=${kernelFile}  of=${kernelPart2}
        ##
        dd if=${kernelFile}  of=/dev/sda${kernelPart1}
        dd if=${kernelFile}  of=/dev/sda${kernelPart2}
    fi
    echo "Done kernel partition copy."
}

control_copy ()
{
    controlFile=${upgradePath}/boot/boot.env
    [ -z "${upgradeDevice}" ] || [ "${upgradeDevice}" == "/dev/md0" ] && cp -v ${upgradePath}/usr/local/share/k1m0.env ${controlFile}
    [ "${upgradeDevice}" == "/dev/md1" ] && cp -v ${upgradePath}/usr/local/share/k1m1.env ${controlFile}
    if [ -f "${controlFile}" ]; then
        ## TBD: Add multi drive support
        #dd if=${controlFile} of=${controlPart1}
        #dd if=${controlFile} of=${controlPart2}
        ##
        dd if=${controlFile} of=/dev/sda${controlPart1}
        dd if=${controlFile} of=/dev/sda${controlPart2}
    fi
    echo "Done control partition copy."
}

_install ()
{
    # perform copy and configure only when installing on a real target
    [ ! -f /tmp/nas_build ] && kernel_copy
    [ ! -f /tmp/nas_build ] && control_copy
    configure
}

_upgrade ()
{
    kernel_copy
    control_copy
    configure
}
<snip>


My guess
This means not barebox changes the content of partition 7 and 8 but the firmware when upgrading
That also means we can adapt these partitions and they will not be changed when fvdw-sl firmware is running unless we implement a script doing that.

:mrgreen:

ps I will not be available until next week wednesday