Booting Pogoplug From The Correct USB Disk

Booting Arch Linux ARM (ALARM) on Pogoplug V2 is straightforward, as long as we have only attached the USB drive/stick where ALARM is installed. But if we have any additional USB drives attached to Pogoplug, we face troubles booting ALARM.

An easy workaround is to detach any USB drives but the ALARM USB until booting, then attaching other USB drives. But that means that Pogoplug can’t boot automatically if there is a power outage or something, until we manually do this workaround.

The problem happens because uBoot (the boot loader) may identify the attached USB drives in a different order than the linux kernel may do. Let’s give an example for such scenario:

  1. Say we have attached two USB drives, one has ALARM, and the other is just a storage drive.
  2. During the boot process, uBoot may identify the storage drive as the first USB drive (/dev/sda), and the ALARM drive as second USB drive (/dev/sdb).
  3. uBoot finds the kernel (/boot/uImage) on the first partition of the ALARM drive (/dev/sdb1). So it passes (/dev/sdb1) to the kernel as the root filesystem.
  4. The kernel may have detected the ALARM drive as the first USB drive (/dev/sda), while it expects the root filesystem on /dev/sdb1, which is the storage drive not the ALARM drive!

If the kernel detects the attached USB disks in the same order as uBoot, there will be no problem. But most of the time the order is different, and the boot process fails when more than one USB drive is attached.

For a stable and expected boot process, we need some other way to identify disks, rather than the generic dynamic (/dev/sdx) notation.

The technique is explained in the following thread, which is about Debian, but the concept can apply to any linux kernel:
http://forum.doozan.com/read.php?2,5233,5957

We can summarize the technique in the following steps:

  1. Give a distinct label to the partition containing the root filesystem.
  2. Modify the uBoot environment parameters to pass that label to the linux kernel.
  3. The linux kernel searches through all detected partitioned until it find the one with the correct label, which then mounts as the root filesystem and continue the booting process.

Let’s address the steps one by one, and make the necessary configurations to implement each of them.

 1- Give Distinct Label to The Partition Containing Root Filesystem

To avoid any confusion, let’s boot Pogoplug with only the ALARM USB attached. When booting completes, we SSH to ALARM as root user and run the following command, which sets the label of the first partition (root filesystem) to ROOTFS:

[root@alarm ~]# e2label /dev/sda1 ROOTFS

2- Modify uBoot Environment Parameters to Pass ROOTFS Label to The Kernel

Given that we haven’t modifies the default uBoot environment parameters, we just need to make a minor change. First we check usb_init parameter which should read as below:

[root@alarm ~]# /usr/sbin/fw_printenv usb_init
usb_init=run usb_scan

We run the following command to modify the usb_init parameter to pass the ROOTFS label after completing the USB scan:

[root@alarm ~]# /usr/sbin/fw_setenv usb_init "run usb_scan; setenv usb_root LABEL=ROOTFS"

3- The Linux Kernel to Search For the ROOTFS Partition

For the Linux Kernel to be able to search through the attached USB drives, and to find the partition with the label specified, the Linux Kernel has to mount a temporary root filesystem, which has the necessary drivers the kernel needs to be able to identify disk labels. Such initial temporary root filesystem is called the Initial Ram Disk, which is a compressed ram image file (called uInitrd), that’s uncompressed and loaded into memory during the boot process by uBoot.

By default, ALARM has no initial ramdisk file, and hence we need to create it for this technique to work. I’ve found helpful steps for creating a ramdisk in the following thread:
http://archlinuxarm.org/forum/viewtopic.php?f=23&t=1248&p=7340&hilit=LABEL

In summary, we can simply create the initial ramdisk with the following commands:

[root@alarm etc]# mkinitcpio -v -g /boot/kernel.img
[root@alarm etc]# mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs -d /boot/kernel.img /boot/uInitrd

if “mkimage” utility is not installed, then you can install it using the following command:

[root@alarm etc]# pacman -Sy uboot-mkimage

Now after creating the initial ramdisk (uInitrd) file, the technique described in this post should word smoothly, and we can boot ALARM on Pogoplug regardless of any other connected USB drives.

54 thoughts on “Booting Pogoplug From The Correct USB Disk

  1. Pingback: Swapping between Pogoplug Original and Custom Firmware | Moustafa Hassan

    • do you mean you face troubles following the procedure?
      or you followed the procedure but still ALARM doesn’t boot?
      please give more details about the problem, and I will try to assist.

    • do you mean you face troubles following the procedure?
      or you followed the procedure but still ALARM doesn’t boot?
      please give more details about the problem, and I will try to assist.

  2. Thank you very much for this guide.
    It helped me a lot, but shouldn`t # initcpio -v -g /boot/kernel.img be # mkinitcpio -v -g /boot/kernel.img ?
    And i had to install uboot-mkimage via “yaourt -S uboot-mkimage” firs.

    • Thanks for your feedback.
      yes indeed, the correct command is mkinitcpio (not initcpio).
      uboot-mkimage should be installed first as you mentioned.
      it can be installed using “pacman -Sy uboot-mkimage”

      I will update the post considering both points.
      Thanks again.

      • It is not, but I believe I could pass rw. As of now, I simply added an entry to fstab and it remounts automatically rw. The guide did not work however; I can see that root=LABEL=ROOTFS is passed to the kernel but I still don’t boot successfully with certain configurations. Right now I simply rearranged my drives so that the one with ROOTFS happens to be queried first. I have yet to reconfigure and run netconsole to determine the cause of the malfunction.

      • Having to rearrange drives means that the procedure is not working for your for some reason. I’ve tested the procedure above on Pogoplug V2 using Jeff Doozan uboot, and Arch Linux ARM (ALARM). Are you using this same configuration?

  3. Hey ! Thanks for the guide…i was able to arrange it BUT since i´ve done it my system only boots in Read Only (RO) and Samba does not work any more…? Any Ideas ? What else can i do to get my system to work as it has done before ?

  4. i did also myself….for all having the same problem :
    edit /etc/fstab and add (please take care inserting the right device) :
    /dev/sda1 / ext3 defaults,noatime,rw 0 1

    reboot and have fun….
    Solved my problem…

    • Thanks for sharing your experience.
      I don’t know why it’s mounted read only. May you check the output of “dmesg” command to see what happeneded during booting.

      Anyway, if you have to put something in /etc/fstab, then please use labels instead of device paths, or things may stop functioning case of more device attached.

      E.g.

      LABEL=ROOTFS / ext3 defaults,noatime,rw 0 1

  5. I also had the read only issue. I added “rw” at the end of the “fw_setenv usb_init” command.

    Below is the exact commands I executed. Hope its the right fix.

    e2label /dev/sda1 ROOTFS
    fw_setenv usb_init “run usb_scan; setenv usb_root LABEL=ROOTFS rw”
    Pacman -Sy uboot-mkimage
    mkinitcpio -v -g /boot/kernel.img
    mkimage -A arm -O linux -T ramdisk -C gzip -a 0×00000000 -e 0×00000000 -n initramfs -d /boot/kernel.img /boot/uInitrd

  6. Pingback: How do I get my Pogoplug to boot from the same USB port every time?

    • Try to remove ALARM USB flash to reboot into original firmware. Then you can check uBoot env variables against the article and fix as necessary.

      • My pogoplug wont boot with ALARM flash drive after outage. I put uuid label for root in fstab. It booted once and it worked. Power outage again. Not working. I tried with usb drive and then without. Without usb drive, pogoplug(or uboot) through ssh asks for login/password, which both ceadmin and root/root and my personal login/pass didnt work. If i try with my ALARM usb drive, not able ssh in. So blocked at both instances from doing any editing whatsoever.

  7. Same problem as Steve. I had the read-only problem using the original environment settings, so I change my environment variable to “”run usb_scan; setenv usb_root LABEL=ROOTFS rw” as suggested by Qui Hong. Now, I’m unable to boot at all.

    I need to set the environment variable back to the default, but I can’t get boot into the original Pogoplug environment, presumably because I updated to the new bootloader.

    Can anybody suggest a way that I can get the fw_setenv variable reset?

  8. OK to follow up on my earlier post, I was able to boot into the original firmware and reset the usb_init variable and then I was able to boot into ALARM again. I’m still having the problem I had before though, which is that the root system boots up read only. Has anybody figured out a reliable way to get it use the root system label and also boot up with read/write?

    • You were on the right track with the rw switch appended after the label tag. Alternatively, you can explicitly declare the filesystem rw with an entry in fstab. Mine also seems to default to read only.

      • I’m not sure what the problem is. I definitely was not able to boot with rw appended to the U-boot variable. For now, I’ve just gone back to the default boot without the label, since it seems that something is not working well with the method outlined. I wonder if there’s another parameter that needs to be declared to ensure that rootfs will boot up with r/w permisssion?

    • How did you boot into the original firmware? Did you just remove the Flash Drive? I’ve tried that and I haven’t been able to SSH to the Pogoplug.

      How did you reset the usb_init variable?

      Also, can anyone lay out a simple description of the setup here? I don’t know what is running from the internal NAND and what is running from the USB drive.

      • yes you can boot into the original firmware by just removing the Flash.

        you can check uboot variables using:
        /usr/sbin/fw_printenv

        and you can edit a variable using:
        /usr/sbin/fw_setenv

        (both are used in the article above)

        The boot loader (uBoot) loads from NAND.
        It checks if there is a kernel on any attached USB drive.
        If so, it boots it (which is run from USB)
        if not, it loads the original firmware from NAND.

      • Okay, well, perhaps I wasn’t waiting long enough. I plug it in before it went to bed and in the morning SSH was working just like you said. Thank goodness!

  9. Adding a entry to mount the ROOTFS in /etc/fstab will resolve the Read-Only issue.

    e2label /dev/sda1 ROOTFS
    echo “LABEL=ROOTFS / ext3 rw,noatime 0 1″ >> /etc/fstab

    • the uBoot update script (http://jeff.doozan.com/debian/uboot/install_uboot_mtd0.sh) asks during installation whether to disable pogoplug service, and the default answer is y

      Would you like to disable the pogoplug services? [Y/n]

      You can turn it back on by the following steps:
      1- Boot into original firmware
      2- Connect using ssh
      3- Edit “/etc/init.d/rcS” script, and remove the comment(#) in front of the line reading “/etc/init.d/hbmgr.sh start”

      after rebooting into original firmware again, pogoplug services will be available as before.

      • Ah Ha! It’s all starting to make sense. Thank you for your help. That is great, I’m back up and running. I was scared there for a minute.

        It will be nice to have the pogo features available.

        Unfortunately, it is still having problems booting when there is an additional USB disk plugged in. I followed the instructions and they went smoothly. I’ve checked the boot drive label “ROOTFS”. I’m trying to attach an NTFS disk, so I can’t apply an e2label that is something not “ROOTFS” to the additional drive. Would that affect the boot sequence? I can’t SSH when I “boot” with the NTFS disk plugged in.

        Thanks for helping a newbie. You are a hero.

        Helpful(?) output:
        [root@pogoplug ~]# fdisk -l

        Disk /dev/sda: 4127 MB, 4127195136 bytes, 8060928 sectors
        Units = sectors of 1 * 512 = 512 bytes
        Sector size (logical/physical): 512 bytes / 512 bytes
        I/O size (minimum/optimal): 512 bytes / 512 bytes
        Disk label type: dos
        Disk identifier: 0×00000000

        Device Boot Start End Blocks Id System
        /dev/sda1 63 8048564 4024251 83 Linux

        Disk /dev/sdb: 3000.6 GB, 3000558944256 bytes, 732558336 sectors
        Units = sectors of 1 * 4096 = 4096 bytes
        Sector size (logical/physical): 4096 bytes / 4096 bytes
        I/O size (minimum/optimal): 4096 bytes / 4096 bytes
        Disk label type: dos
        Disk identifier: 0×00028375

        Device Boot Start End Blocks Id System
        /dev/sdb1 256 732558335 2930232320 7 HPFS/NTFS/exFAT
        [root@pogoplug ~]# e2label /dev/sda1
        ROOTFS
        [root@pogoplug ~]# e2label /dev/sdb1
        e2label: Bad magic number in super-block while trying to open /dev/sdb1
        Couldn’t find valid filesystem superblock.
        [root@pogoplug ~]# fw_printenv usb_init
        usb_init=run usb_scan; setenv usb_root LABEL=ROOTFS

  10. Tutorial Instructions
    +
    e2label /dev/sda1 ROOTFS
    echo “LABEL=ROOTFS / ext3 rw,noatime 0 1″ >> /etc/fstab
    = Flawless boot with 2+ drives.
    Thanks MHassan for the tutorial + Qui Hong(ty for your own tutorial too & help here as well).
    ——–>

    Thinking forward to when/if my USB drive fails I already have a duplicate/identical USB from backup img setup sitting under the Pogoplug in a plastic bag :P. With these changes it will only boot correctly with multiple drives from ROOTFS(usb scan will still work with the single file system plugged in)? What would your suggestion be here so that in a year or two it will be plug ‘n play?
    Thoughts :
    1)Label the backup drive ROOTFS2 and add as we did above?

    > e2label /dev/ ROOTFS2
    > /usr/sbin/fw_setenv usb_init “run usb_scan; setenv usb_root LABEL=ROOTFS”; setenv usb_root LABEL=ROOTFS2″
    >echo “LABEL=ROOTFS2 / ext3 rw,noatime 0 1″ >> /etc/fstab
    (echo the label=ROOTFS2 into /media/echo “LABEL=ROOTFS2 / ext3 rw,noatime 0 1″ >> /etc/fstab
    (echo the label=ROOTFS2 into /media/<backupdrivemountname/etc/fstab)

    2b) Or just unplug original ROOTFS. Boot off duplicate bkp drive and re-do ROOTFS label on drive(/etc/fstab should remain intact).

    3) Reimage the backup drive off of this current version as the /etc/fstab is properly setup for read-only issue

    PS: e2label is stored on the pogoplug correct? Is it based on UUID(which will result in issues for option 3 as ROOTFS will be uniquely linked to UUID of current drive)?

    Phew… Hope you're able to decipher that.
    Thanks again! Best $15 I spent..

    • Thanks for your feedback.

      I personally prefer option (2) which is to just unplug the faulty drive, set the label on the backup drive (using any linux machine), then boot pogoplug off it.

      That’s the exact way I used to recover from my faulty flash disk.

      btw, I don’t use disk image, I just backup using rsync as described in this post: http://mhassan.me/2012/06/30/backing-up-arch-linux-arm-alarm-on-pogoplug/

      As for your question about where ROOTFS label is stored …
      it’s actually stored on the disk itself.
      we just set the parameter on pogoplug boot (fw_setenv) to have it passed to the linux kernel during boot, so that Linux can identify the correct desk to boot from.

      As far as I know, label is not based on UUID. It is stored on the desk itself as part of the ext2/3/4 filesystem metadata.

      hope I haven’t missed any part of your questions :)

  11. Hello thanks for making this tutorial. I was able to complete all the steps with no errors but it no longer boots. I’m able to boot to stock pogoplug by removing the USB drive. I can also see the structure of the USB drive. Is there any way to fix this or would I need to start over. Unfortionately I didn’t create a back up. Before attempting this tutorial. Thanks in advance

  12. Thanks for the tutorial.

    Having bit of an issue. Here is what I get:

    [root@alarm ~]# e2label /dev/sda1 ROOTFS
    [root@alarm ~]# /usr/sbin/fw_printenv usb_init
    -bash: /usr/sbin/fw_printenv: No such file or directory
    [root@alarm ~]# usb_init=run usb_scan
    -bash: usb_scan: command not found

    If I understand correctly, I need to rerun uBoot.

    The uBoot update script (http://jeff.doozan.com/debian/uboot/install_uboot_mtd0.sh) asks something along the lines if want to repair/reset. Which option should I choose at this point?

    Spent hours setting all up and jsut hate the thought of starting over:)

    • Thanks for your feedback. Yes you just need to run the uboot update script same as you did before. It will install the tools (fw_printenv, fw_setenv), but it will detect that uboot is already updated and will not update it again. I don’t remember about the reset/repair option. Hope that helps.

      • Thanks for fast reply mhassan!

        To better rephrase the question:

        When I rerun uBoot and get to the Y/n, do I choose yes or no?

        As you can tell, really new to this but learning fast:)

          • Sorry. Should have done that for you.

            When I run and get to the step:

            ————————————–
            ## Valid uBoot detected: [pinkpogo davygravy-2012-02-20-current]
            ## The newest uBoot is already installed on mtd0.

            You are already running the latest uBoot.
            Your current uBoot environment should be reasonable. However, if you’re having
            any probems booting, you can reset the environment variables to know good values.
            Would you like to reset the uBoot environment? [N/y]

            ——————————————

            Not sure how to proceed.

          • We don’t need to reset the environment. So please answer with N. But I believe that at this point this script should have installed the tools ( eg fw_printenv). Please check if they really exist now. If not, let’s proceed with answer N and see.

          • Appears it was not installed, so proceeded again and got to the N/y. Answered no and here is results:

            Would you like to reset the uBoot environment? [N/y] N

            # uBoot installation has completed successfully.
            [root@alarm tmp]# cd ..
            [root@alarm /]# /usr/sbin/fw_printenv usb_init
            usb_init=run usb_scan
            [root@alarm /]# usb_init=run usb_scan
            -bash: usb_scan: command not found
            [root@alarm /]#

            Lost at this point with “-bash: usb_scan: command not found”.

          • I can see that fw_printenv already run successfully and printed the output. The next line in the tutorial is the output of the command preceding it, and shouldn’t be run as command :)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Current day month ye@r *