Re: Please rebuild robustbase and then fportfolio
Hi Hector, Thanks for the follow-up. On 23 February 2011 at 18:49, Hector Oron wrote: | Hi, | | 2011/2/22 Dirk Eddelbuettel : | | > Could someone please schedule a rebuild of robustbase on armel, followed by a | > rebuild of fportfolio on armel? | | That has been done. Very well, and I can see indeed see the robustbase build status on https://buildd.debian.org/build.cgi?pkg=robustbase Now, will fportfolio now attempt an auto-rebuild, or does someone need to schedule a WB for it? Dirk | | Thanks, | -- | Héctor Orón | | "Our Sun unleashes tremendous flares expelling hot gas into the Solar | System, which one day will disconnect us." | | -- Day DVB-T stop working nicely | Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/19813.44489.728989.531...@max.nulle.part
Re: Why shouldn't I upgrade uboot on my new OpenRD Ultimate? If so, to which version?
Thanks, Martin! I'll keep that in mind... I've also got a "Client". Do you know a uboot binary that supports SD- card booting on the OpenRD-Client? Thanks for all your good work in this area! Rick On Feb 23, 2011, at 1:28 PM, Martin Michlmayr wrote: * Rick Thomas [2011-02-22 23:04]: The problem is that Uboot 3.4.16 doesn't support access to the MMC/ SD card. So now the question is: What version should I upgrade to? Is it OK to use the same one I used to upgrade the SheevaPlug? U-Boot I don't know which binary to use for the Ultimate, but do NOT use a binary for SheevaPlug or other OpenRD variants for your Ultimate. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51c17319-5e05-428c-bad1-d9bcf1af6...@pobox.com
Re: Reports of successful Squeeze upgrades
Martin Michlmayr wrote: > It would be great if other users could comment. So far, I've seen one > problem report about the RAID uuid changing. What does it take to do a successful upgrade on a slug? Is it really just replacing "lenny" by "squeeze" in /etc/apt/sources.list ? What about the "non-free" firmware that required special images in earlier releases? This is my current sources.list: deb http://ftp.de.debian.org/debian/ lenny main deb-src http://ftp.de.debian.org/debian/ lenny main deb http://security.debian.org/ lenny/updates main deb-src http://security.debian.org/ lenny/updates main deb http://volatile.debian.org/debian-volatile lenny/volatile main deb-src http://volatile.debian.org/debian-volatile lenny/volatile main Do I have to include the "non-free" repository? Regards, Richard -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1773.95.91.209.39.1298496053.squir...@webmail.lrz.de
Re: Please rebuild robustbase and then fportfolio
Hi, 2011/2/22 Dirk Eddelbuettel : > Could someone please schedule a rebuild of robustbase on armel, followed by a > rebuild of fportfolio on armel? That has been done. Thanks, -- Héctor Orón "Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us." -- Day DVB-T stop working nicely Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi=8of_em13sl-zefe-7rsxbervhx0sftnxq3...@mail.gmail.com
Re: Reports of successful Squeeze upgrades
* Björn Wetterbom [2011-02-22 09:54]: > Following the recent conversations regarding upgrade problems I > would appreciate some success stories before I attempt the upgrade > on my (production) machines. Anyone willing to share? Please state > your device type as well (I run an NSLU2 and a TS-209 with Lenny). I upgraded a NSLU2 to squeeze yesterday without any problems but the system was a base system of lenny without any additional software installed. It would be great if other users could comment. So far, I've seen one problem report about the RAID uuid changing. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110223184222.ge21...@jirafa.cyrius.com
Re: flashing fails due to size issue during upgrade
* Björn Wetterbom [2011-02-21 21:18]: > So what's the bottom line of this for the average user? Should I > take any precautionary measures before upgrading my slug to Squeeze > (I will of course follow the instructions in the release notes)? Is > it clear why Jeffrey's ramdisk didn't fit in the flash? I've investigated the problem in the meantime. On a "normal" NSLU2 system running squeeze (normal = root is on extX, not on LVM or something like that) the ramdisk is 6108309 bytes. The ramdisk partition is 6291456 bytes large, so it will just fit. But under certain scenarios (e.g. root on LVM), additional modules will be added and the ramdisk won't fit. The bottom line is: users should make sure to use MODULES=dep to generate their initramfs. Even if a MODULES=most initramfs will fit today, there's no guarantee that it will fit in the future; MODULES=dep makes sure that only the modules you need are put into the initramfs. So: before you upgrade, check whether there's a file on your NSLU@ called /etc/initramfs-tools/conf.d/driver-policy that contains MODULES=dep If not, create such a file: echo "MODULES=dep" > /etc/initramfs-tools/conf.d/driver-policy -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110223184049.gd21...@jirafa.cyrius.com
Re: flashing fails due to size issue during upgrade
* Luca Niccoli [2011-02-22 11:27]: > Compressing my initrd with lzma instead of gzip reduces its size by > 30%, so it could fit. BEWARE though, there could be catches I'm not > aware of (I haven't actually tried booting in this configuration), > maybe Martin could enlighten us? I suppose it would work; my recommendation is to use MODULES=dep to build the ramdisk. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110223183457.gc21...@jirafa.cyrius.com
Re: flashing fails due to size issue during upgrade
* Jeffrey B. Green [2011-02-21 15:00]: > Yes. I do have lvm installed for the slug. So, that is a decent size hit... > > >Can you upload initrd.img-2.6.32-5-ixp4xx somewhere so I can have a > >look at it? > > > Sent to you separately. Thanks. I generated a ramdisk on my NSLU2 and it just fits; since you also use LVM, your ramdisk is larger and won't fit. So MODULES=dep is the right solution for you. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110223183358.gb21...@jirafa.cyrius.com
Re: Why shouldn't I upgrade uboot on my new OpenRD Ultimate? If so, to which version?
* Rick Thomas [2011-02-22 23:04]: > The problem is that Uboot 3.4.16 doesn't support access to the MMC/SD card. > > So now the question is: What version should I upgrade to? Is it OK > to use the same one I used to upgrade the SheevaPlug? U-Boot I don't know which binary to use for the Ultimate, but do NOT use a binary for SheevaPlug or other OpenRD variants for your Ultimate. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110223182835.ga21...@jirafa.cyrius.com
vgchange (lvm) fails with large snapshots on low memory machines
I am running 2.6.32-5-orion5x on a dns-323 (800MHz processor, 64MB RAM). When I have large snapshots (e.g., 75GB), I cannot activate the snapshots or the corresponding original lvm partition. In fact, running the command "vgchange -ay" (or the equivalent lvchange version) either hangs the machine or returns the line "killed" after a few minutes. Looking in the syslog, I get many error messages about memory allocation failures, including: vgchange: page allocation failure. order:0, mode:0x10 Nothing else is running on the machine and I have 500MB of swap (almost all free). I also have a reasonable (for this low memory machine) of unused RAM: #free total used free sharedbuffers cached Mem: 61056 51688 9368 0340 7156 -/+ buffers/cache: 44192 16864 Swap: 530104 6636 523468 Everything works if I switch the drive to a plugcomputer with 512MB RAM though vgchange takes a couple of minutes to load (I believe that is because snapshots are slow). Also, it worked when I removed the older of the two 75GB snapshots. And I think it didn't become a problem until the snapshot got "old" (i.e., started to differ a lot from the original). So what is going on with vgchange that it cannot allocate enough kernel memory? Shouldn't the free RAM plus the swap be enough? Or is there something special about vgchange that requires actual RAM? I am attaching the verbose output of 'vgchange' and the corresponding syslog output below. --- vgchange -ay -v: #lvmcmdline.c:914 Processing: vgchange -ay -v #lvmcmdline.c:917 O_DIRECT will be used #config/config.c:950 Setting global/locking_type to 1 #locking/locking.c:223 File-based locking selected. #config/config.c:927 Setting global/locking_dir to /var/lock/lvm #toollib.c:578 Finding all volume groups #device/dev-io.c:439 Opened /dev/md0 RO O_DIRECT #device/dev-io.c:134 /dev/md0: block size is 4096 bytes #label/label.c:184 /dev/md0: No label detected #label/label.c:287 #device/dev-io.c:485 Closed /dev/md0 #device/dev-io.c:439 Opened /dev/dm-0 RO O_DIRECT #device/dev-io.c:134 /dev/dm-0: block size is 4096 bytes #label/label.c:184 /dev/dm-0: No label detected #label/label.c:287 #device/dev-io.c:485 Closed /dev/dm-0 #device/dev-io.c:439 Opened /dev/sda1 RO O_DIRECT #device/dev-io.c:134 /dev/sda1: block size is 4096 bytes #label/label.c:184 /dev/sda1: No label detected #label/label.c:287 #device/dev-io.c:485 Closed /dev/sda1 #device/dev-io.c:439 Opened /dev/dm-1 RO O_DIRECT #device/dev-io.c:134 /dev/dm-1: block size is 4096 bytes #label/label.c:184 /dev/dm-1: No label detected #label/label.c:287 #device/dev-io.c:485 Closed /dev/dm-1 #device/dev-io.c:439 Opened /dev/root RO O_DIRECT #device/dev-io.c:134 /dev/root: block size is 4096 bytes #label/label.c:184 /dev/root: No label detected #label/label.c:287 #device/dev-io.c:485 Closed /dev/root #device/dev-io.c:439 Opened /dev/dm-2 RO O_DIRECT #device/dev-io.c:134 /dev/dm-2: block size is 4096 bytes #label/label.c:184 /dev/dm-2: No label detected #label/label.c:287 #device/dev-io.c:485 Closed /dev/dm-2 #device/dev-io.c:439 Opened /dev/md3 RO O_DIRECT #device/dev-io.c:134 /dev/md3: block size is 4096 bytes #label/label.c:160 /dev/md3: lvm2 label detected #cache/lvmcache.c:965 lvmcache: /dev/md3: now in VG #orphans_lvm2 (#orphans_lvm2) #format_text/format-text.c:1095 /dev/md3: Found metadata at 28160 size 2360 (in area at 4096 size 192512) for volume1 (Jn9uiZ-yQn1-SFSa-7UoU-67rb-5eYF-s2vtdd) #cache/lvmcache.c:965 lvmcache: /dev/md3: now in VG volume1 with 1 mdas #cache/lvmcache.c:752 lvmcache: /dev/md3: setting volume1 VGID to Jn9uiZyQn1SFSa7UoU67rb5eYFs2vtdd #cache/lvmcache.c:1002 lvmcache: /dev/md3: VG volume1: Set creation host to raider. #device/dev-io.c:485 Closed /dev/md3 #device/dev-io.c:439 Opened /dev/sda4 RO O_DIRECT #device/dev-io.c:134 /dev/sda4: block size is 4096 bytes #label/label.c:184 /dev/sda4: No label detected #label/label.c:287 #device/dev-io.c:485 Closed /dev/sda4 #device/dev-io.c:439 Opened /dev/md4 RO O_DIRECT #device/dev-io.c:134 /dev/md4: block size is 4096 bytes #label/label.c:160 /dev/md4: lvm2 label detected #cache/lvmcache.c:965 lvmcache: /dev/md4: now in VG #orphans_lvm2 (#orphans_lvm2) #format_text/format-text.c:1095 /dev/md4: Found metadata at 5632 size 883 (in area at 4096 size 192512) for volume2 (7cNqUI-uqut-jSmm-yzu2-E22I-n2yV-R6w0h2) #cache/lvmcache.c:965 lvmcache: /dev/md4: now in VG volume2 with 1 md
Re: Why shouldn't I upgrade uboot on my new OpenRD Ultimate? If so, to which version?
Mmm, I double checked and found this post [0] that states that the version I linked doesn't work on the Ultimate. Also, the u-boot version in debian (and upstream git as well) appears only to support openrd-base, w/o SD. This thread could give you some better pointers for a working version: http://groups.google.com/group/openrd/browse_thread/thread/d69f47fc81633f8?pli=1 Cheers, Luca -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikbze1_48qo6a3tdk6k7vykcgv6dpc9k8spr...@mail.gmail.com
Re: Why shouldn't I upgrade uboot on my new OpenRD Ultimate? If so, to which version?
On 23 February 2011 04:04, Rick Thomas wrote: > So now the question is: What version should I upgrade to? Is it OK to use > the same one I used to upgrade the SheevaPlug? U-Boot 3.4.27+pingtoo binary Don't. I did and I ended up with a half-bricked OpenRD Base. If you find the openrd version in debian doesn't suits you, I had success with the one at [0] The procedure is still the same as the one posted on Martin's website. Cheers, Luca [0] http://openrd.googlegroups.com/attach/82f086b82c44e412/u-boot-3.4.19-openrd.zip?part=2 -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinyldqhoukasdvfyz9y5xj+klnrn5awcyfdm...@mail.gmail.com
Re: Why shouldn't I upgrade uboot on my new OpenRD Ultimate? If so, to which version?
On Tue, Feb 22, 2011 at 11:04:17PM -0500, Rick Thomas wrote: > Or is there a special one for the OpenRD machines? The openrd_base image in the Debian u-boot package is supposed to work for OpenRD-Base, OpenRD-Client, and OpenRD-Ultimate. If it does not, please file a bug report. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110223151124.ga17...@scru.org
