All right, I've added a note about the two different nc invocations. (Note that I'm running Ubuntu, by the way :-] I just have the "netcat-openbsd" package installed instead of "netcat-traditional". The latter is probably the more common one, in any event.) Quotebodhi I've intentionally avoided this in the instruction. uEnv.txt could be used to activate nby iSKUNK! - Rescue System
(Apologies for the delay; the day job kept me busy!) I've added information about the OpenWRT download. I agree, I'd glossed over that part. Regarding that nc invocation, however... $ nc -lup 6666 192.168.100.25 6666 usage: nc [-46CDdFhklNnrStUuvZz] [-I length] [-i interval] [-M ttl] [-m minttl] [-O length] [-P proxy_username] [-p source_port] [-q seconds] [-s source]by iSKUNK! - Rescue System
All right, here is my "director's cut" of the process of installing a new U-Boot and current (19.07.2) OpenWRT on a Pogoplug Mobile, complete with deleted scenes not present in the original release (seen above). I've confirmed these steps by running through them on a second Pogoplug device, so I'm pretty darn sure that this process will work for anyone who follows it to tby iSKUNK! - Rescue System
Okay, now I understand what's going on: OpenWRT has to be booted with the "mtdparts=..." option on the kernel command line in order to partition and write to the NAND correctly. I don't understand why the whole process worked the first time, when I didn't do this. But oh well, better this is caught now, rather than months/years later when some poor soul gets the errorby iSKUNK! - Rescue System
The point where I got the error was right as I was about to set the U-Boot variables for booting normally into OpenWRT (set_bootargs_owrt, bootcmd_owrt, bootcmd). Before that first-time boot of OpenWRT, this is what I did in the U-Boot session (first time the new U-Boot came up): setenv partition nand0,0 nand erase.part ubi tftpboot openwrt-19.07.2-kirkwood-cloudengines_pogoplugv4-initraby iSKUNK! - Rescue System
Note that the OpenWRT environment in question is the TFTP-loaded one, not the final one. Here is the U-Boot environment: Pogov4> printenv arcNumber=3960 bootcmd=run bootcmd_uenv; run scan_disk; run set_bootargs; run bootcmd_exec bootcmd_exec=if run load_uimage; then if run load_initrd; then if run load_dtb; then bootm $load_uimage_addr $load_initrd_addr $load_dtb_addr; else bootm $loaby iSKUNK! - Rescue System
Quotebodhi Could you make one new post that shows the whole thing. You can call it Part I and Part II, if you like. Happy to oblige! (And thank you for the kind words too, habibie!) However, there is a problem: I actually have a second identical Pogoplug device that I wish to upgrade in the same way. I've been putting together a new post that documents the whole process from start tby iSKUNK! - Rescue System
I'm happy to report that the OpenWRT installation was a success. Since this is all past the "one wrong move and you've got a brick" stage, I was able to work through it on my own, while eyeballing the two other relevant threads closely. Below is the transcript of what I did, also color-coded for clarity. Starting in netconsole: Pogov4> nand erase.part ubi NAND erase.by iSKUNK! - Rescue System
QuotebodhiAnd in this case, nc_ready is really transient because without a saveenv, nothing got written to NAND during the next boot. Ohh, okay. So "setenv" only changes a variable temporarily (in RAM) on its own; "saveenv" is needed to actually commit the new value(s) to NAND. So it's different from fw_setenv in that way. (After seeing the "printenv" listiby iSKUNK! - Rescue System
I added the bad-block check to my command list above. Here are the results of my session. I'll use color-coding, so that all this text doesn't run together. Comments are in light grey, commands I type in are in red, and command output is green. # Check that the first eight NAND blocks (1 MB) are good /tmp # dmesg | grep -i bad <6>[ 1.010000] Scanning device for bad blby iSKUNK! - Rescue System
Okay, I have revised (and clarified) my previous post as requested. Yes, I am starting with the stock Pogoplug OS, modified only as far as enabling SSH/telnet. Side note: I'm actually using telnet, because the Pogoplug's SSH server is only offering an insecure key-exchange algorithm that my client refuses: $ ssh root@192.168.100.15 Unable to negotiate with 192.168.100.15 port 22by iSKUNK! - Rescue System
Thanks for confirming. Yes, it struck me as odd that the V4-A1-01 supposedly didn't use the same software as the V4-A3-01, given the similarity of the two devices. Below is what I'm starting with, and the commands that I plan to run to install U-Boot (taken from the install thread and also the OpenWRT on Kirkwood boxes thread). Could you give them a final once-over, in case I got anyby iSKUNK! - Rescue System
So, if I'm eyeballing these other threads correctly, the command/value I should use is fw_setenv mtdparts 'mtdparts=orion_nand:0x200000@0x0(u-boot),-@0x200000(ubi)' ? (I don't see anything on "mtdid"; is that something I need to set, or just an internal thing?) Quoteopenwrt-19.07.2-kirkwood-cloudengines_pogoe02-initramfs-uImage is the OpenWrt image for Pogoby iSKUNK! - Rescue System
I agree that having correct information posted on matters like these is quite important! Is setting the "mtdparts" variable equivalent to repartitioning, then? (As in, is this variable basically a partition table?) The U-Boot install procedure mentions setting mtdparts and ethaddr after flashing (to restore their old values), but blparam did not give me anything for mtdparts. Willby iSKUNK! - Rescue System
Okay, so I take it that writing the environment to 0xC0000 on this device is still the correct action (that this is the appropriate location for the new U-Boot, even if it isn't so for the old one). I have used blparam to read the current environment, and saved a copy of that information. I recently found the thread HowTo: OpenWrt on Kirkwood boxes, which seems to come pretty close to whaby iSKUNK! - Rescue System
Ah, I see that Lede on Pogo E02 HowTo page. (The name is out-of-date; Lede was merged into OpenWRT a while ago and no longer exists as a distinct project.) Can't the entire process be done from the running Linux system? I don't believe the flashing tools are present in the original OS, but I can pull them down. Otherwise, it seems like the first step is to follow the standard instby iSKUNK! - Rescue System
This post is the final installation instruction: https://forum.doozan.com/read.php?4,100764,101409#msg-101409 ======= Hello, I have a Pogoplug Mobile device (POGO-V4-A1-01) with SSH and telnet access enabled. I would like to get rid of the original Pogoplug OS completely, and reflash the on-board memory with OpenWRT. However, I'd also like to have netconsole, and the abilityby iSKUNK! - Rescue System
okigan Wrote: ------------------------------------------------------- > The regex/top command in that line looked > suspicious to me as well I don't think it's the regex---although that could be tightened up a bit---so much as that the script is relying on the server to sort the various debootstrap packages in newest-to-oldest order via the "?C=M;O=D" (last-Modifieby iSKUNK! - Debian
Brainy142 Wrote: ------------------------------------------------------- > I tried the new script, but I am still stuck at > configuring intramfs, it tries to configue it 5 > times then fails, I tried the NSA320 rootfs on my > goflex home but it doesn't seem to work properly > and never ask's for an IP address meaning I cannot > administrate it. Any ideas? I havby iSKUNK! - Debian
chessplayer Wrote: ------------------------------------------------------- > thanks a lot. I have meanwhile been able to get > everything I need working with davygravy's Kernel > and what not, but it is always good to have > something running cleanly out of the box. Aye, I'm big on "clean," especially in terms of playing ball with the way a distribution expby iSKUNK! - Debian
I see the git repository has other scripts with similar code, so I've patched those up as well, and sent the pull request. On a related note: Would it be feasible for the site to provide a rootfs of the installed Wheezy system? I ask this because once I ran into the issue of the Pogoplug kernel not being able to chroot, what saved me was the Arch Linux ARM rootfs from this page. The foby iSKUNK! - Debian
I recently acquired a Pogoplug E02, and have been playing around with Jeff's Wheezy install script. I have a handful of changes to contribute; below is a walk-through of them: * Removed URL_FW_CONFIG definition, as it is not used (but see note below on /etc/fw_env.config) * Replaced dummy/transitional packages in EXTRA_PACKAGES with their successors: module-init-tools -> kmod, ubootby iSKUNK! - Debian