Install Debian on WD My Cloud home

Speaking of wireless, trying to get a USB RTL8188C working. When I run make for the driver I get header errors.

apt-get install linux-headers-$(uname -r)
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
E: Unable to locate package linux-headers-4.9.266
E: Couldn’t find any package by glob ‘linux-headers-4.9.266’
E: Couldn’t find any package by regex ‘linux-headers-4.9.266’

Anyone know what snapshot archive to add to snapshot.list ?

I had to compile the kernel and run
“make headers_install INSTALL_HDR_PATH=/usr/src/linux-headers-4.9.266”
to get the headers installed.

apt search linux-headers-

Hi @zeusjan i try to install the Deb10+OMV5 with the USB Images on my MCHD. It works until the system reboots after the successful installation in golden image boot. It reboots in recovery mode, using the usb boot.

[INFO]: bootState: BOOT_STATE_NO_OTA
[FATAL ERROR] CBR not found, boot USB rescue mode.
==== boot_rescue_from_usb =====
(Re)start USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
USB1:   USB XHCI 1.10
scanning bus 1 for devices... Unknown request , typeReq = 0x200c 
2 USB Device(s) found
USB2:   USB XHCI 1.10
scanning bus 2 for devices... Unknown request , typeReq = 0x200c 
1 USB Device(s) found
USB3:   USB XHCI 1.10
scanning bus 3 for devices... Unknown request , typeReq = 0x200c 
1 USB Device(s) found
       scanning usb for storage devices... Enter is_pmbr_valid
Warning: failed to 0xEE type in MBR
1 Storage Device(s) found

I try to fix that … but nothing change :frowning:q

need USB with MBR or replace a USB if has corrupted

Hello, you don´t have any need to touch the golden sections, you only need to modified the A or B sections (depending on where you gonna boot), but for the look of that log i believe that you mess more than the golden section, it looks like you delete or modified the FW Table, and that´s why your NAS is trying to boot from the usb, a normal boot with a functional FW table should look like this:

[INFO]: bootState: BOOT_STATE_NO_OTA
Start Boot Setup ...
---------------LOAD NORMAL FW TABLE ---------------
[INFO] fw desc table base: 0x00620000, count: 13

If you have a backup, i recommend you to load the backup and start from scratch, if you don´t have any, I can share a fw table with you, but i can´t guarantee is gonna work

Ok, i’ll try to restore the FW-Table. I guess it is possible with the uboot toolset right? Simular to this tutorial: RTD129X Unbrick

Otherwise i can try to fix it with your shared table too.

Thanks in advanced!

Edit: I try to fix the FWTable but without success…

REBOOT_ACTION : No Action
Hit Esc or Tab key to enter console mode or rescue linux:  0 
------------can't find tmp/factory/recovery
======== Checking into android recovery ====

reading bootConfig
Filesize: 8 bytes
8 bytes
Size: 8, got: 8

8 bytes read (take 6ms)

[INFO]: Boot golden image
Start Boot Setup ... 
---------------LOAD  GOLD  FW  TABLE ---------------
[INFO] fw desc table base: 0x00628000, count: 13
Normal boot fw follow...
GOLD Kernel:
         FW Image to 0x03000000, size=0x00c44e00 (0x03c44e00)
         FW Image fr 0x00a70000 
GOLD Rescue DT:
         FW Image to 0x01f00000, size=0x0000ef5a (0x01f0ef5a)
         FW Image fr 0x00630000 
GOLD Rescue ROOTFS:
         FW Image to 0x02200000, size=0x00c00000 (0x02e00000)
         FW Image fr 0x01a70000 
         FW Image checksum FAILED
         FW Image entry  checksum=0x3fff93a7
         FW Image result checksum=0x3fff9630
Booting golden image, use default bootarg

It shows “FW Image checksum FAILED” and boots again in USB Discovery :frowning:

this is 4.1 though, what is the link to the latest kernel?

I don’t know exactly how the bit sequence in the MCHD works… this is from the uboot source:

static int wd_boot_cbr(void)
{
	char *cbr = NULL;
	cbr = getenv("cbr");
	if(cbr != NULL)	{
		if( strncmp(cbr, "A", 1 ) == 0 ){
		// set the boot_mode
			boot_mode = BOOT_NORMAL_MODE;		// A image
		} else if( strncmp(cbr, "B", 1 ) == 0 )	{
			boot_mode = BOOT_RESCUE_MODE;		// B image
		}else {
			printf("[FATAL ERROR] Invalid CBR(%s) from uboot env, boot USB rescue mode.", cbr);
			gUSB_MODE = 1;
			return -1;
		}
	}else {	//unknown cbr
		printf("[FATAL ERROR] CBR not found, boot USB rescue mode.\n");
		gUSB_MODE = 1;
		return -1;
	}

	return 0;
}

Maybe it’s just as easy as writing the correct string to the config partition

mount /dev/sataa18 /mnt/
echo "2:B:2;" > /mnt/bootConfig

Sorry, I replied while you edited your post :slight_smile:

What are the two lines after the FW Image checksum FAILED?

Maybe you can fix this by using fwtablectl

It looks like you managed to fix the golden fw table, i believe that you had a checksum error because you change the kernel, dtb and rootfs on the beginning . What method do you use to change the kernel, rootfs and dtb file when you installed Debian? you used fwtutil from forth32 or other method???. you need to write again the kernel, rootfs and dtb file with a utility that modified the checksum on the fwtable (like fwtutil from forth32 install image). And you need to check and double check that you are going to write every thing in their corresponding place (the kernel on the golden kernel, etc.). the best practice now that you recovered the golden fwtable, is copy that table over another partition (1 or 2) and try to boot from there to no mess anymore with with the golden boot, so you can recover if you had any problem.

Short background story about the situation. My MCHD partitions brick them self, maybe while a broken update. Now it try to bring this system back to life … with debian and omv.

When i boot from usb and startup fwutils from forth32 is shows:

/ # fwtutil -l


 **** Firmware list ****

 ## ro lzma  version   tg_addr    offset   length   paddings checksum  type
--------------------------------------------------------------------------------------------

 00  1   0  00000000  03000000  00a70000  00c44e00  00c44e00 4c5ca44c  31 - GOLD_KERNEL         
 01  1   0  00000000  01f00000  00630000  0000ef5a  0000f000 001ee0de  32 - GOLD_RESCUE_DT      
 02  1   0  00000000  02200000  01a70000  00c00000  00c00000 3fff93a7  33 - GOLD_RESCUE_ROOTFS  
 03  1   0  00000000  01b00000  00670000  00317c30  00317e00 0dd71a22  34 - GOLD_AUDIO          
 04  1   0  00000000  00000000  069f0000  00000000  00000000 00000000  37 - UBOOT               
 05  1   0  00000000  03000000  02bb0000  00b7e600  00b7e600 4a7cca7b  02 - KERNEL              
 06  1   0  00000000  01f00000  048b0000  0000b8c3  0000ba00 001628a1  03 - RESCUE_DT           
 07  1   0  00000000  01f00000  02770000  0000f581  0000f600 001fee3a  04 - KERNEL_DT           
 08  1   0  00000000  02200000  05cf0000  00400000  00400000 18580222  05 - RESCUE_ROOTFS       
 09  1   0  00000000  02200000  03bb0000  00400000  00400000 18580222  06 - KERNEL_ROOTFS       
 10  1   0  00000000  01b00000  027b0000  00317c30  00317e00 0dd71a22  07 - AUDIO               
 11  1   0  00000000  01b00000  048f0000  000defa0  000df000 03e24215  44 - RESCUE_AUDIO        
 12  1   0  00000000  03000000  04cf0000  00b7e600  00b7e600 4a7cca7b  43 - RESCUE_KERNEL       
 * Total len = 03e79f9e      Paddings len = 03e7a600 *
/ # fwtutil -p

[   32.930541] pgd = ffffffc03e092000
 **** Part list ****

 type ro[   32.934127] [0000000b] *pgd=000000003e7fc003       length       fw_count fw_, *pud=000000003e7fc003type mount_point
--------------, *pmd=000000003e318003--------------------------------, *pte=0000000000000000
--

Segmentation fault

Did you have any idea to fix that?

@RAH-66 or @Alex-N do you guys have a link for upgrading the kernel to 4.9? I am running 4.1 kernel and I don’t see where to get the archive that contains the 4.9 kernel

I have this link kernel.zip - Google Drive but that’s 4.1

Is there an english guide though? The link is in Russian

try from here, but it has already changed a bit
WD MyCloud Home to Linux Server – 17. Install OpenMediaVault 6 and Debian 11 directly (new method) – Nerdy Projects / Nerdprojekte (wordpress.com)

Is it possible to upgrade the previous 4.1 kernel installed system to a 4.9 kernel system without hurting the existing installation or filesystems?

no, in new version use “sda” device, instead of “sataa”

yes, user files on “sataa24” can saved, to do this, skip the step of formatting partition sda21

make_ext4fs -L UsersFolders /dev/sda21

p.s. in the new version, the space of unused partitions 19, 21, 22 is merged with partition 20, so there are 21 partitions left in the system:

sda1-17 - firmware
sda18 - bootconfig
sda19 - system
sda20 - swap
sda21 - user files

I want to give this a go on my mycloud. Back at the beginning of this thread western1 said “Edit 28.04.2020 : others people confirm that you won’t loose your data” but later I saw where it looked like data was wiped during installation of debian. Has anyone done the install recently and do you lose your existing data?

I didn’t, but I also backed it up. If you don’t have local storage I’d recommend paying a few dollars to throw it on a cloud service for a couple of hours while you do the upgrade.

1 Like

Am I correct in assuming this install will remove the odd restsdk indexing and storage management software from the data areas of the MCH leaving a standard filesystem store in their place ?

I know this is an odd followup question, but does anybody know what project the storage system used in the original firmware is based on and what features it provides beyond a cloud API ?? (is it WD blb?)

It seems an odd engineering choice if it doesn’t provide zoned storage or some useful feature… It certainly makes a lot of things impossible and has many drawbacks… I just don’t get what would have motivated the design choice, the device is deliberately hobbled by some very questionable quirky choices.

A cloud auth system with no local fallback capability (unusable without internet access)
A cloud store system that slows access on local networks in exchange for ?? (nothing ?)
A cloud store that appears to have incomplete file semantics (or giant bugs)
A cloud store system that is not multi tasking (or has giant bugs)
Hardware with a lot of promise, but most of it completely and deliberately blocked off from its owner.
Forced and uncontrollable updating.

The resounding question I have for this is why ? Such potential here and they deliberately busted it.