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:
- Say we have attached two USB drives, one has ALARM, and the other is just a storage drive.
- 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).
- 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.
- 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:
- Give a distinct label to the partition containing the root filesystem.
- Modify the uBoot environment parameters to pass that label to the linux kernel.
- 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.
Does not work ! tried it a couple of times !
LikeLike
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.
LikeLike
Does not work….tried it a couple of times !
LikeLike
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.
LikeLike
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.
LikeLike
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.
LikeLike
I’m trying this right now but ROOTFS is mounted read-only. I can remount of course, but what is the cause of this?
LikeLike
I suggest looking into the uboot environment (/usr/sbin/fw_printenv) to see if read only “ro” is passed to the kernel command line.
LikeLike
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.
LikeLike
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?
LikeLike
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 ?
LikeLike
I used “root=LABEL=ROOTFS rw” to solve this issue.
LikeLike
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…
LikeLike
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
LikeLike
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
LikeLike
Followed this guide and I can no longer ssh into my pogoplug. Guess it’s a new install for me again.
LikeLike
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.
LikeLike
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.
LikeLike
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?
LikeLike
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?
LikeLike
I suggest to check /etc/fstab for an entry for root filesystem that makes it read only.
LikeLike
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.
LikeLike
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?
LikeLike
As I noted, “””Alternatively, you can explicitly declare the filesystem rw with an entry in fstab”””
LikeLike
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.
LikeLike
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.
LikeLike
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!
LikeLike
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
LikeLike
Yes, that’s probably the best solution. I’ll do it that way.
LikeLike
People are saying just removing the Flash Drive will boot the Pogoplug as normal, I have not experienced that, the install instructions here http://archlinuxarm.org/platforms/armv5/pogoplug-v2-pinkgray say that won’t work, was there a different install process that kept both?
“my.pogoplug.com, the mobile applications, and the desktop Pogoplug connector will no longer work.”
LikeLike
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.
LikeLike
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
LikeLike
Your hdds are larger thant 2.2 TB, thus you need to use GPT (gdisk) not old MBR (fdisk) http://www.rodsbooks.com/gdisk/
https://wiki.archlinux.org/index.php/GUID_Partition_Table
https://github.com/archlinuxarm/PKGBUILDs/issues/368
http://archlinuxarm.org/forum/viewtopic.php?f=18&t=2611&start=30#p14953
http://archlinuxarm.org/forum/viewtopic.php?f=23&t=4967
LikeLike
I can’t find /usr/sbin/fw_printenv on my dockstar running the latest arch arm.
Any suggestions?
LikeLike
NVM I figured it out you have to rerun the uboot installer
LikeLike
Just to follow up, I got it working great with my media drive, thank you 🙂
LikeLike
thanks for your feedback 🙂
LikeLike
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..
LikeLike
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 🙂
LikeLike
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
LikeLike
First I suggest to review steps again and make sure each one is configured properly.
If this doesn’t help, I suggest using netconsole to see what happens during booting. Please check my other post https://extremepogoplug.wordpress.com/2013/08/30/configuring-netconsole-on-pogoplug-v2/
At least we will know if we reach the kernel startup.
LikeLike
/usr/sbin/fw_printenv
leads only to:
Cannot parse config file: Invalid argument
LikeLike
I’m not sure what is this.
but I suggest re-running uboot update script from jeff doozan web site (http://jeff.doozan.com/debian/uboot/)
so that it re-installs the fw_printenv utility in the ALARM environment.
LikeLike
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.
LikeLike
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:)
LikeLike
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.
LikeLike
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:)
LikeLike
No problem 🙂
Please post the full script question that we should answer Y or N
LikeLike
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.
LikeLike
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.
LikeLike
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”.
LikeLike
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 🙂
LikeLike
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.
LikeLike
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.
LikeLike
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?
LikeLike
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.
LikeLike
Hi yes it’s arch Linux. I followed the instructions on archlinux.org. The official install instructions.
LikeLike
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.
LikeLike
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?
LikeLike
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?
LikeLike
Any tips for running this on TonidoPlug v1? What are the correct offsets for the TonidoPlug v1 in /etc/fw_env.config?
LikeLike
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.
LikeLike
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.
LikeLike
Thanks for explanation. Let me study the whole situation again hoping to get any helpful advice.
LikeLike
Thanks! Sorry for the messed up comment structure. My phone did something weird when replying that last time.
LikeLike
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.
LikeLike
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?
LikeLike
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.
LikeLike
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?
LikeLike
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.
LikeLike
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.
LikeLike
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.
LikeLike
Ok, thanks mhassan.
Will explore options. Was not sure if should work by simple plugin after reading your info.
Appreciate the input.
LikeLike
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
LikeLike
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!
LikeLike
Is the HDD also the Arch Linux boot disk?
Because as far as I know, the uboot of pogoplug 4 only support booting from the usb 2.0 at the top, or the e-sata.
(ref: https://archlinuxarm.org/platforms/armv5/pogoplug-series-4)
Hope that helps.
LikeLike
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
LikeLike
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.
LikeLike