Re: The new armhf in town...
On Thu, 2012-07-19 at 08:44 +0300, Andrei POPESCU wrote: FYI, the image works fine (Thanks!), but it is a bit too customized for my taste[1]. Also, your GPG key is not singed by anyone (a trust path to Debian would be great). The emdebian-archive-keyring is in debian[1] which is pretty awesome. [1] http://packages.debian.org/sid/emdebian-archive-keyring -- -Shawn Landden -- 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/1342679032.5910.86.camel@shawn-ssd
Re: The new armhf in town...
On Wed, Jul 18, 2012 at 10:44 PM, Andrei POPESCU andreimpope...@gmail.com wrote: [CC'ing only because you did, JFYI, I am subscribed to debian-arm] FYI, the image works fine (Thanks!), but it is a bit too customized for my taste[1]. Also, your GPG key is not singed by anyone (a trust path to Debian would be great). I'm talking mostly about small stuff like that. [1] This is not a bad thing in itself, considering the audience for it, but I'd still like a pristine Raspbian installation, even I have to do it by hand. Admittedly, I did not look in the forum for instructions yet, since I don't really like forums :( There is a Debian based Raspbian installer available here: http://www.raspbian.org/RaspbianInstaller I personally prefer to work with an installer, but unfortunately, with the SD card media it can be very slow to use so 95% or more of users just want to start from a live image. Improving the installer experience is something we could really use help with as it would make Raspbian more versatile for a wider audience. One of the current handicaps we have is that don't yet have a Raspbian kernel which closely resembles the Debian kernel available with other ARM based systems. Instead we are using the Foundation provided kernel which is derived from a generic 3.1 kernel with Broadcom drivers for the SoC peripherals. It, how shall I say, has issues. Peter is working on a Debian derived kernel for the Pi, but we'll need some help from the foundation to iron out some of the problems he's running into. Regarding the keys not having GPG signatures, that's my fault. Unfortunately, I'm not a Debian developer and I'm not up to speed on the significance of signatures on signing keys. Hopefully this is something that can be corrected in the coming weeks. I'll work with Peter on that. Mike -- 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/caeosq-o29e0nqiyf5oskvxszjkvr7nrnuenguju6jgv5jcz...@mail.gmail.com
Re: The new armhf in town...
Mike Thompson mpthomp...@gmail.com writes: I personally prefer to work with an installer, but unfortunately, with the SD card media it can be very slow to use so 95% or more of users Ack, we have the same problem on openmoko. http://liw.fi/vmdebootstrap/ is an interesting alternative but I haven't had time to test it fully. Peter is working on a Debian derived kernel for the Pi, but we'll need Just taking the debian linux package and dropping the extra patches to debian/patches is surprisingly easy. At least on openmoko the largest problems are that debian kernels typically enable all possible configuration options and some of them have not been tested on openmoko (for example cpufreq breaks suspend). Apart from http://gitorious.org/pkg-fso/linux-2-6-gta02 I'm only aware of one other unofficial fork of the linux package: http://anonscm.debian.org/gitweb/?p=collab-maint/linux-2.6-ac100.git;a=summary Are there others? -- 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/84r4s8w7zd@sauna.l.org
Is it the time to write to you?))
Hey, sweety! My name is Natosha and here is the thing I looked through your pics and I liked the way u look like so much that you can't even imagine, right from the 1st glance. I think that behind those photographs there is a strong and gorgeous man, so I couldn't resist and wrote to you. And I hope you would not ignore it.) Little bit about myself: tall, brunette, good looking titties and my ass is really something.)) I really want to meet you and I hope you've got the same thoughts) Tell me something spicy about urself! Please, do not make me wait for too long Natosha -- 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/1342681918.36427.yahoomail...@web132406.mail.ird.yahoo.com
RE: SS4000E Fan speed, LEDS and power button
Sorry for all the questions. Should I create a swap partition on one disk prior to assembling RAID, does it matter which disk it's on? You said to make all to make all RAID slices the same size, so the swap size would have to be allocated to a partition on all disks? Where does the boot sector go? Does that need a partition? CJW -Original Message- From: JF Straeten [mailto:jfstrae...@scarlet.be] Sent: Wednesday, July 18, 2012 1:55 PM To: debian-arm@lists.debian.org Subject: Re: SS4000E Fan speed, LEDS and power button Chris, On Wed, Jul 18, 2012 at 01:33:44PM -0400, Chris Wilkinson wrote: Loaded the initrd.gz/zimage from daily images by ymodem and ran the exec with rescue/enable=true option. This runs d-i in rescue mode as you said. Good point. Now when I get to the partitioning menu in d-i the option I select is 'assemble RAID array'. I don't think I want to select any of the existing partitions to use as a root file system. The next d-i menu list is 'automatic', followed by a list of existing partitions. I select 'automatic' and hit continue and it goes back to the previous step 'assemble RAID array', so I'm stuck in loop. So went back and tried selecting sda1 sdb1 sdc1 sdd1 as partitions to assemble but same result. When creating the partitions, you have marked them as Member of a RAID set, right ? (Or something similar, perhaps MD ?, but you should figure it easily in front of d-i) If not, you should destroy any partition and redo the partitioning from scratch, not omiting to mark each partition as RAID set member. The steps after is to assemble the corresponding RAID sets, and after that to format the RAID sets themselves with you FS of choice. (Until recently, you can also partition a RAID set, but I never played with that feature.) This can perhaps helps you : lothar:~# cat /proc/mdstat Personalities : [raid1] [raid6] [raid5] [raid4] md2 : active raid5 sda3[0] sdd3[3] sdc3[2] sdb3[1] 928886016 blocks level 5, 64k chunk, algorithm 2 [4/4] [] md1 : active raid1 sda2[0] sdd2[3] sdc2[2] sdb2[1] 497920 blocks [4/4] [] md0 : active raid1 sda1[0] sdd1[3] sdc1[2] sdb1[1] 2441728 blocks [4/4] [] unused devices: none lothar:~# df -h Sys. de fichiersTaille Uti. Disp. Uti% Monté sur /dev/md0 2,3G 597M 1,6G 27% / tmpfs 126M 0 126M 0% /lib/init/rw udev 124M 156K 123M 1% /dev tmpfs 126M 0 126M 0% /dev/shm /dev/sde1 230G 119G 112G 52% /media/lacie /dev/md2 872G 462G 411G 53% /srv So, I've : - md0 of 2.3 GB as / on a RAID1 set ; - (md1 is swap, also RAID1 set) ; - md2 of 872G as /srv on a RAID5 set. You should take care to specify exactly the same size for the corresponding RAID slices on each disk (see the sdX[1-3] up : every member of a RAID set should have the same size. So here, for example, sda1[0] sdd1[3] sdc1[2] sdb1[1] are all of the exact same size.) IIRC, the d-i is able for now to do all the operations involved in RAID creation, so it should work. N.B. you can make your / smaller than mine for a NAS... I've seen to big at setup time :-/ Hih, -- JFS. -- 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/20120718175519.ga10...@jones.jfs.dt -- 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/006801cd65b5$6073f330$215bd990$@net
Re: SS4000E Fan speed, LEDS and power button
Chris, On Thu, Jul 19, 2012 at 09:49:53AM -0400, Chris Wilkinson wrote: Sorry for all the questions. Well, it's what mailing lists are for :-) Should I create a swap partition on one disk prior to assembling RAID [...] It depends on what you want. If you want your swap on RAID, then no : you'll make the swap on the assembled RAID set, like for other RAID sets. But if you don't want RAID for swap, then you can create a swap partition on any disk in the nas, even one on each disk if you want (tough it's not usefull : you simply don't need (big) swap). I take the swap on RAID approach because the disks where all the same size (and so must be the RAID slices) and it was simpler. [...] , does it matter which disk it's on? It also depends... In the swap on RAID school, you will have a slice of each disk used by the swap RAID set. (Optimization ninjas will probably say here that the place of swap on the disk itself matters, which is true in theory, but in practice, and considering the low speed and/or usage of the box, these considerations have little interest, if any...) If the swap is apart, in theory it probably matters, but in practice I think it will not make any difference where swap is. It's even possible that the kernel will not use the swap at all. (Mine doesn't swap a lot at all, if it does...) You said to make all to make all RAID slices the same size, [...] (Yes, but obviously, all the same size **in a given RAID set**. You can of course have RAID sets of different sizes, which is the case in the output from yesterday.) [...] so the swap size would have to be allocated to a partition on all disks? Yes, it's one of the possibilies. You'll probably find usefull informations on RAID in the Debian installation manual if not already read. To summarize, take a look at this table : lothar:~# sfdisk -l /dev/sd[a-d] Disk /dev/sda: 38913 cylinders, 255 heads, 63 sectors/track Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls#blocks Id System /dev/sda1 0+303 304- 2441848+ fd Linux raid autodetect /dev/sda2304 365 62 498015 fd Linux raid autodetect /dev/sda3366 38912 38547 309628777+ fd Linux raid autodetect Disk /dev/sdb: 38913 cylinders, 255 heads, 63 sectors/track Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls#blocks Id System /dev/sdb1 0+303 304- 2441848+ fd Linux raid autodetect /dev/sdb2304 365 62 498015 fd Linux raid autodetect /dev/sdb3366 38912 38547 309628777+ fd Linux raid autodetect Disk /dev/sdc: 38913 cylinders, 255 heads, 63 sectors/track Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls#blocks Id System /dev/sdc1 0+303 304- 2441848+ fd Linux raid autodetect /dev/sdc2304 365 62 498015 fd Linux raid autodetect /dev/sdc3366 38912 38547 309628777+ fd Linux raid autodetect Disk /dev/sdd: 38913 cylinders, 255 heads, 63 sectors/track Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls#blocks Id System /dev/sdd1 0+303 304- 2441848+ fd Linux raid autodetect /dev/sdd2304 365 62 498015 fd Linux raid autodetect /dev/sdd3366 38912 38547 309628777+ fd Linux raid autodetect You see 4 disks of 320 GB each. They are partionned exactly the same. Next, I take each three groups of four same partitions on each disk to assemble the RAID sets : /dev/sd[a-d]1 make together /dev/md0 in RAID 1, mounted on / /dev/sd[a-d]2 make together /dev/md1 in RAID1, formated as swap /dev/sd[a-d]3 make together /dev/md2, in RAID5 mounted as /srv Where does the boot sector go? Does that need a partition? I don't think so. Theses boxes are curiosa which doesn't boot from hard disk, but from an embeded flash memory on the MB. So, d-i will probably write the boot sectors on each disk of the RAID set mounted as /, through the RAID device (/dev/md0 in my case), but unusefully since the nas will not use hard disk to boot... (I'm not absolulety sure, but I don't see either where the hard disks are involved in the boot process...) Hih, -- JFS. -- 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/20120719162514.ga22...@jones.jfs.dt
ARM port(s) BoF at DebConf
[ Please note the cross-post and Reply-To ] Hi folks, Here's a summary of what we discussed in the ARM ports BoF [1] last week (10th July). Thanks to the awesome efforts of the DebConf video team, the video of the session is already online [2] in case you missed it. I've also attached the Gobby notes that were taken during the session. Again, thanks to the people who took part - we had a very useful discussion. Slides are up on my website [3]. armel = First released with Lenny. Soft-float EABI, Software floating point assumed by default. v4t which also runs smaller-size thumb instruction set. Targeting old hardware like openmoko. Discussed (again!) moving forwards from v4. Declared that v5 is no faster than v4t, but there are doubts elsewhere in the community. Later discussion suggests moving to v5te would be worth it. Some good benchmarks would help - volunteers welcome! armhf = First release will be Wheezy. Targets ARMv7 (latest released version of the ARM family), VFPv3-D16, hard-float version of EABI, assumes hardware floating point unit. Benchmarks show that you get anything from 0 to 20% improvement in real-life code, depending on workload. In any case, you should lose nothing. New agreed standard for ARM Linux, in use across all the distros supporting ARM. Mono does not do useful floating point (yet!), still looking for somebody to help here. libffi issues with variadic functions using floating point. buildds === Both armel and armhf are doing well, covering ~96% of the archive. We don't have any ARM server hardware yet, so we're stuck using development boards as build machines. They work, but they're a PITA for hosting and they're not designed for 24x7 usage like we're doing so they're not that reliable. armel currently using a load of Marvell Feroceon dev boards (v5), armhf on Freescale imx53 dev boards. Both sets of machines are limited in terms of memory, meaning the common large C++ apps are painful to build - linking in swap! elsewhere (starting close, moving further out) == Raspbian Unofficial Debian port for the Raspberry Pi. Built (mostly) using Debian source packages, but targeting ARMv6 hard-float. Works well and forwards-compatible with official (v7) armhf. Not being considered for inclusion into the main Debian archive - we already have two ARM ports. Great work from the folks involved, and we'd love to work with them and help wherever possible. Pi is problematic for kernel and non-free graphics drivers... Ubuntu -- Ubuntu has 2 ARM ports released with 12.04 (LTS): armhf for v7 hard-float and armel for v7 soft-float. armel is slowly being re-targeted / rebuilt for v5 instead (no point in having both ports on v7 only). OpenSUSE OpenSUSE developers are doing 2 ARM ports. Concentrating on v7 hard-float, with a lower priority v5 soft-float port. Hoping for a release with 12.2. Fedora -- Fedora developers are doing 2 ARM ports. Concentrating on v7 hard-float, with a lower priority v5 soft-float port. Did a release of F17 with ARM, but beware of linker path issues. Ongoing discussions in Fedora about whether or not ARM will end up becoming a primary architecture. As/when/if it does, expect a RedHat release for ARM. Mageia, Gentoo, ChromeOS, Android also doing ARM Linux work with varying amounts of overlap with what we're doing in Debian. New stuff = Newer versions of ARM hardware and software are coming, with new features and requirements that will be useful and we should look into supporting: * virtualisation extensions * LPAE (large physical address extensions) - allows for a 32-bit system but with larger amounts of memory available on the system. Each process still limited to 4GiB address space, but along with virtualisation could be very useful for large servers * UEFI: standard boot architecture and boot loaders. Device tree and ACPI coming too. Should be able to use a single kernel image to support most new hardware once this work filters down. Very useful as commodity ARM-powered machines become more readily available instead of application-specific setups like phones. * ARMv8 - 64-bit capable. More information in the next talk! [1] http://penta.debconf.org/dc12_schedule/events/870.en.html [2] http://meetings-archive.debian.net/pub/debian-meetings/2012/debconf12/high/870_ARM_ports_update.ogv [3] http://www.einval.com/~steve/talks/Debconf12-arm-ports/ -- Steve McIntyre, Cambridge, UK.st...@einval.com Every time you use Tcl, God kills a kitten. -- Malcolm Ray Please take notes here (not an official ARM talk) armel = First released with Lenny. soft-float EABI. v4t which also runs smaller-size thumb instruction set. Targetting old hardware like openmoko. v5 is no faster than v4t. Software floating point assumed. armhf = First release will
Re: ARM port(s) BoF at DebConf
On Thu, Jul 19, 2012 at 6:35 PM, Steve McIntyre st...@einval.com wrote: Both armel and armhf are doing well, covering ~96% of the archive. We don't have any ARM server hardware yet, so we're stuck using development boards as build machines. They work, but they're a PITA for hosting and they're not designed for 24x7 usage like we're doing so they're not that reliable. there was a post on the arm-netbook mailing list about a 7W quad-core tegra3-based mini ITX motherboard which could take up to 2gb of RAM. whether it's the usual let's-put-something-out-there-see-if-anyone-is-actually-interested style of vapourware or actual reality i'd strongly suggest someone gets onto them and considers putting together a group buy / bulk order just to make it worthwhile their time making a batch, because it's literally the first ARM-based machine i've ever heard about that can actually take 2gb of RAM. oh: also the motherboards have eSATA and uPCI-e, hm let me find the post here you go: http://lists.phcomp.co.uk/pipermail/arm-netbook/2012-July/005127.html btw, steve: it's not the c++ doing linking in swap that's the problem, it's trying to do *debug* builds of c++ applications that's the problem. webkit for example requires a minimum of 1.4gb of resident RAM for the linker phase if you enable debug builds. i have mentioned a number of times that it's debug builds that are the problem, and that all you have to do is disable debugging (*1) and the build will complete within 15 minutes instead of 15 hours, but as usual because it's that fucking moron lkcl telling us what the fuck to do nobody bothers to listen. well, keep on not listening for as long as you (plural) find it useful to do so: i'm not the one with a PITA for having to wait 18 hours for a debug build of a c++ app to complete, am i, eh? *eyebrows-arched* l. (*1) and if someone _really_ wants a debug build of that particular problematic package, on a build and distro port that's still experimental, well, surely they can compile it themselves, using their own resources, yes? -- 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/CAPweEDzD1sVfWTUFrt64=drral2fntoagjaqmm8oabyag7d...@mail.gmail.com
RE: SS4000E Fan speed, LEDS and power button
So one way of proceeding would be to delete all the existing partitions on the 4 HDs, leaving them all as free space. I see you have 3 partitions on each HD, so you created these 3 partitions before creating the RAID sets. I think I need to add only 1 making 2 partitions on each HD, swap and the remaining free space create a new RAID1 adding the swap spaces from each HD. About 2x the RAM size seems to be the suggested size. create a new RAID5 adding the remaining free spaces from each HD use the RAID5 as an ext3 FS, mounted at /, bootable no Use the RAID1 as a swap So this is what I end up with (from the d-i terminal screen) RAID1 device #0 - 510.6 MB Software RAID device #1 510.6 MBf swapswap 53.8 kBunusable RAID5 device #1 - 1.5 TB Software RAID device #1 1.5 TB f ext3/ 512.0 Bunusable SCSI1 (0,0,0) (sda) - 500.1 GB ATA WDC WD5000AAKS-0 #5 logical 499.6 GBK raid #1 primary 510.7 MBK raid SCSI2 (0,0,0) (sdb) - 500.1 GB ATA WDC WD5000AAKS-0 #5 logical 499.6 GBK raid #1 primary 510.7 MBK raid SCSI3 (0,0,0) (sdc) - 500.1 GB ATA WDC WD5000AAKS-0 #5 logical 499.6 GBK raid #1 primary 510.7 MBK raid SCSI4 (0,0,0) (sdd) - 500.1 GB ATA WDC WD5000AAKS-2 #5 logical 499.6 GBK raid #1 primary 510.7 MBK raid After saving/committing this setup, d-i next creates ext3 FS on the RAID5 Creating ext3 file system for / in partition #1 of RAID5 device #1... Install proceeds without error, writes flash, requests reboot. So far so good. The system is going down NOW!ystem... x Sent SIGKILL to all processes x Requesting system rebootj [12830.53] Restarting system. +No network interfaces found EM-438/EM-7220 ver.AG0 2006-05-23 == Executing boot script in 1.000 seconds - enter ^C to abort RedBoot fis load ramdisk.gz RedBoot fis load zImage RedBoot exec -c console=ttyS0,115200 rw root=/dev/ram mem=256M@0xa000 -r 0x0180 -w 5 About to start execution at 0xa0008000 - abort with ^C within 5 seconds Using base address 0x01008000 and length 0x00132fa8 Uncompressing Linux... done, booting the kernel. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.32-5-iop32x (Debian 2.6.32-45) (da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 Sun May 6 07:47:32 UTC 2012 [0.00] CPU: XScale-80219 [69052e30] revision 0 (ARMv5TE), cr=397f [0.00] CPU: VIVT data cache, VIVT instruction cache [0.00] Machine: Lanner EM7210 [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 [0.00] Kernel command line: console=ttyS0,115200 rw root=/dev/ram mem=256M@0xa000 [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Memory: 256MB = 256MB total [0.00] Memory: 251776KB available (3084K code, 444K data, 112K init, 0K highmem) [0.00] SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:32 [0.00] Console: colour dummy device 80x30 [0.00] Calibrating delay loop... 599.65 BogoMIPS (lpj=2998272) [0.22] Security Framework initialized [0.22] SELinux: Disabled at boot. [0.22] Mount-cache hash table entries: 512 [0.22] Initializing cgroup subsys ns [0.22] Initializing cgroup subsys cpuacct [0.22] Initializing cgroup subsys devices [0.22] Initializing cgroup subsys freezer [0.22] Initializing cgroup subsys net_cls [0.22] CPU: Testing write buffer coherency: ok [0.22] devtmpfs: initialized [0.22] regulator: core version 0.5 [0.22] NET: Registered protocol family 16 [0.22] pci :00:01.0: PME# supported from D0 D3hot D3cold [0.22] pci :00:01.0: PME# disabled [0.22] pci :00:05.0: PME# supported from D0 D1 D2 D3hot [0.22] pci :00:05.0: PME# disabled [0.22] pci :00:05.1: PME# supported from D0 D1 D2 D3hot [0.22] pci :00:05.1: PME# disabled [0.22] pci :00:05.2: PME# supported from D0 D1 D2 D3hot [0.22] pci :00:05.2: PME# disabled [0.22] PCI: bus0: Fast back to back transfers disabled [0.23] bio: create slab bio-0 at 0 [0.23] vgaarb: loaded [0.24] NET: Registered protocol family 2 [0.24] IP route cache hash table entries: 2048 (order: 1, 8192 bytes) [0.24] TCP established hash table entries: 8192 (order: 4, 65536 bytes) [0.25] TCP
Re: ARM port(s) BoF at DebConf
Luke Kenneth Casson Leighton wrote: there was a post on the arm-netbook mailing list about a 7W quad-core tegra3-based mini ITX motherboard which could take up to 2gb of RAM. whether it's the usual let's-put-something-out-there-see-if-anyone-is-actually-interested style of vapourware or actual reality i'd strongly suggest someone gets onto them and considers putting together a group buy / bulk order just to make it worthwhile their time making a batch, because it's literally the first ARM-based machine i've ever heard about that can actually take 2gb of RAM. The dell copper machines can supposedly take 8gb per node. Of course when they will be available and how much they will cost is anyones guess at this point. oh: also the motherboards have eSATA and uPCI-e, hm let me find the post here you go: http://lists.phcomp.co.uk/pipermail/arm-netbook/2012-July/005127.html btw, steve: it's not the c++ doing linking in swap that's the problem, it's trying to do *debug* builds of c++ applications that's the problem. webkit for example requires a minimum of 1.4gb of resident RAM for the linker phase if you enable debug builds. i have mentioned a number of times that it's debug builds that are the problem, and that all you have to do is disable debugging (*1) and the build will complete within 15 minutes instead of 15 hours, but as usual because it's that fucking moron lkcl telling us what the fuck to do nobody bothers to listen. well, keep on not listening for as long as you (plural) find it useful to do so: i'm not the one with a PITA for having to wait 18 hours for a debug build of a c++ app to complete, am i, eh? *eyebrows-arched* l. (*1) and if someone _really_ wants a debug build of that particular problematic package, on a build and distro port that's still experimental, well, surely they can compile it themselves, using their own resources, yes? Painful as it is to build them I think we do need the debug symbols for things like webkit. Without them any bug reports will be basically useless. -- 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/50086a71.1010...@p10link.net
Re: ARM port(s) BoF at DebConf
On Thu, 2012-07-19 at 20:09 +0100, Luke Kenneth Casson Leighton wrote: On Thu, Jul 19, 2012 at 6:35 PM, Steve McIntyre st...@einval.com wrote: Both armel and armhf are doing well, covering ~96% of the archive. We [...] (*1) and if someone _really_ wants a debug build of that particular problematic package, on a build and distro port that's still experimental, well, surely they can compile it themselves, using their own resources, yes? Neither wheezy nor the armhf port contained in it are experimental. If that's not what you meant, please be clearer. Regards, Adam -- 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/1342728935.2846.16.ca...@jacala.jungle.funky-badger.org
Re: ARM port(s) BoF at DebConf
On Thu, Jul 19, 2012 at 9:13 PM, peter green plugw...@p10link.net wrote:
Luke Kenneth Casson Leighton wrote:
there was a post on the arm-netbook mailing list about a 7W quad-core
tegra3-based mini ITX motherboard which could take up to 2gb of RAM.
whether it's the usual
let's-put-something-out-there-see-if-anyone-is-actually-interested
style of vapourware or actual reality i'd strongly suggest someone
gets onto them and considers putting together a group buy / bulk order
just to make it worthwhile their time making a batch, because it's
literally the first ARM-based machine i've ever heard about that can
actually take 2gb of RAM.
The dell copper machines can supposedly take 8gb per node. Of course when
they will be available and how much they will cost is anyones guess at this
point.
... yeh, exactly. whereas kontron's tegra3 motherboards appear, if
you take their advertisement as being honest and at face value, to be
available now. 2gb of RAM is just enough, i've found from experience,
to be able to do debug builds of e.g. webkitgtk or webkitefl (not at
the same time!). that linker phase is 1.4 gb resident RAM required,
increasing to 1.6gb briefly towards the end, for the last minute or
so.
(*1) and if someone _really_ wants a debug build of that particular
problematic package, on a build and distro port that's still
experimental, well, surely they can compile it themselves, using their
own resources, yes?
Painful as it is to build them I think we do need the debug symbols for
things
like webkit. Without them any bug reports will be basically useless.
ok, so consider this process/procedure, tell me if you see any
fundamental flaws:
* maintainer (whoever) happily spends 18 hours of their personal
machine's life doing manual builds, once in a while. maybe once a
month even.
* build system creates debug-stripped automated (daily?) packages,
churns them out regularly.
* user downloads debug-stripped package, installs, gets on with it, then...
* splat, bug, reports problem, stacktrace is completely useless
* maintainer asks please download from my home directory a
debug-build i did last {insert manual delay time, week, day, month}
and try again.
or, heck, even the (painful) debug builds could be done automated
using buildd, just once a week/month and kept in a separate
location/server/repository for now. you could even rotate the pain
somewhat by scheduling all of the over-bloated packages to be built
less often but only one being done at any one time, so that they don't
interfere with the building of everything else.
if that truly does become problematic on a per-package basis - large
number of bugreports - then you could always just put that problematic
package back into hammering the build machines mode.
/peace.
l.
--
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/capweedxkfekd2_qrdirq5ajhw00qcaz_vy98nraynddpfuc...@mail.gmail.com
Re: ARM port(s) BoF at DebConf
On Thu, Jul 19, 2012 at 9:15 PM, Adam D. Barratt a...@adam-barratt.org.uk wrote: On Thu, 2012-07-19 at 20:09 +0100, Luke Kenneth Casson Leighton wrote: On Thu, Jul 19, 2012 at 6:35 PM, Steve McIntyre st...@einval.com wrote: Both armel and armhf are doing well, covering ~96% of the archive. We [...] (*1) and if someone _really_ wants a debug build of that particular problematic package, on a build and distro port that's still experimental, well, surely they can compile it themselves, using their own resources, yes? Neither wheezy nor the armhf port contained in it are experimental. If that's not what you meant, please be clearer. yes i used the wrong word: apologies. i was trying to convey the following in a concise way, and chose the word experimental, which i realise in hindsight doesn't cover half of it: doesn't yet have as many users as e.g. i386/amd64, hasn't been around as long as i386/amd64, hasn't got hardware that the average user can buy at a spec approaching that of i386/amd64 yet, and doesn't have as many packages successfully and reliably building as i386/amd64. btw continuing on the thread on debian-arm (only) i put forward a [temporary!] procedure for review which is an interactive balancing act to relieve the burden of having excessive linker-related loads, moving it down instead to later inconvenience for users. of course, if the package is perfect and there *aren't* any bugreports then the interim proposed procedure has done its job. http://lists.debian.org/debian-arm/2012/07/msg00073.html l. -- 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/CAPweEDxPpxZsPjHf7R=nzem5jibfa1snjsve5hk-b167xqu...@mail.gmail.com
Re: ARM port(s) BoF at DebConf
Hi, On Thu, 19 Jul 2012 18:35:44 +0100 Steve McIntyre st...@einval.com wrote: buildds === Both armel and armhf are doing well, covering ~96% of the archive. We don't have any ARM server hardware yet, so we're stuck using development boards as build machines. They work, but they're a PITA for hosting and they're not designed for 24x7 usage like we're doing so they're not that reliable. As I've posted during DebConf(*), Maybe OpenBlocks can solve this problem. It has 2GB RAM, reliable production use and we can buy it NOW. *) http://lists.debian.org/debian-arm/2012/07/msg7.html I'll continue to communicate with that company, so if you have any questions/ comments/suggestions/request/discount;), please tell me whether on-list or privately. -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYamane -- 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/20120720085407.c6a160a418086d0a38d7c...@debian.or.jp
Re: SS4000E Fan speed, LEDS and power button
Re, On Thu, Jul 19, 2012 at 03:49:51PM -0400, Chris Wilkinson wrote: So one way of proceeding would be to delete all the existing partitions on the 4 HDs, leaving them all as free space. I see you have 3 partitions on each HD, so you created these 3 partitions before creating the RAID sets. Yes. I think I need to add only 1 making 2 partitions on each HD, swap and the remaining free space Yes. It's just a (good or bad) habit to create the / apart... create a new RAID1 adding the swap spaces from each HD. About 2x the RAM size seems to be the suggested size. It's an old (and osbolete) advice, but... yes :-) So this is what I end up with (from the d-i terminal screen) RAID1 device #0 - 510.6 MB Software RAID device #1 510.6 MBf swapswap 53.8 kBunusable RAID5 device #1 - 1.5 TB Software RAID device #1 1.5 TB f ext3/ 512.0 Bunusable SCSI1 (0,0,0) (sda) - 500.1 GB ATA WDC WD5000AAKS-0 #5 logical 499.6 GBK raid #1 primary 510.7 MBK raid SCSI2 (0,0,0) (sdb) - 500.1 GB ATA WDC WD5000AAKS-0 #5 logical 499.6 GBK raid #1 primary 510.7 MBK raid SCSI3 (0,0,0) (sdc) - 500.1 GB ATA WDC WD5000AAKS-0 #5 logical 499.6 GBK raid #1 primary 510.7 MBK raid SCSI4 (0,0,0) (sdd) - 500.1 GB ATA WDC WD5000AAKS-2 #5 logical 499.6 GBK raid #1 primary 510.7 MBK raid It seems good to me (you have no need for logical partitions, but it won't hurt either). After saving/committing this setup, d-i next creates ext3 FS on the RAID5 Creating ext3 file system for / in partition #1 of RAID5 device #1... Install proceeds without error, writes flash, requests reboot. Good. [...] [1.74] Freeing init memory: 112K Loading, please wait... /scripts/init-top/udev: line 17: udevd: not found You have already a probleme with udev here. Should try to (re)install it. Begin: Loading essential drivers ... /init: line 205: modprobe: not found /init: line 205: modprobe: not found /init: line 205: modprobe: not found Huu ? modprobe not found ? It's strange, since modprobe is a vital command with a modular kernel... Try also to (re)install it. done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. error sending message: Connection refused udevadm[45]: error sending message: Connection refused Begin: Waiting for root file system ... done. Gave up waiting for root device. Common problems: - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - Check root= (did the system wait for the right device?) - Missing modules (cat /proc/modules; ls /dev) /init: line 5: modprobe: not found /init: line 5: modprobe: not found ALERT! /dev/disk/by-uuid/65707e43-d5a8-4c1a-ac5a-937d8078a606 does not exist. Dropping to a shell! BusyBox v1.17.1 (Debian 1:1.17.1-8) built-in shell (ash) Enter 'help' for a list of built-in commands. /bin/sh: can't access tty; job control turned off (initramfs) Problems are (see log) No root device found initramfs is junk Hangs at this point :( Hangs ? Not really hanged, I suppose ? You should be able to play with busybox, right ? Could you restart d-i and try to purge and reinstall the kernel ? You are using debian stock kernel, right ? It will re-generate the initrd, which I suspect lacks some essential modules... If you have flashed an old initrd without raid support, for example, or without ext3 support in it, it's not surprising that the kernel can't find the root device without support to deal with it... By redoing it, you should finish with an inirtd specially crafted with the modules you need to boot. (NB: It exists also the mkinitramfs command to redo just the initrd. Feel free to try it, but you will need to take a shell in the context of d-i, which is perhaps a bit involved for now.) Hih, -- JFS. -- 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/20120720003338.ga23...@jones.jfs.dt
RE: SS4000E Fan speed, LEDS and power button
Thanks for the tips. Next I tried this and had some success but just why this works escapes me. Loaded initird.gz, zimage After each load, wrote the image to flash with fis create Reboot d-i starts but not in rescue mode ran thru install without incident. Only snag was that the RAID5 was not set as a root FS, so backtracked to make it so. All the partitions set up previously were intact. d-i continued without further problem reboot NAS boots into debian OK. --start log-- +No network interfaces found EM-438/EM-7220 ver.AG0 2006-05-23 == Executing boot script in 1.000 seconds - enter ^C to abort RedBoot fis load ramdisk.gz RedBoot fis load zImage RedBoot exec -c console=ttyS0,115200 rw root=/dev/ram mem=256M@0xa000 -r 0x018000 00 -w 5 About to start execution at 0xa0008000 - abort with ^C within 5 seconds Using base address 0x01008000 and length 0x00132fa8 Uncompressing Linux... done, booting the kernel. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.32-5-iop32x (Debian 2.6.32-45) (da...@debian.org) (gccversion 4.3.5 (Debian 4.3.5-4) ) #1 Sun May 6 07:47:32 UTC 2012 [0.00] CPU: XScale-80219 [69052e30] revision 0 (ARMv5TE), cr=397f [0.00] CPU: VIVT data cache, VIVT instruction cache [0.00] Machine: Lanner EM7210 [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 [0.00] Kernel command line: console=ttyS0,115200 rw root=/dev/ram mem=256M@0xa000 [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Memory: 256MB = 256MB total [0.00] Memory: 251776KB available (3084K code, 444K data, 112K init, 0K highmem) [0.00] SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:32 [0.00] Console: colour dummy device 80x30 [0.00] Calibrating delay loop... 599.65 BogoMIPS (lpj=2998272) [0.22] Security Framework initialized [0.22] SELinux: Disabled at boot. [0.22] Mount-cache hash table entries: 512 [0.22] Initializing cgroup subsys ns [0.22] Initializing cgroup subsys cpuacct [0.22] Initializing cgroup subsys devices [0.22] Initializing cgroup subsys freezer [0.22] Initializing cgroup subsys net_cls [0.22] CPU: Testing write buffer coherency: ok [0.22] devtmpfs: initialized [0.22] regulator: core version 0.5 [0.22] NET: Registered protocol family 16 [0.22] pci :00:01.0: PME# supported from D0 D3hot D3cold [0.22] pci :00:01.0: PME# disabled [0.22] pci :00:05.0: PME# supported from D0 D1 D2 D3hot [0.22] pci :00:05.0: PME# disabled [0.22] pci :00:05.1: PME# supported from D0 D1 D2 D3hot [0.22] pci :00:05.1: PME# disabled [0.22] pci :00:05.2: PME# supported from D0 D1 D2 D3hot [0.22] pci :00:05.2: PME# disabled [0.22] PCI: bus0: Fast back to back transfers disabled [0.23] bio: create slab bio-0 at 0 [0.23] vgaarb: loaded [0.24] NET: Registered protocol family 2 [0.24] IP route cache hash table entries: 2048 (order: 1, 8192 bytes) [0.24] TCP established hash table entries: 8192 (order: 4, 65536 bytes) [0.25] TCP bind hash table entries: 8192 (order: 3, 32768 bytes) [0.25] TCP: Hash tables configured (established 8192 bind 8192) [0.25] TCP reno registered [0.25] NET: Registered protocol family 1 [0.25] Unpacking initramfs... [0.95] Freeing initrd memory: 4096K [0.95] NetWinder Floating Point Emulator V0.97 (double precision) [0.95] audit: initializing netlink socket (disabled) [0.95] type=2000 audit(0.950:1): initialized [0.97] VFS: Disk quotas dquot_6.5.2 [0.97] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [0.97] msgmni has been set to 500 [0.97] alg: No test for stdrng (krng) [0.97] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) [0.97] io scheduler noop registered [0.97] io scheduler anticipatory registered [0.97] io scheduler deadline registered [0.97] io scheduler cfq registered (default) [0.98] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled [0.99] serial8250.0: ttyS0 at MMIO 0xfe80 (irq = 28) is a 16550A [1.33] console [ttyS0] enabled [1.33] physmap platform flash device: 0200 at f000 [1.34] physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank [1.34] Intel/Sharp Extended Query Table at 0x0031 [1.35]
Re: ARM port(s) BoF at DebConf
Hi,
2012/7/20 Hideki Yamane henr...@debian.or.jp:
Hi,
On Thu, 19 Jul 2012 18:35:44 +0100
Steve McIntyre st...@einval.com wrote:
buildds
===
Both armel and armhf are doing well, covering ~96% of the archive. We
don't have any ARM server hardware yet, so we're stuck using
development boards as build machines. They work, but they're a PITA
for hosting and they're not designed for 24x7 usage like we're doing
so they're not that reliable.
As I've posted during DebConf(*), Maybe OpenBlocks can solve this problem.
It has 2GB RAM, reliable production use and we can buy it NOW.
Note: This device can carry 2 GB of memory at the maximum. It is 1 GB at first.
It does not necessarily have this 2 GB from first.
*) http://lists.debian.org/debian-arm/2012/07/msg7.html
I'll continue to communicate with that company, so if you have any questions/
comments/suggestions/request/discount;), please tell me whether on-list or
privately.
Well, I already taking about this.
And the kernel of this machine has not been supported by upstream yet.
We have some problems which should be solved.
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
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/cabmqnvkkmu9viwgyitdlgifjz2jk4izkm+5c-xdkn8pc+od...@mail.gmail.com
modern cheap NAS fully supported by Debian?
Sorry list, I can imagine this question has been asked many times, but the answer changes with time and browsing this list and related resources I cannot find a sufficiently recent (let's say1 year) answer to it. I gave up on my NSLU 2 which seems irremediably broken (my guess is that the RAM is botched) and I would like to buy another NAS in that price range or whereabouts. And of course, I would like to be able to run a full Debian system on it. Debian Squeeze would be fine, but I can install Woody if need be. What do you think is a good buy? To qualify further my question, I was looking at something like the XTreamer ETrayz http://www.xtreamer.net/etrayz/specs.aspx, but that machine is no longer in production and I don't even know if Debian can be installed over it. Thank you for all your replies, nicb -- Nicola Bernardini e-mail: nic.b...@tiscali.it http://www.nicolabernardini.info GPG fingerprint = 6AE6 AF21 E160 D9B3 396E EBAC 906C CFAE 4D65 D910 Neither MS-Word nor MS-PowerPoint attachments please. -- 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/20120720034229.GB6493@eeepc-1215B
Re: modern cheap NAS fully supported by Debian?
On Thu, Jul 19, 2012 at 8:42 PM, Nicola Bernardini n...@sme-ccppd.org wrote: Sorry list, I can imagine this question has been asked many times, but the answer changes with time and browsing this list and related resources I cannot find a sufficiently recent (let's say1 year) answer to it. I gave up on my NSLU 2 which seems irremediably broken (my guess is that the RAM is botched) and I would like to buy another NAS in that price range or whereabouts. And of course, I would like to be able to run a full Debian system on it. Debian Squeeze would be fine, but I can install Woody if need be. What do you think is a good buy? To qualify further my question, I was looking at something like the XTreamer ETrayz http://www.xtreamer.net/etrayz/specs.aspx, but that machine is no longer in production and I don't even know if Debian can be installed over it. Thank you for all your replies, nicb I don't know if you would considder this modern enough, but I have had good luck with my HP MV2120 that I picked up for about $30 on ebay. You will need to supply a drive and a power supply in addition to the basic unit. I am running Wheezy on mine and it is used to run rsnapshot,apcupsd and soon dnsmasq (that one is still on the Slug it replaced). -- Henry von Tresckow (hvontres) -- 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/caea7u+lu1pyppnjxuzp1fnjs0g32rbwfmunn_ehtt0kkfwv...@mail.gmail.com
Re: modern cheap NAS fully supported by Debian?
On Thu, Jul 19, 2012 at 09:19:38PM -0700, Hans Henry von Tresckow wrote: On Thu, Jul 19, 2012 at 8:42 PM, Nicola Bernardini n...@sme-ccppd.org wrote: Sorry list, I can imagine this question has been asked many times, but the answer changes with time and browsing this list and related resources I cannot find a sufficiently recent (let's say1 year) answer to it. I gave up on my NSLU 2 which seems irremediably broken (my guess is that the RAM is botched) and I would like to buy another NAS in that price range or whereabouts. And of course, I would like to be able to run a full Debian system on it. Debian Squeeze would be fine, but I can install Woody if need be. What do you think is a good buy? To qualify further my question, I was looking at something like the XTreamer ETrayz http://www.xtreamer.net/etrayz/specs.aspx, but that machine is no longer in production and I don't even know if Debian can be installed over it. Thank you for all your replies, nicb I don't know if you would considder this modern enough, but I have had good luck with my HP MV2120 that I picked up for about $30 on ebay. You will need to supply a drive and a power supply in addition to the basic unit. I am running Wheezy on mine and it is used to run rsnapshot,apcupsd and soon dnsmasq (that one is still on the Slug it replaced). Thank you Henry! Just to specify: by modern I just mean that I still can find it somewhere to buy it, nothing else. Thanks again, nicb -- Nicola Bernardini e-mail: nic.b...@tiscali.it http://www.nicolabernardini.info GPG fingerprint = 6AE6 AF21 E160 D9B3 396E EBAC 906C CFAE 4D65 D910 Neither MS-Word nor MS-PowerPoint attachments please. -- 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/20120720043040.GC6493@eeepc-1215B
Re: modern cheap NAS fully supported by Debian?
On 07/20/2012 05:42 AM, Nicola Bernardini wrote: I gave up on my NSLU 2 which seems irremediably broken (my guess is that the RAM is botched) and I would like to buy another NAS in that price range or whereabouts. And of course, I would like to be able to run a full Debian system on it. Debian Squeeze would be fine, but I can install Woody if need be. What do you think is a good buy? I like Marvell Kirkwood based boxes. You have everything from the more expensive guruplug down to cheaper pogoplug v2 and dockstar. GoFlex Home and GoFlex Net only have one usb port, but comes with one or two sata ports. Earlier there where someone selling just the base for GoFlex Homes on ebay really cheap. At least if you're living in the US. http://forum.doozan.com/ is a good source for Debian on those machines. /M -- 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/5008eaa1.8030...@gmail.com
