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.

80 thoughts on “Booting Pogoplug From The Correct USB Disk”

    1. 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.

      Like

    1. 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.

      Like

  1. 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.

    Like

    1. 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.

      Like

    1. I suggest looking into the uboot environment (/usr/sbin/fw_printenv) to see if read only “ro” is passed to the kernel command line.

      Like

      1. 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.

        Like

      2. 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?

        Like

  2. 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 ?

    Like

  3. 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…

    Like

    1. 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

      Like

  4. 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 0x00000000 -e 0x00000000 -n initramfs -d /boot/kernel.img /boot/uInitrd

    Like

    1. 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.

      Like

      1. 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.

        Like

  5. 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?

    Like

  6. 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?

    Like

    1. 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.

      Like

      1. 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?

        Like

    2. 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.

      Like

      1. 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.

        Like

      2. 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!

        Like

  7. 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

    Like

    1. 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.

      Like

      1. 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: 0x00000000

        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: 0x00028375

        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

        Like

  8. 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..

    Like

    1. 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: https://extremepogoplug.wordpress.com/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 🙂

      Like

  9. 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

    Like

      1. Hmpf… doesn’t help.

        I don’t understand the problem. I’ve found a hint that there is a config file for the fw_printenv tool.

        Like

  10. 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:)

    Like

    1. 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.

      Like

      1. 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:)

        Like

      2. 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.

        Like

      3. 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.

        Like

      4. 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”.

        Like

      5. 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 🙂

        Like

    2. So I started following the instructions to update uboot. I set my ROOTFS label. Then I went to run the uboot install script it gave a huge warning that this was only for the listed devices…it did not list pogoplug v4. Does it cover V4 and just doesn’t list it? Or is there another installer for V4 that I need to use? I used the official uboot loader not the new uboot loader. So how should I tackle this one? I’m having the same issue with the environment var not being present. please help. Thanks.

      Like

      1. Unfortunately, V4 is not supported by jeff uboot. There is uboot updater on archlinuxarm.org for V4. But im not sure if the uboot parameters in this post will work with it.

        Like

      2. So then how do I get the V4 to recognize the correct boot order using the official uboot? Could you help me out with that?

        Like

      3. What’s the operating system you boot? Is it Arch Linux or something else? Does it boot successfully if this is the only usb flash? Please share as much info about the problem.

        Like

      4. Hi yes it’s arch Linux. I followed the instructions on archlinux.org. The official install instructions.

        Like

      5. Well, if you followed the instructions then you should have updated uboot. It a modified version of the official uboot. I remeber that it supports booting from the USB port on the top side (below the cap), And the USB ports on the rear cant boot from. So how you face a problem with incorrect boot device if the only bootable is the top usb? Please explain the problem.

        Like

      6. Hi yes it’s arch Linux. I followed the instructions on archlinux.org. The official install instructions.
        It boots normal with only the Linux USB drive plugged in. I can mount other drives as well. It’s when it reboots is when things hang. If there is another drive plugged in, it will not boot into the OS. I’m assuming because uboot and the kernel don’t talk to each other about where the OS is located. Hope this helps. It’s about as cut and dry as that. I’m convinced it just needs to be labeled and both the uboot and Linux need to know that label. the problem is I’m running into the same thing the original poster of Thai sub comment is. The print system env line isn’t being found. The variable doesn’t exist. Through my reading I’ve found that uboot needs to be updated but you said the update doesn’t apply to the V4. So I’m trying figure out how to get the Linux drive label to be recognized by both uboot and Linux. Make sense?

        Like

      7. Hi yes it’s arch Linux. I followed the instructions on archlinux.org. The official install instructions.
        It boots normal with only the Linux USB drive plugged in. I can mount other drives as well. It’s when it reboots is when things hang. If there is another drive plugged in, it will not boot into the OS. I’m assuming because uboot and the kernel don’t talk to each other about where the OS is located. Hope this helps. It’s about as cut and dry as that. I’m convinced it just needs to be labeled and both the uboot and Linux need to know that label. the problem is I’m running into the same thing the original poster of this sub comment is. The print system env line isn’t being found. The variable doesn’t exist. Through my reading I’ve found that uboot needs to be updated but you said the update doesn’t apply to the V4. So I’m trying figure out how to get the Linux drive label to be recognized by both uboot and Linux. Make sense?

        Like

    1. Unfortunately I have not tried TonidaPlug. But the idea holds the same for any Linux plug. It’s just needed to figure out how to implement each step on the specific plug.

      Like

  11. Ok, I follow your logic about the back USB ports not being bootable. The situation still stands when I only have the Linux drive in the top, it boots fine. When I add another usb to the rear, it won’t boot. Rather, I can’t access it. It looks like it goes through a very shortened boot process. The LED blinks green then goes to solid green, but in a much shorter amount of time than if there is only the Linux drive. That’s all I have. I can’t access it enough to give you more detail. The drive I plugged in was created from the Linux install. So it is able to read/write to it fine and the drive doesn’t cause any problems, until I reboot.

    Like

      1. Thanks! Sorry for the messed up comment structure. My phone did something weird when replying that last time.

        Like

      2. I’ve reviewed the installation script of pogoplug v4:
        http://archlinuxarm.org/os/ppv4/ppv4-install.sh

        it installs new version of uboot, and change uboot environment variables.

        it uses the standard command that comes with the original firmware:
        /usr/local/cloudengines/bin/blparam

        it seems our target line is:
        /usr/local/cloudengines/bin/blparam alarm_args=’setenv bootargs console=ttyS0,115200 root=$device rootwait rootfstype=ext3′ > /dev/null

        I think if we change “root=$device” to “root=LABEL=ROOTFS”, we will have the desired effect

        so the full command should look like:
        /usr/local/cloudengines/bin/blparam alarm_args=’setenv bootargs console=ttyS0,115200 root=LABEL=ROOTFS rootwait rootfstype=ext3′ > /dev/null

        by the way, the command above needs to be run from the original firmware (i.e. remove flash disk and reboot into the original firmware before running it)

        The rest of the steps (step 1 & 3) in the article should hold the same.

        hope that helps.

        Like

      3. Thanks:) Is there a way to revert to the original pogoplug firmware after following Jeff’s uboot instructions? I know with the official install you can use the “revert” method. Does it boot to the original when no drives are attached?

        Like

      4. U r welcome 🙂 Yes simply remove Arch Linux USB and it will reboot to orig firmware. Thats what i see from uboot parameters of the V4 install script.

        Like

      5. But I guess in order to perform the 3rd step of your tutorial I will have to create initial ramdisk image first inside archlinux, copy those files and then reinstall/revert back to original pogoplugOS, paste the files back into new /boot folder during installation?

        Like

  12. The way I got it working on my Pogoplug E02 (Pink) was by doing steps (1) Distinct Label & (3) Update the Linux Kernel in ALARM Linux (booted via the USB stick). After that I /sbin/poweroff the Pogoplug and re-plugged it in without the USB, landing me in uBoot, where I performed Step (2) Modify uBoot Environment Parameters.

    After this I rebooted back with the USB attached in to ALARM linux, and everything seems to work fine now.

    Like

  13. I have a working Pogo and loving it. At this point just want to plugin a second USB drive after box has booted into arch. Not worried about power going off and rebooting, on UPS and no biggie if does not reboot without my help.

    Issue is the second drive never shows up? It is a NTFS formatted drive.

    Is there any extra steps I am missing to get drive to show on network?

    Thanks in advance for your input.

    Like

    1. Please try to do manual mount and see if it works. I’m not sure if NTFS driver is installed by default with Arch. If not, you can install it with package manager.

      Like

      1. Ok, thanks mhassan.

        Will explore options. Was not sure if should work by simple plugin after reading your info.

        Appreciate the input.

        Like

  14. I have a pogoplug E02 black with Fedora18 and Redsleeve 7.1 (which was built from the F18 kernel, so let’s keep this to a F18 problem). This setup was done by following:

    https://fedoraproject.org/wiki/Architectures/ARM/PogoplugUSBDisk

    I have a serial console per:

    http://blog.qnology.com/2013/10/pogoplug-e02-v2-serial-connection.html

    And of course, I cannot boot with a 2nd USB HD attached. 😦

    I have tried all different orders of where the boot USB drive and the big 3TB drive is. If only the boot drive is in the back, (any of the three ports), it boots fine and THEN I can attach the USB HD and proceed. Not acceptable, even with the pogo on my UPS.

    Since I have different env setup per the F18 instructions, I don’t know how to apply what is said here for ALARM os. I would be happy to send someone my printenv output if that would help making the boot deterministic.

    BTW, with Redsleeve 7, we have built sernet 4.2 and this will be my sernet backup fileserver.

    Thanks

    Like

  15. Hi,
    My Pogoplug v4 won’t boot if the HDD is attached to one of the back USB3 ports. I tried your solution few times. Still, it doesn’t work. Any other suggestion?
    Thank you!

    Like

      1. It shouldn’t be… I have a USB stick plugged on top. Now, if it boots w/o the HDD plugged in, it’s fine (then, I have to mount the HDD by hand). If I have the HDD plugged in at boot time, it won’t boot, plus the HDD keep spinning forever. I added a second entry into fstab to mount the HDD automatically. My fstab looks like this:
        LABEL=ROOTFS / ext3 rw,noatime 0 1
        UUID=dd2d60e7-55ca-475c-b025-7af6c2648313 /srv/nfs4/z ext3 defaults,nofail 0 2

        10x alot

        Like

      2. Hi Radu,

        thanks for your feedback. in that case, I agree with you that the booting issue could be due to the order of recognising disks by the linux kernel. I wrote the above article for pogoplug v2, but your pogoplug is v4, and the uboot used is not the same. Please refer to my other comment below that details my trial to map the solution to v4.

        https://extremepogoplug.wordpress.com/2012/06/27/booting-pogoplug-from-the-right-usb-disk/#comment-80

        Let me know if it works for your.

        Like

Leave a comment