[GUIDE] How to Boot from a USB Stick


#1

This guide will demonstrate how to boot the NAS from a USB stick for testing, diagnosis and recovery purposes. No modifications to the NAS or its firmware are required.

WARNING: THE FOLLOWING PROCEDURES MAY VOID YOUR WARRANTY OR BRICK YOUR NAS - USE EXTREME CAUTION AT ALL TIMES

NOTE: BASIC LINUX SKILLS AND ROOT ACCESS VIA SSH ARE REQUIRED

Each of the Linux command examples shown below is preceeded with "# " (no quotes). This indicates a command prompt with root access. If copying/pasting a command, do not copy/paste the "# " portion of the example.

The following instructions are based on the WD My Cloud PR4100 NAS firmware, but they may be applicable to other WD My Cloud models, possibly with minor variations applied as needed.

Format a USB stick using the Fat32 filesystem and change its volume label to USB_RESCUE.

Download a copy of the My Cloud PR4100 GPL Source Code and extract the following files.

/WDMyCloud_PR4100_GPL_v2.30.165_20170321/firmware/merge/grub.tgz
/WDMyCloud_PR4100_GPL_v2.30.165_20170321/firmware/merge/uImage
/WDMyCloud_PR4100_GPL_v2.30.165_20170321/firmware/merge/uRamdisk

Extract the contents of the grub.tgz file.

/grub/EFI/BOOT/bootx64.efi
/grub/EFI/BOOT/grub.cfg
/grub/startup.nsh

Edit the grub.cfg file and replace its contents with the following.

set default="0"
set timeout="5"
set fallback=1
set kcmdline="root=/dev/ram0 rootfstype=ramfs rootwait console=ttyS0,115200n8 net.ifnames=0 acpi_enforce_resources=lax"
set root=(hd0,msdos1)

menuentry "USB Test Firmware" {
	Alpha_CRC32_Reset
	Alpha_CRC32_Check /uImage /uRamdisk
	linux /uImage ${kcmdline}
	initrd /uRamdisk
}

menuentry "USB Rescue Firmware" {
	Alpha_CRC32_Reset
	Alpha_CRC32_Check /uImage-rescue /uRamdisk-rescue
	linux /uImage-rescue ${kcmdline}
	initrd /uRamdisk-rescue
}

Copy uImage, uRamdisk and the contents of the grub folder to the root of the USB stick as follows. Do not copy the grub folder, only its contents.

/EFI/BOOT/bootx64.efi
/EFI/BOOT/grub.cfg
/startup.nsh
/uImage
/uRamdisk

The bootx64.efi file is the GRUB bootloader, which is configured by the grub.cfg file. The startup.nsh file is a script, which automatically runs every time a bootloader shell environment is opened. The uImage file is the Linux kernel, and the uRamdisk file is the initial RAM filesystem.

At this point, the first GRUB menu entry will be sufficient to boot a Linux kernel and initramfs for testing purposes. However, the NAS firmware also requires a SquashFS file named image.cfs to load the primary root filesystem, which is currently loaded from NAND flash memory. Loading the image.cfs file from the USB stick is possible, but knowledge of the firmware build process is required.

If the NAS fails to boot from USB, try using a different USB flash drive. In some cases there may be certain hardware incompatibilities which can cause it to fail to boot properly. In my experience, small inexpensive USB flash drives tend to work best for booting purposes.

To enable the rescue firmware functionality contained in the second GRUB menu entry, one must first copy the rescue firmware from the NAND flash partition using SSH.

To determine which NAND flash partition contains the rescue firmware, execute the following command.

# blkid -o list

Look for the device with an entry labeled wdnas_rescue_fw and note the device path. The path is /dev/mmcblk0p5 for the PR4100 NAS.

Next, create a folder named rescue_firmware on the Public share and copy the contents of the rescue firmware partition by executing the following commands, one at a time.

# mkdir /tmp/rescue_firmware
# mkdir /shares/Public/rescue_firmware
# mount -t ext4 /dev/mmcblk0p5 /tmp/rescue_firmware
# cp -Rf /tmp/rescue_firmware/* /shares/Public/rescue_firmware
# umount /tmp/rescue_firmware
# cd /shares/Public/rescue_firmware
# ls -l

Close the SSH connection, and browse to the Public share using the local network. Copy the rescue_firmware folder to the local computer and rename the uImage and uRamdisk files as follows.

  uImage --> uImage-rescue
uRamdisk --> uRamdisk-rescue

Copy the uImage-rescue and uRamdisk-rescue files to the root of the USB sitck, then shut down the NAS and insert the USB stick into one of its USB ports. Power on the NAS and it should now boot from the USB stick.

To verify that the rescue firmware is booting properly, remove or rename the uImage and uRamdisk files, which will cause the GRUB bootloader to default to loading the rescue firmware (uImage-rescue and uRamdisk-rescue) from the USB stick. After the NAS has finished booting, simply enter its IP address in a browser, which should then display a “Safe Mode” prompt. Note: The firmware is not corrupted as the “Safe Mode” message indicates, it’s programmed to say that.

To return the NAS to normal operation, simply hold the power button until it shuts down, then remove the USB stick and press the power button again.

To view the boot process from the serial console, please refer to the instructions contained in the following thread.


USB Rescue Firmware Procedure
[GUIDE] How to Build Custom Firmware
[WARNING] Custom Firmware Build
My Cloud PR4100 / PR2100 Firmware Analysis
Is it possible boot a DL4100 from a USB stick in view to recovering a bricked DL4100 NAS?
Totally bricked PR4100 - drive LEDs blinking red?
#2

This guide will be quite helpful to other Users in need. Thanks for sharing it.


#3

I installed OMV (debian based) with a flash drive onto another flash drive.
The OMV grub bootloader is located in the /boot/grub directory instead /grub

I could modify the WD NAS grub to pick the OS on the USB drive, but maybe it’s better to create a symlink at /grub to /boot/grub. Any other tips before I go ahead?


#4

Last night I loaded GRML, a debian based live system on my PR4100.
A live system lives in RAM memory so it doesn’t touch the WD flash firmware and doesn’t void your warranty.
You get a recent kernel, the apt package manager and a lot of handy tools, but the cooling fan whirling at full speed… I’ll see what I can do about that.

Get a pendrive of at least 512MB.
Find the device name of the pendrive. I’ll use /dev/sdX in this tutorial.

df

Format the pendrive and create a partition with a FAT32 filesystem.

sudo parted /dev/sdX

print mklabel msdos mkpart primary fat32 1M 100% set 1 BOOT ON quit

Change the partition label.

sudo fatlabel /dev/sdX USB_RESCUE

Download the grml64 iso of your choice. I chose the recent GRML prerelease.
Get grml2usb to install the iso.

sudo apt-get install grml2usb

As we can only do a headless install, we’ll add the SSH boot option with a password of your choice.
Install grml to the first partition of /dev/sdX as follows

sudo grml2usb --bootoptions='hostname=wdnas ssh=p1ck4s3cr3t' grml64-small-XXX.iso /dev/sdX1

Unmount and plug the pendrive in the NAS, then boot the NAS.
You can ssh into your box with your password, p1ck4s3cr3t in this case…

ssh root@wdnas

The full grml64 live ISO used only 500MB RAM of the 4GB present in the PR4100…


#5

Another great Guide.
I haven’t tried it yet since I have couple of questions.
I understand it’s for testing, diagnosis, and recovery purposes. But I’m thinking to modify the firmware for my needs and boot the modified firmware from USB.

  1. Can we persistently boot from USB? (possibly from SSD)
  2. Will there be any performance issues?
  3. For regular boot (without rescue), are uLmage and uRamdisk files sufficient?
  4. In which circumstances NAS can be bricked?

Best,


#6

The NAS will always boot from a properly configured bootable USB flash drive, but I believe it favors a bootable hard drive installed in one of the drive bays. Normally, the hard drives are not bootable unless an OS is installed, as is the case with my Debian installation guide. I don’t know if booting from an SSD drive is possible.

As I recall, uImage and uRamdisk are sufficient to boot into a very basic shell. However, it has been a while since I tested it so I will need to confirm this.

There are no performance issues that I am aware of. In fact, customized firmware can increase performance. With regard to custom firmware, I have made major progress and intend to post a guide very soon, perhaps within the next week.

Bricking is always a risk, but having a properly prepared USB rescue flash drive virtually eliminates most of the risk, as long as no changes are made to BIOS via console access.


#7

Well, the rescue firmware didn’t work (On the NAS led screen, it was saying “Firmware update failure”), but uImage, uRamdisk worked
I successfully boot from USB, changed the corrupted firmware, and now NAS works normal.

As you pointed out, USB boot can be used to test custom firmware to make sure it’s booting as expected.

Best,


#8

The rescue firmware has been extensively tested and it works. It is not an automated process, it merely allows one to upload new firmware via the browser. Did you use the NAS IP address?


#9

There was no internet connection. It was saying “Firmware update failed” on the led screen. Have you seen anything like that?

Current USB boot allows to update the kernel, and root level settings, but there are also WD config and modules, which are mounted from /dev/mmcblk0pX.
Have you figured it out how to by-pass those mounts so that config and other changes are possible without touching the original firmware?

I know you have a guide to update config.xml, but that may result to a brick nas.

Best


#10

Ignore the LED screen, it’s often not fully functional when booting from USB. And when booting the rescue firmware via USB, it may very well say firmware update failed, but only because no new firmware was loaded. It’s programmed to say that, and was never intended to be used for testing via USB.

If the NAS gets an IP address and you can see the rescue firmware page in the browser, it loaded successfully. If necessary, new firmware may be loaded from the rescue firmware web page, but uploading new firmware is not required if one is just booting it from USB as a test.

When booting the kernel and initramfs alone via USB, there will be no access through the browser. Only a serial console connection will allow you to see the boot process, unless you have configured it to boot with SSH, etc. In fact, it won’t do much at all with just a kernel and initramfs.

I have learned how to do almost anything I want to the NAS. I’ve compiled and ran custom firmware, standalone kernels, you name it. However, doing it myself and showing others how to do it are vastly different propositions. I am preparing a guide, but it will not be for your average user to tinker with. Building firmware is very complex, and many things can go wrong… often with no warning. Come to think of it, I temporarily bricked my NAS this morning when a custom kernel failed to load properly, but I had it back up and running in minutes using a custom USB rescue stick.

Any change you make can brick the NAS, sometimes they even brick themselves, it’s just the nature of the beast. The warning is there to make it clear to people that they should be careful, and so they can’t blame me if things go wrong.


#11

#This one need the mount from util-linux, busybox’s one can’t handle LABEL
#echo “initramfs: mounting label=image.cfs partition”
#mount -t ext4 LABEL=image.cfs /usr/local/tmp
chk_image

Here is the code from GPL firmware, ramdisk/root/etc/rc.sh.
They commented out mount commands, but similar mounting has been done in “chk_image”.
Have you tried mounting image.cfs from above commented code blocks? I think if it’s succefully, image.cfs can be mounted from USB Stick - just pointing to a USB partition or file inside the USB.


#12

The image.cfs file can be easily mounted by executing the following commands. One temp directory is made to mount the wdnas_image.cfs (/dev/mmcblk0p4) partition in the eMMC flash memory, and another temp directory is created to mount the actual image.cfs file, which contains a Squashfs filesystem with a 2048 byte header. The offset switch tells the mount command to skip past the header when reading the image.cfs file.

# mkdir /mnt/image_mount
# mkdir /mnt/image_root
# mount -t ext4 LABEL=wdnas_image.cfs /mnt/image_mount
# mount -t squashfs -o loop,offset=2048 /mnt/image_mount/image.cfs /mnt/image_root

Both temp directories must remain mounted while the image.cfs file is in use. For example, the following command will return a “busy” error.

# umount /mnt/image_mount

To unmount the image.cfs file, execute the following commands.

# umount /mnt/image_root
# umount /mnt/image_mount

If the image.cfs file is located on a USB flash drive, simply change the path.

# mount -t squashfs -o loop,offset=2048 /dev/sdb1/image.cfs /mnt/image_root

#13

Hello there!
My PR2100 is not booting anymore - i dont know why acctually.
Maybe someone can help me here…

When i got the NAS i installed Debian on a 16GB USB Stick, then i’ve been in holiday two weeks.

when i came back the device didnt stared anymore correctly and it is not (!) booting from the installing USB Stick anymore, neither from the debian usb Stick (from the guide thread here), nor from any other USB Stick (i tried the rescue stick, a freenas stick and a grml stick)

i already tried to boot in the normal wd OS, making the 5s and 40s reset…

in every case the NAS is not getting an IP Adress and i cannot ping it or access via SSH

EDIT:
OK, i just soldered a wire to the UART Port and connected it to my pc, over screen i came to the bios and was able to set my booting device to the USB Stick. The second option was some unknown device (i just connected the usb stick)…

could maybe someone upload the images of the original boot partition or can i find this online?