> Limiting the number of password attempts per ssh logon to 2 (i.e. allow for 1 human typo) rather > than 5 would also be helpful, if anyone knows where this should best be set. It's set in /etc/ssh/sshd_config: "MaxAuthTries 2"by restamp - Debian
Setting the correct date is certainly a complicated process in these little ARM boxes without a RTC. Yes, the SNTP in uBoot will prevent you from seeing all those 1969 timestamps on files that get written or created on each boot, but will it result in an accurate time after reboot? My short experimentation with it seems to show that it won't. What happens is that the SNTP module will feby restamp - Debian
Thanks, bodhi, we ought to double your salary!by restamp - uBoot
I still believe there is something not right about the fsload command in the 2014.07 uBoot for the Pogoplug E02. None of the fs commands that access the flash work -- they all put the uBoot into an infinite loop printing "get_fl_mem: unknown device type, using raw offset!" that I've only been able to remedy by power cycling the device. The fsinfo command does the same thing, althby restamp - uBoot
bodhi Wrote: ------------------------------------------------------- > nicco, > > Your Arch rootfs must have been corrupted by the > power outage. Take it to another Linux box and: > > 1. run fsck to repair the filesystem errors (if > the stick is mounted as /media/sdb1) > > e2fsck /media/sdb1 > sync > sync > I agree with your assessment of thby restamp - Rescue System
> Have you tried to mount it in Debian? Yes, it is mountable: root@debian:~# modprobe mtdblock root@debian:~# mount /dev/mtdblock2 /mnt -t jffs2 -r [ 284.354435] jffs2: Empty flash at 0x009ac208 ends at 0x009ac800 [ 284.769108] jffs2: notice: (1466) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan)by restamp - uBoot
A couple days ago, bodhi and I exchanged some brief comments on how to boot to the PogoPlug E02 internal NAND OS from the 2014.07 version of uBoot. I could not see any reason to ever need to do this, but out of curiosity I experimented with it this afternoon. The original uBoot (version 1.1.4 from 2009) was on the NAND filesystem under the name uboot-original-mtd0.kwb. I believe it was put theby restamp - uBoot
One of the concerns I had when I converted from my power-hungry-but-bulletproof Sparc servers to these small Arm boxes was how reliable the hardware would be over time. Here's my personal experience with these devices to date. SheevaPlug - The first Arm device I acquired was a SheevaPlug. I put it in service in the fall of 2009. The power supply lasted about a year, but this was a wellby restamp - Off-Topic
Yep, that resolved the problem. I did go looking around for a module, but couldn't find one in the wheezy kernel ("lsmod | grep mtd") either, and gave up. FWIW, the only time I use these mtd block devices is when I'm mounting the NAND root file system, which is rare. So, as long as I know what module name I need to modprobe beforehand to make it work, it's not a probleby restamp - uBoot
> > why the /dev/mtdblock devices are missing in > > the Jesse load with the 3.18.5 kernel? > > No they are not missing. I think if you check your > kernel bootargs for mtdparts again, if it is > there, it should show up in the kernel under /dev. > Does the mtdparts in the cmdline show something > like this? > > cat /proc/cmdline > > ....by restamp - uBoot
Thanks for the help, bodhi. You hit the nail squarely on the head with respect to my LED issue: Not paying close enough attention resulted in my blindly using the wrong DTB. But, without you pointing me in this direction, it would have taken me quite a while to figure that one out. BTW, are there any disadvantages to appending the DTB so that it is a part of the uImage and booting it the conveby restamp - uBoot
I had a free afternoon, so thought I would play with installing Jesse and the latest bodhi uboot (2014.07-tld-2) on one of my test PogoPlug E02 boxes. Currently, my Pogoplugs are all running Wheezy with the standard 3.2 kernel and a 2011.12 version of uboot, and although I have no immediate plans to upgrade, I can see that Wheezy will realistically have to be upgraded to Jesse in the next yby restamp - uBoot
bodhi Wrote: > The rPi is good in that it is cheap, powerful for > the price, and has large community supports. > However, the drawback is it lacks true Gbit > Ethernet (everything goes through the USB bus). So > if Gigabit NAS is important, then other boxes are > better (such as ODROID C1). Thanks, bodhi. Good to know. This probably wouldn't be a problem for meby restamp - Off-Topic
LeggoMyEggo Wrote: ------------------------------------------------------- > restamp Wrote: > -------------------------------------------------- > > kludged-together answering machine (using a > >voice modem) for my landline. > > It would be interesting to hear how you did that. > Is it acting as a quasi FXO device? This may turn into a long story. Someby restamp - Off-Topic
I currently have three ARM-based PCs running 24/7 here: Two are PogoPlug E02s and the third is a SheevaPlug. The SheevaPlug runs an ancient version of Ubuntu and is dedicated to spooling over-the-air TV programming to a hard drive for later viewing. Before my last major power failure, it had been up and running around 550 days without a reboot. The two PogoPlugs run Debian Wheezy and areby restamp - Off-Topic
Yes, but since Mark succeeded in putting in what he put in, what did it actually do? I would think it would create an entry "bootcmd=usb" with a value of "start" (and then give some error messages about "usb: not found", etc, from the shell when you execute the fw_setenv command). But how would this new variable be interpreted by the uBoot? Would it parse it as &qby restamp - Debian
DonCharisma Wrote: ------------------------------------------------------- > @restamp, I count 11 modes in the current version, > probably you didn't look at the attached file ... > a conflictory argument is sometimes helpful, you > seem to know something about this, so thanks for > sharing your thoughts ... however if your > experiences stem from several years ago,by restamp - Debian
To answer your (probably rehtorical) question, well, no, I gave up early on trying to integrate the the ARM processor's hardware crypto engine into a general package like openssl. The crypto engine only implements one or two cipher/modes which are considered "strong" by today's standards, so it would not be usable for a large portion of what openssl supports anyway. Thereby restamp - Debian
Hi Don, I also have a passing interest in cryptography and looked at the hardware crypto engine in the ARM processors some time back. I think the prevailing notion a few years ago was that unless you had a dedicated use for it, the crypto engine was not efficient because you had to queue up for its use if you had multiple users. I interpret your data a bit differently than you do, although Iby restamp - Debian
bodhi Wrote: ------------------------------------------------------- > As I mentioned, netconsole sometimes mysteriously > not working for some people. One thing I noticed that definitely breaks netconsole, at least when using a Debian-type OS (Ubuntu, Mint...) as the netconsole host, is setting up a secondary IP address for this purpose. I thought I'd be smart and assign an oby restamp - uBoot
Running a php caching package like XCache will help, but Owncloud on an E02 is still pretty pokey. Whether or not it is usable is, I suppose, something you'd have to decide for yourself.by restamp - Debian
bodhi Wrote: ------------------------------------------------------- > The L2 cache is re-enabled by the kernel during > boot, we can see this in dmesg: > > root@tldDebian:~# dmesg | grep -i l2 > [ 16.769392] Feroceon L2: Enabling L2 > [ 16.769431] Feroceon L2: Cache support > initialised. > So it is. Thanks, bodhi!by restamp - Debian
FWIW, a couple datapoints: I just compared my Pogoplug E02 running Wheezy to a SheevaPlug running Ubuntu 9.04 booted from a very old uBoot -- certainly one that predates the L2-disable trick. These two boxes have the same processors and the reported BogoMIPS are virtually identical: 1192. Furthermore, a difficult factoring problem was handled in roughly the same amount of time on each, leadinby restamp - Debian
The disabling of the L2 cache in modern uBoots was purposefully done -- I think it started with U-Boot 2011.12 (Feb 20 2012) with Wheezy -- because, for some reason I can't explain, it allowed the 3.2-and-beyond kernels to be successfully uncompressed and dispatched to. With L2 cache enabled, I think these kernels could not be used, as they employed a different compression method which woulby restamp - Debian
My Pogoplug E2s have been similarly robust, although I've upgraded them to Wheezy and keep them up-to-date with patches, so they don't have long run-times on them. I have a SheevaPlug that has sat in the corner untouched, spooling TV shows to disk for me for the past 5 years and, except for its power supply which was notorious on these devices, it has been reliable. Current run time:by restamp - Debian
Well, the ides of May has come and gone, and my Google Voice line continues to work fine with Asterisk. So, what's going on? Has Google simple not gotten around to disabling XMPP yet? Has the OBI crowd or anyone else lost access? I keep reading stories on the net referring to Google Voice XMPP in the past tense, but is that a reality to some folks or simply a presumed expectation?by restamp - Debian
Bodhi, I agree, and it's even more problematic if you run servers on the internet, as I do. I don't actually have anything of value sitting behind Apache TLS here -- I do run https on one server, but it's really only to experiment with. However, https seems to be the service everyone is interested in. I'm personally more concerned as to whether I need to regenerate my sendmby restamp - Debian
Thanks, bodhi. The addition of the security repository pulled in a number of (probably much overdue) updates. I'm not sure where I got the singular line in my sources.list. I think it was what was recommended when upgrading from Squeeze to Wheezy. In any event, I'm slowly learning something about an area of Debian that I was not very familiar with. As a experiment, on my test serby restamp - Debian
OK, after a bit of investigation, I changed my /etc/apt/sources.list from: deb http://ftp.us.debian.org/debian wheezy main to deb http://http.debian.net/debian wheezy main deb-src http://http.debian.net/debian wheezy main deb http://http.debian.net/debian wheezy-updates main deb-src http://http.debian.net/debian wheezy-updates main deb http://security.debian.org/ wheezy/updates main deby restamp - Debian