Es posible traer 20 tablets a Perú de su ultuma version XO? Para un proyecto de Alfabetización Privado.
Saludos Juan Camareno. 2015-07-14 21:54 GMT-05:00 <devel-requ...@lists.laptop.org>: > Send Devel mailing list submissions to > devel@lists.laptop.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.laptop.org/listinfo/devel > or, via email, send a message with subject or body 'help' to > devel-requ...@lists.laptop.org > > You can reach the person managing the list at > devel-ow...@lists.laptop.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Devel digest..." > > > Today's Topics: > > 1. Re: [XSCE] sdcard for /opt and /library on xo 1.5 (James Cameron) > 2. RE: [XSCE] sdcard for /opt and /library on xo 1.5 (Tim Moody) > 3. Re: [XSCE] sdcard for /opt and /library on xo 1.5 (James Cameron) > 4. Re: [XSCE] sdcard for /opt and /library on xo 1.5 > (Samuel Greenfeld) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 15 Jul 2015 10:13:40 +1000 > From: James Cameron <qu...@laptop.org> > To: Tim Moody <t...@timmoody.com> > Cc: server-de...@lists.laptop.org, devel@lists.laptop.org, > xsce-de...@googlegroups.com > Subject: Re: [XSCE] sdcard for /opt and /library on xo 1.5 > Message-ID: <20150715001340.gf21...@us.netrek.org> > Content-Type: text/plain; charset=us-ascii > > G'day Tim, > > Thanks, that's interesting. > > My best guess is you have a bad connector and the 24-hour thermal test > you did fixed it. The problem may return. > > Another guess is that the card has the production state awareness > feature [1], part of e.MMC v5.0, which uses the storage cells > differently before they are enabled for normal use. The state can be > changed with suitable tools, or will clear itself once enough data is > written; followed by a power cycle. The result is a sudden increase > in performance after that power cycle. > > Suggestions: > > - next time you want to erase a card, send it the erase command, which > takes between three and fifteen seconds in my tests [2], > > - test the communications between the system and the card by measuring > the sequential read performance; this is usually the easiest way to > test communications, > > - try on a different XO-1.5, in case you have a faulty XO-1.5, and > raise doubts if the performance differs, > > - try on a modern desktop system; that will isolate the problem to > interoperability with the XO-1.5, > > - identify the kernel, in case you have a version that doesn't > properly switch to 1.8V; if so, the slot on the XO-1.5 will run it > at 3.3V, warm, and so the card firmware will intentionally slow the > transfers to ensure compliance with thermal specifications, > > - try reseating the card in the adapter, and the adapter in the > system, because a bad connection can show up as slow data rate, then > re-test the communications, > > - if available, use uninit_bg when calling mke2fs, so that the > "formatting" doesn't have to write much, > > - publish the dmesg fragment showing the card being detected. > > When thinking about problems with SD card, it is best to imagine it as > a separate computer, in which you can't change the software. There's > no telling what it will do. ;-) They are very complex systems, made > to look simple. Plug and play, dumbing down. > > +CC devel@ for general XO-1.5 and SD card interest. > > References: > > 1. > > https://www.jedec.org/news/pressreleases/jedec-announces-publication-emmc-standard-update-v50 > > 2. > http://wiki.laptop.org/go/Firmware/Storage#How_to_quickly_erase_everything > (but use http://wiki.laptop.org/go/Firmware/Storage#devalias_fsdisk > first) > > On Tue, Jul 14, 2015 at 06:34:52PM -0400, Tim Moody wrote: > > I have been around the block with a 128G micro sdcard allegedly from > > Sandisk. I made various attempts at creating two partitions and > > formatting them ext4, some of which progressed at the rate of > > 10G/hour. > > > > I finally used dd to write /dev/zero to the entire device, which > > took almost 24 hours. > > > > After that parted mklabel msdos and mkpart worked fine and mkfs.ext4 > > also worked fine in a couple of minutes. > > > > -- > James Cameron > http://quozl.linux.org.au/ > > > ------------------------------ > > Message: 2 > Date: Tue, 14 Jul 2015 23:49:29 -0400 > From: Tim Moody <t...@timmoody.com> > To: <xsce-de...@googlegroups.com> > Cc: server-de...@lists.laptop.org, devel@lists.laptop.org > Subject: RE: [XSCE] sdcard for /opt and /library on xo 1.5 > Message-ID: <blu405-eas3406e6198351b4225c603acc5...@phx.gbl> > Content-Type: text/plain; charset="us-ascii" > > I think the bottom line is that on this xo1.5 I need to use a usb thumb > drive instead of this micro sdcard and its holder. > > > -----Original Message----- > > From: xsce-de...@googlegroups.com [mailto:xsce- > > de...@googlegroups.com] On Behalf Of James Cameron > > Sent: Tuesday, July 14, 2015 8:14 PM > > To: Tim Moody > > Cc: server-de...@lists.laptop.org; devel@lists.laptop.org; xsce- > > de...@googlegroups.com > > Subject: Re: [XSCE] sdcard for /opt and /library on xo 1.5 > > > > G'day Tim, > > > > Thanks, that's interesting. > > > > My best guess is you have a bad connector and the 24-hour thermal test > you > > did fixed it. The problem may return. > > > > Another guess is that the card has the production state awareness feature > > [1], part of e.MMC v5.0, which uses the storage cells differently before > they > > are enabled for normal use. The state can be changed with suitable > tools, > or > > will clear itself once enough data is written; followed by a power cycle. > The > > result is a sudden increase in performance after that power cycle. > > > interesting ideas. I have no way of judging either. > > My guess is that I tried so many different ways of partitioning it from > fdisk to parted that it was so messed up that an xo 1.5, a nuc, and a dell > all found it corrupt, compounded by the fact that systemd has it in use > even > if it is not actually mounted. > > The sdcard holder is also looking pretty suspect as used with the card slot > on the xo. I put the micro sd in the holder back into the xo 1.5 and it > reported two devices with pttype of "dos", but gave unknown file system > when > I tried to mount > > -bash-4.2# mount > /dev/mmcblk1p1 on /bootpart type ext4 (rw,relatime,user_xattr,barrier=1) > /dev/mmcblk1p2 on / type ext4 > (rw,noatime,user_xattr,barrier=1,data=ordered) > devtmpfs on /dev type devtmpfs > (rw,nosuid,relatime,size=475460k,nr_inodes=118865,mode=755) > /dev/mmcblk1p2 on /home type ext4 > (rw,relatime,user_xattr,barrier=1,data=ordered) > /dev/mmcblk1p2 on /versions type ext4 > (rw,relatime,user_xattr,barrier=1,data=ordered) > /dev/mmcblk1p1 on /security type ext4 (rw,relatime,user_xattr,barrier=1) > proc on /proc type proc (rw,relatime) > sysfs on /sys type sysfs (rw,relatime) > tmpfs on /dev/shm type tmpfs (rw,relatime,size=51200k) > devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620) > tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) > tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755) > cgroup on /sys/fs/cgroup/systemd type cgroup > > (rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgro > ups-agent,name=systemd) > cgroup on /sys/fs/cgroup/cpu type cgroup > (rw,nosuid,nodev,noexec,relatime,cpu) > systemd-1 on /proc/sys/fs/binfmt_misc type autofs > (rw,relatime,fd=27,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) > hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime) > debugfs on /sys/kernel/debug type debugfs (rw,relatime) > mqueue on /dev/mqueue type mqueue (rw,relatime) > vartmp on /var/tmp type tmpfs (rw,relatime,size=51200k) > /tmp on /tmp type tmpfs (rw,relatime,size=204800k) > none on /var/lib/stateless/writable type tmpfs > (rw,relatime,size=4096k,nr_inodes=2048) > none on /var/cache/man type tmpfs (rw,relatime,size=4096k,nr_inodes=2048) > none on /var/lib/xkb type tmpfs (rw,relatime,size=4096k,nr_inodes=2048) > none on /var/cache/httpd/ssl type tmpfs > (rw,relatime,size=4096k,nr_inodes=2048) > none on /var/cache/httpd/proxy type tmpfs > (rw,relatime,size=4096k,nr_inodes=2048) > none on /var/cache/php-pear type tmpfs > (rw,relatime,size=4096k,nr_inodes=2048) > none on /var/lib/dav type tmpfs (rw,relatime,size=4096k,nr_inodes=2048) > none on /var/lib/dhclient type tmpfs > (rw,relatime,size=4096k,nr_inodes=2048) > none on /etc/adjtime type tmpfs (rw,relatime,size=4096k,nr_inodes=2048) > none on /var/lib/logrotate.status type tmpfs > (rw,relatime,size=4096k,nr_inodes=2048) > none on /var/spool type tmpfs (rw,relatime,size=4096k,nr_inodes=2048) > /dev/mmcblk1p1 on /etc/ssh type ext4 (rw,relatime,user_xattr,barrier=1) > /dev/mmcblk1p1 on /var/lib/dbus type ext4 > (rw,relatime,user_xattr,barrier=1) > /dev/mmcblk1p1 on /var/lib/random-seed type ext4 > (rw,relatime,user_xattr,barrier=1) > /dev/mmcblk1p1 on /etc/NetworkManager/system-connections type ext4 > (rw,relatime,user_xattr,barrier=1) > /dev/sda2 on /library type ext4 > (rw,noatime,user_xattr,barrier=1,data=ordered) > /dev/sda1 on /opt type ext4 (rw,noatime,user_xattr,barrier=1,data=ordered) > (sda is a usb thumbdrive) > > -bash-4.2# blkid > /dev/sda1: UUID="20d7ab6c-ec76-4fc3-a702-75c0051b5ce6" TYPE="ext4" > /dev/sda2: UUID="e1c0ef6a-dc89-4d46-bcef-7b19360d41f7" TYPE="ext4" > /dev/mmcblk0p1: UUID="de889f2b-fffb-4a45-8358-dce449f2cf7e" TYPE="ext4" > /dev/mmcblk0p2: UUID="0ad6a5ee-bc3d-4fc6-8b9b-ca9bc456cb74" TYPE="ext4" > /dev/mmcblk1p1: LABEL="Boot" UUID="ac3c6c0f-8350-47ab-a308-42d49652f030" > TYPE="ext2" > /dev/mmcblk1p2: LABEL="OLPCRoot" > UUID="61a34c92-0f69-409d-9b61-23a5522d296d" > TYPE="ext4" > /dev/mmcblk0: PTTYPE="dos" > /dev/mmcblk1: PTTYPE="dos" > > -bash-4.2# mkdir /mnt/sdcard > -bash-4.2# mount /dev/mmcblk0 /mnt/sdcard > mount: unknown filesystem type '(null)' > > But when I put the micro sdcard into my usb adapter and plugged that into > the xo 1.5 I see > > -bash-4.2# ll /dev/sde* > brw-rw---- 1 root disk 8, 64 Jul 15 2015 /dev/sde > brw-rw---- 1 root disk 8, 65 Jul 15 2015 /dev/sde1 > brw-rw---- 1 root disk 8, 66 Jul 15 2015 /dev/sde2 > > and /dev/sde1 automounted on /media/usb0 > > I tried another holder from nexxtech and got the same result as the sandisk > one. > > > Suggestions: > > > > - next time you want to erase a card, send it the erase command, which > > takes between three and fifteen seconds in my tests [2], > > you mentioned erase before, but I couldn't find it. the googling I did > only > mentioned using dd to erase. > > [root@schoolserver zims]# which erase > /usr/bin/which: no erase in > > (/usr/local/sbin:/usr/sbin:/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/u > sr/bin:/root/bin) > > > > - test the communications between the system and the card by measuring > > the sequential read performance; this is usually the easiest way to > > test communications, > > not sure I had anything to read as I never had a file system. > > > > - try on a different XO-1.5, in case you have a faulty XO-1.5, and > > raise doubts if the performance differs, > > only have the one > > > > - try on a modern desktop system; that will isolate the problem to > > interoperability with the XO-1.5, > > even I thought of this. in fact I saw differences between fedora 22 (my > NUC) and fedora 20 (my old Dell). It was fedora 20 on which I did anything > useful including the zeroing. I guess the subject line of my email is > misleading in this regard. > > > > - identify the kernel, in case you have a version that doesn't > > properly switch to 1.8V; if so, the slot on the XO-1.5 will run it > > at 3.3V, warm, and so the card firmware will intentionally slow the > > transfers to ensure compliance with thermal specifications, > > > > - try reseating the card in the adapter, and the adapter in the > > system, because a bad connection can show up as slow data rate, then > > re-test the communications, > > this is a possible factor in that I used a usb adapter for the micro sd > more > successfully than the holder > > > > - if available, use uninit_bg when calling mke2fs, so that the > > "formatting" doesn't have to write much, > > > > - publish the dmesg fragment showing the card being detected. > > > > When thinking about problems with SD card, it is best to imagine it as a > > separate computer, in which you can't change the software. There's no > > telling what it will do. ;-) They are very complex systems, made to > look > > simple. Plug and play, dumbing down. > > and apparently the home of a new class of virus, undetectable due to the > fact that the os is stored in write-only memory. > > > > +CC devel@ for general XO-1.5 and SD card interest. > > > > References: > > > > 1. > > https://www.jedec.org/news/pressreleases/jedec-announces-publication- > > emmc-standard-update-v50 > > > > 2. > > http://wiki.laptop.org/go/Firmware/Storage#How_to_quickly_erase_everyt > > hing > > (but use http://wiki.laptop.org/go/Firmware/Storage#devalias_fsdisk > > first) > > > > On Tue, Jul 14, 2015 at 06:34:52PM -0400, Tim Moody wrote: > > > I have been around the block with a 128G micro sdcard allegedly from > > > Sandisk. I made various attempts at creating two partitions and > > > formatting them ext4, some of which progressed at the rate of > > > 10G/hour. > > > > > > I finally used dd to write /dev/zero to the entire device, which took > > > almost 24 hours. > > > > > > After that parted mklabel msdos and mkpart worked fine and mkfs.ext4 > > > also worked fine in a couple of minutes. > > > > > > > -- > > James Cameron > > http://quozl.linux.org.au/ > > > ------------------------------ > > Message: 3 > Date: Wed, 15 Jul 2015 14:09:16 +1000 > From: James Cameron <qu...@laptop.org> > To: xsce-de...@googlegroups.com > Cc: server-de...@lists.laptop.org, devel@lists.laptop.org > Subject: Re: [XSCE] sdcard for /opt and /library on xo 1.5 > Message-ID: <20150715040916.gp21...@us.netrek.org> > Content-Type: text/plain; charset=us-ascii > > On Tue, Jul 14, 2015 at 11:49:29PM -0400, Tim Moody wrote: > > I think the bottom line is that on this xo1.5 I need to use a usb thumb > > drive instead of this micro sdcard and its holder. > > > > > -----Original Message----- > > > From: xsce-de...@googlegroups.com [mailto:xsce- > > > de...@googlegroups.com] On Behalf Of James Cameron > > > Sent: Tuesday, July 14, 2015 8:14 PM > > > To: Tim Moody > > > Cc: server-de...@lists.laptop.org; devel@lists.laptop.org; xsce- > > > de...@googlegroups.com > > > Subject: Re: [XSCE] sdcard for /opt and /library on xo 1.5 > > > > > > G'day Tim, > > > > > > Thanks, that's interesting. > > > > > > My best guess is you have a bad connector and the 24-hour thermal test > you > > > did fixed it. The problem may return. > > > > > > Another guess is that the card has the production state awareness > feature > > > [1], part of e.MMC v5.0, which uses the storage cells differently > before > > they > > > are enabled for normal use. The state can be changed with suitable > tools, > > or > > > will clear itself once enough data is written; followed by a power > cycle. > > The > > > result is a sudden increase in performance after that power cycle. > > > > > interesting ideas. I have no way of judging either. > > > > My guess is that I tried so many different ways of partitioning it from > > fdisk to parted that it was so messed up that an xo 1.5, a nuc, and a > dell > > all found it corrupt, compounded by the fact that systemd has it in use > even > > if it is not actually mounted. > > Yes, it sounds like you lost track of the provenance. > > At heart though, an SD card is just a set of blocks, so I always make > a copy of it before writing. The copy usually compresses really well > for permanent storage. > > > > > The sdcard holder is also looking pretty suspect as used with the card > slot > > on the xo. I put the micro sd in the holder back into the xo 1.5 and it > > reported two devices with pttype of "dos", but gave unknown file system > when > > I tried to mount > > > > -bash-4.2# mount > > /dev/mmcblk1p1 on /bootpart type ext4 (rw,relatime,user_xattr,barrier=1) > > /dev/mmcblk1p2 on / type ext4 > (rw,noatime,user_xattr,barrier=1,data=ordered) > > devtmpfs on /dev type devtmpfs > > (rw,nosuid,relatime,size=475460k,nr_inodes=118865,mode=755) > > /dev/mmcblk1p2 on /home type ext4 > > (rw,relatime,user_xattr,barrier=1,data=ordered) > > /dev/mmcblk1p2 on /versions type ext4 > > (rw,relatime,user_xattr,barrier=1,data=ordered) > > /dev/mmcblk1p1 on /security type ext4 (rw,relatime,user_xattr,barrier=1) > > proc on /proc type proc (rw,relatime) > > sysfs on /sys type sysfs (rw,relatime) > > tmpfs on /dev/shm type tmpfs (rw,relatime,size=51200k) > > devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620) > > tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) > > tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755) > > cgroup on /sys/fs/cgroup/systemd type cgroup > > > (rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgro > > ups-agent,name=systemd) > > cgroup on /sys/fs/cgroup/cpu type cgroup > > (rw,nosuid,nodev,noexec,relatime,cpu) > > systemd-1 on /proc/sys/fs/binfmt_misc type autofs > > (rw,relatime,fd=27,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) > > hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime) > > debugfs on /sys/kernel/debug type debugfs (rw,relatime) > > mqueue on /dev/mqueue type mqueue (rw,relatime) > > vartmp on /var/tmp type tmpfs (rw,relatime,size=51200k) > > /tmp on /tmp type tmpfs (rw,relatime,size=204800k) > > none on /var/lib/stateless/writable type tmpfs > > (rw,relatime,size=4096k,nr_inodes=2048) > > none on /var/cache/man type tmpfs (rw,relatime,size=4096k,nr_inodes=2048) > > none on /var/lib/xkb type tmpfs (rw,relatime,size=4096k,nr_inodes=2048) > > none on /var/cache/httpd/ssl type tmpfs > > (rw,relatime,size=4096k,nr_inodes=2048) > > none on /var/cache/httpd/proxy type tmpfs > > (rw,relatime,size=4096k,nr_inodes=2048) > > none on /var/cache/php-pear type tmpfs > > (rw,relatime,size=4096k,nr_inodes=2048) > > none on /var/lib/dav type tmpfs (rw,relatime,size=4096k,nr_inodes=2048) > > none on /var/lib/dhclient type tmpfs > (rw,relatime,size=4096k,nr_inodes=2048) > > none on /etc/adjtime type tmpfs (rw,relatime,size=4096k,nr_inodes=2048) > > none on /var/lib/logrotate.status type tmpfs > > (rw,relatime,size=4096k,nr_inodes=2048) > > none on /var/spool type tmpfs (rw,relatime,size=4096k,nr_inodes=2048) > > /dev/mmcblk1p1 on /etc/ssh type ext4 (rw,relatime,user_xattr,barrier=1) > > /dev/mmcblk1p1 on /var/lib/dbus type ext4 > (rw,relatime,user_xattr,barrier=1) > > /dev/mmcblk1p1 on /var/lib/random-seed type ext4 > > (rw,relatime,user_xattr,barrier=1) > > /dev/mmcblk1p1 on /etc/NetworkManager/system-connections type ext4 > > (rw,relatime,user_xattr,barrier=1) > > /dev/sda2 on /library type ext4 > > (rw,noatime,user_xattr,barrier=1,data=ordered) > > /dev/sda1 on /opt type ext4 > (rw,noatime,user_xattr,barrier=1,data=ordered) > > (sda is a usb thumbdrive) > > > > -bash-4.2# blkid > > /dev/sda1: UUID="20d7ab6c-ec76-4fc3-a702-75c0051b5ce6" TYPE="ext4" > > /dev/sda2: UUID="e1c0ef6a-dc89-4d46-bcef-7b19360d41f7" TYPE="ext4" > > /dev/mmcblk0p1: UUID="de889f2b-fffb-4a45-8358-dce449f2cf7e" TYPE="ext4" > > /dev/mmcblk0p2: UUID="0ad6a5ee-bc3d-4fc6-8b9b-ca9bc456cb74" TYPE="ext4" > > /dev/mmcblk1p1: LABEL="Boot" UUID="ac3c6c0f-8350-47ab-a308-42d49652f030" > > TYPE="ext2" > > /dev/mmcblk1p2: LABEL="OLPCRoot" > UUID="61a34c92-0f69-409d-9b61-23a5522d296d" > > TYPE="ext4" > > /dev/mmcblk0: PTTYPE="dos" > > /dev/mmcblk1: PTTYPE="dos" > > > > -bash-4.2# mkdir /mnt/sdcard > > -bash-4.2# mount /dev/mmcblk0 /mnt/sdcard > > mount: unknown filesystem type '(null)' > > Expected. You should have been trying /dev/mmcblk0p1 or p2. Without > p1 or p2 it is the overall device, usually not a partition. > > > > > But when I put the micro sdcard into my usb adapter and plugged that into > > the xo 1.5 I see > > > > -bash-4.2# ll /dev/sde* > > brw-rw---- 1 root disk 8, 64 Jul 15 2015 /dev/sde > > brw-rw---- 1 root disk 8, 65 Jul 15 2015 /dev/sde1 > > brw-rw---- 1 root disk 8, 66 Jul 15 2015 /dev/sde2 > > > > and /dev/sde1 automounted on /media/usb0 > > Ok. > > > > > I tried another holder from nexxtech and got the same result as the > sandisk > > one. > > > > > Suggestions: > > > > > > - next time you want to erase a card, send it the erase command, which > > > takes between three and fifteen seconds in my tests [2], > > > > you mentioned erase before, but I couldn't find it. the googling I did > only > > mentioned using dd to erase. > > > > [root@schoolserver zims]# which erase > > /usr/bin/which: no erase in > > > (/usr/local/sbin:/usr/sbin:/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/u > > sr/bin:/root/bin) > > The link supplied in [2] was for Open Firmware, and I've not studied > how to do the same in Linux. It would be really annoying to do it by > accident. > > > > > > > - test the communications between the system and the card by measuring > > > the sequential read performance; this is usually the easiest way to > > > test communications, > > > > not sure I had anything to read as I never had a file system. > > The card is an array of blocks, so you can always read them; > > su > sync > echo 1 > /proc/sys/vm/drop_caches > dd if=/dev/mmcblk0 of=/dev/null bs=1M count=256 > > A data rate will be printed by dd. That will give you a performance > measurement that is never more than the actual performance, and > occasionally less. > > > > - try on a different XO-1.5, in case you have a faulty XO-1.5, and > > > raise doubts if the performance differs, > > > > only have the one > > > > > > - try on a modern desktop system; that will isolate the problem to > > > interoperability with the XO-1.5, > > > > even I thought of this. in fact I saw differences between fedora 22 (my > > NUC) and fedora 20 (my old Dell). It was fedora 20 on which I did > anything > > useful including the zeroing. I guess the subject line of my email is > > misleading in this regard. > > > > > > - identify the kernel, in case you have a version that doesn't > > > properly switch to 1.8V; if so, the slot on the XO-1.5 will run it > > > at 3.3V, warm, and so the card firmware will intentionally slow the > > > transfers to ensure compliance with thermal specifications, > > > > > > - try reseating the card in the adapter, and the adapter in the > > > system, because a bad connection can show up as slow data rate, then > > > re-test the communications, > > > > this is a possible factor in that I used a usb adapter for the micro sd > more > > successfully than the holder > > Also by using USB adapter you are offloading some of the > communications work to a processor in the adapter. > > The electrics of the adapter might also be a better match. > > > > > > > - if available, use uninit_bg when calling mke2fs, so that the > > > "formatting" doesn't have to write much, > > > > > > - publish the dmesg fragment showing the card being detected. > > > > > > When thinking about problems with SD card, it is best to imagine it as > a > > > separate computer, in which you can't change the software. There's no > > > telling what it will do. ;-) They are very complex systems, made to > look > > > simple. Plug and play, dumbing down. > > > > and apparently the home of a new class of virus, undetectable due to the > > fact that the os is stored in write-only memory. > > Yes, and also undetectable because it isn't in the data area of the card. > > > > > > > +CC devel@ for general XO-1.5 and SD card interest. > > > > > > References: > > > > > > 1. > > > https://www.jedec.org/news/pressreleases/jedec-announces-publication- > > > emmc-standard-update-v50 > > > > > > 2. > > > http://wiki.laptop.org/go/Firmware/Storage#How_to_quickly_erase_everyt > > > hing > > > (but use http://wiki.laptop.org/go/Firmware/Storage#devalias_fsdisk > > > first) > > > > > > On Tue, Jul 14, 2015 at 06:34:52PM -0400, Tim Moody wrote: > > > > I have been around the block with a 128G micro sdcard allegedly from > > > > Sandisk. I made various attempts at creating two partitions and > > > > formatting them ext4, some of which progressed at the rate of > > > > 10G/hour. > > > > > > > > I finally used dd to write /dev/zero to the entire device, which took > > > > almost 24 hours. > > > > > > > > After that parted mklabel msdos and mkpart worked fine and mkfs.ext4 > > > > also worked fine in a couple of minutes. > > > > > > > > > > -- > > > James Cameron > > > http://quozl.linux.org.au/ > > -- > James Cameron > http://quozl.linux.org.au/ > > > ------------------------------ > > Message: 4 > Date: Wed, 15 Jul 2015 00:47:10 -0400 > From: Samuel Greenfeld <sam...@greenfeld.org> > To: xsce-devel <xsce-de...@googlegroups.com> > Cc: XS Devel <server-de...@lists.laptop.org>, OLPC Devel > <devel@lists.laptop.org> > Subject: Re: [XSCE] sdcard for /opt and /library on xo 1.5 > Message-ID: > < > ca+caqjpjfsmhxeiaq++orexdn73ds8u2trpslxqd+g6vw75...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Would periodically erasing SD cards and eMMC storage help to extend their > useful life? Or is this potentially dangerous for chips known to be used > which implement these instructions incorrectly? > > A few years ago, XO firmware would erase the SD card prior to running > fs-update. But if I recall correctly this was disabled because it caused > certain SD cards to hang. > > It might also be possible to enable the eMMC equivalent of TRIM in XO > software builds provided XO eMMC's don't accidentally discard the wrong > block. > > > > > On Wed, Jul 15, 2015 at 12:09 AM, James Cameron <qu...@laptop.org> wrote: > > > On Tue, Jul 14, 2015 at 11:49:29PM -0400, Tim Moody wrote: > > > I think the bottom line is that on this xo1.5 I need to use a usb thumb > > > drive instead of this micro sdcard and its holder. > > > > > > > -----Original Message----- > > > > From: xsce-de...@googlegroups.com [mailto:xsce- > > > > de...@googlegroups.com] On Behalf Of James Cameron > > > > Sent: Tuesday, July 14, 2015 8:14 PM > > > > To: Tim Moody > > > > Cc: server-de...@lists.laptop.org; devel@lists.laptop.org; xsce- > > > > de...@googlegroups.com > > > > Subject: Re: [XSCE] sdcard for /opt and /library on xo 1.5 > > > > > > > > G'day Tim, > > > > > > > > Thanks, that's interesting. > > > > > > > > My best guess is you have a bad connector and the 24-hour thermal > test > > you > > > > did fixed it. The problem may return. > > > > > > > > Another guess is that the card has the production state awareness > > feature > > > > [1], part of e.MMC v5.0, which uses the storage cells differently > > before > > > they > > > > are enabled for normal use. The state can be changed with suitable > > tools, > > > or > > > > will clear itself once enough data is written; followed by a power > > cycle. > > > The > > > > result is a sudden increase in performance after that power cycle. > > > > > > > interesting ideas. I have no way of judging either. > > > > > > My guess is that I tried so many different ways of partitioning it from > > > fdisk to parted that it was so messed up that an xo 1.5, a nuc, and a > > dell > > > all found it corrupt, compounded by the fact that systemd has it in use > > even > > > if it is not actually mounted. > > > > Yes, it sounds like you lost track of the provenance. > > > > At heart though, an SD card is just a set of blocks, so I always make > > a copy of it before writing. The copy usually compresses really well > > for permanent storage. > > > > > > > > The sdcard holder is also looking pretty suspect as used with the card > > slot > > > on the xo. I put the micro sd in the holder back into the xo 1.5 and > it > > > reported two devices with pttype of "dos", but gave unknown file system > > when > > > I tried to mount > > > > > > -bash-4.2# mount > > > /dev/mmcblk1p1 on /bootpart type ext4 > (rw,relatime,user_xattr,barrier=1) > > > /dev/mmcblk1p2 on / type ext4 > > (rw,noatime,user_xattr,barrier=1,data=ordered) > > > devtmpfs on /dev type devtmpfs > > > (rw,nosuid,relatime,size=475460k,nr_inodes=118865,mode=755) > > > /dev/mmcblk1p2 on /home type ext4 > > > (rw,relatime,user_xattr,barrier=1,data=ordered) > > > /dev/mmcblk1p2 on /versions type ext4 > > > (rw,relatime,user_xattr,barrier=1,data=ordered) > > > /dev/mmcblk1p1 on /security type ext4 > (rw,relatime,user_xattr,barrier=1) > > > proc on /proc type proc (rw,relatime) > > > sysfs on /sys type sysfs (rw,relatime) > > > tmpfs on /dev/shm type tmpfs (rw,relatime,size=51200k) > > > devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620) > > > tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) > > > tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755) > > > cgroup on /sys/fs/cgroup/systemd type cgroup > > > > > > (rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgro > > > ups-agent,name=systemd) > > > cgroup on /sys/fs/cgroup/cpu type cgroup > > > (rw,nosuid,nodev,noexec,relatime,cpu) > > > systemd-1 on /proc/sys/fs/binfmt_misc type autofs > > > (rw,relatime,fd=27,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) > > > hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime) > > > debugfs on /sys/kernel/debug type debugfs (rw,relatime) > > > mqueue on /dev/mqueue type mqueue (rw,relatime) > > > vartmp on /var/tmp type tmpfs (rw,relatime,size=51200k) > > > /tmp on /tmp type tmpfs (rw,relatime,size=204800k) > > > none on /var/lib/stateless/writable type tmpfs > > > (rw,relatime,size=4096k,nr_inodes=2048) > > > none on /var/cache/man type tmpfs > (rw,relatime,size=4096k,nr_inodes=2048) > > > none on /var/lib/xkb type tmpfs (rw,relatime,size=4096k,nr_inodes=2048) > > > none on /var/cache/httpd/ssl type tmpfs > > > (rw,relatime,size=4096k,nr_inodes=2048) > > > none on /var/cache/httpd/proxy type tmpfs > > > (rw,relatime,size=4096k,nr_inodes=2048) > > > none on /var/cache/php-pear type tmpfs > > > (rw,relatime,size=4096k,nr_inodes=2048) > > > none on /var/lib/dav type tmpfs (rw,relatime,size=4096k,nr_inodes=2048) > > > none on /var/lib/dhclient type tmpfs > > (rw,relatime,size=4096k,nr_inodes=2048) > > > none on /etc/adjtime type tmpfs (rw,relatime,size=4096k,nr_inodes=2048) > > > none on /var/lib/logrotate.status type tmpfs > > > (rw,relatime,size=4096k,nr_inodes=2048) > > > none on /var/spool type tmpfs (rw,relatime,size=4096k,nr_inodes=2048) > > > /dev/mmcblk1p1 on /etc/ssh type ext4 (rw,relatime,user_xattr,barrier=1) > > > /dev/mmcblk1p1 on /var/lib/dbus type ext4 > > (rw,relatime,user_xattr,barrier=1) > > > /dev/mmcblk1p1 on /var/lib/random-seed type ext4 > > > (rw,relatime,user_xattr,barrier=1) > > > /dev/mmcblk1p1 on /etc/NetworkManager/system-connections type ext4 > > > (rw,relatime,user_xattr,barrier=1) > > > /dev/sda2 on /library type ext4 > > > (rw,noatime,user_xattr,barrier=1,data=ordered) > > > /dev/sda1 on /opt type ext4 > > (rw,noatime,user_xattr,barrier=1,data=ordered) > > > (sda is a usb thumbdrive) > > > > > > -bash-4.2# blkid > > > /dev/sda1: UUID="20d7ab6c-ec76-4fc3-a702-75c0051b5ce6" TYPE="ext4" > > > /dev/sda2: UUID="e1c0ef6a-dc89-4d46-bcef-7b19360d41f7" TYPE="ext4" > > > /dev/mmcblk0p1: UUID="de889f2b-fffb-4a45-8358-dce449f2cf7e" TYPE="ext4" > > > /dev/mmcblk0p2: UUID="0ad6a5ee-bc3d-4fc6-8b9b-ca9bc456cb74" TYPE="ext4" > > > /dev/mmcblk1p1: LABEL="Boot" > UUID="ac3c6c0f-8350-47ab-a308-42d49652f030" > > > TYPE="ext2" > > > /dev/mmcblk1p2: LABEL="OLPCRoot" > > UUID="61a34c92-0f69-409d-9b61-23a5522d296d" > > > TYPE="ext4" > > > /dev/mmcblk0: PTTYPE="dos" > > > /dev/mmcblk1: PTTYPE="dos" > > > > > > -bash-4.2# mkdir /mnt/sdcard > > > -bash-4.2# mount /dev/mmcblk0 /mnt/sdcard > > > mount: unknown filesystem type '(null)' > > > > Expected. You should have been trying /dev/mmcblk0p1 or p2. Without > > p1 or p2 it is the overall device, usually not a partition. > > > > > > > > But when I put the micro sdcard into my usb adapter and plugged that > into > > > the xo 1.5 I see > > > > > > -bash-4.2# ll /dev/sde* > > > brw-rw---- 1 root disk 8, 64 Jul 15 2015 /dev/sde > > > brw-rw---- 1 root disk 8, 65 Jul 15 2015 /dev/sde1 > > > brw-rw---- 1 root disk 8, 66 Jul 15 2015 /dev/sde2 > > > > > > and /dev/sde1 automounted on /media/usb0 > > > > Ok. > > > > > > > > I tried another holder from nexxtech and got the same result as the > > sandisk > > > one. > > > > > > > Suggestions: > > > > > > > > - next time you want to erase a card, send it the erase command, > which > > > > takes between three and fifteen seconds in my tests [2], > > > > > > you mentioned erase before, but I couldn't find it. the googling I did > > only > > > mentioned using dd to erase. > > > > > > [root@schoolserver zims]# which erase > > > /usr/bin/which: no erase in > > > > > > (/usr/local/sbin:/usr/sbin:/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/u > > > sr/bin:/root/bin) > > > > The link supplied in [2] was for Open Firmware, and I've not studied > > how to do the same in Linux. It would be really annoying to do it by > > accident. > > > > > > > > > > - test the communications between the system and the card by > measuring > > > > the sequential read performance; this is usually the easiest way to > > > > test communications, > > > > > > not sure I had anything to read as I never had a file system. > > > > The card is an array of blocks, so you can always read them; > > > > su > > sync > > echo 1 > /proc/sys/vm/drop_caches > > dd if=/dev/mmcblk0 of=/dev/null bs=1M count=256 > > > > A data rate will be printed by dd. That will give you a performance > > measurement that is never more than the actual performance, and > > occasionally less. > > > > > > - try on a different XO-1.5, in case you have a faulty XO-1.5, and > > > > raise doubts if the performance differs, > > > > > > only have the one > > > > > > > > - try on a modern desktop system; that will isolate the problem to > > > > interoperability with the XO-1.5, > > > > > > even I thought of this. in fact I saw differences between fedora 22 > (my > > > NUC) and fedora 20 (my old Dell). It was fedora 20 on which I did > > anything > > > useful including the zeroing. I guess the subject line of my email is > > > misleading in this regard. > > > > > > > > - identify the kernel, in case you have a version that doesn't > > > > properly switch to 1.8V; if so, the slot on the XO-1.5 will run it > > > > at 3.3V, warm, and so the card firmware will intentionally slow the > > > > transfers to ensure compliance with thermal specifications, > > > > > > > > - try reseating the card in the adapter, and the adapter in the > > > > system, because a bad connection can show up as slow data rate, > then > > > > re-test the communications, > > > > > > this is a possible factor in that I used a usb adapter for the micro sd > > more > > > successfully than the holder > > > > Also by using USB adapter you are offloading some of the > > communications work to a processor in the adapter. > > > > The electrics of the adapter might also be a better match. > > > > > > > > > > - if available, use uninit_bg when calling mke2fs, so that the > > > > "formatting" doesn't have to write much, > > > > > > > > - publish the dmesg fragment showing the card being detected. > > > > > > > > When thinking about problems with SD card, it is best to imagine it > as > > a > > > > separate computer, in which you can't change the software. There's > no > > > > telling what it will do. ;-) They are very complex systems, made to > > look > > > > simple. Plug and play, dumbing down. > > > > > > and apparently the home of a new class of virus, undetectable due to > the > > > fact that the os is stored in write-only memory. > > > > Yes, and also undetectable because it isn't in the data area of the card. > > > > > > > > > > +CC devel@ for general XO-1.5 and SD card interest. > > > > > > > > References: > > > > > > > > 1. > > > > > https://www.jedec.org/news/pressreleases/jedec-announces-publication- > > > > emmc-standard-update-v50 > > > > > > > > 2. > > > > > http://wiki.laptop.org/go/Firmware/Storage#How_to_quickly_erase_everyt > > > > hing > > > > (but use http://wiki.laptop.org/go/Firmware/Storage#devalias_fsdisk > > > > first) > > > > > > > > On Tue, Jul 14, 2015 at 06:34:52PM -0400, Tim Moody wrote: > > > > > I have been around the block with a 128G micro sdcard allegedly > from > > > > > Sandisk. I made various attempts at creating two partitions and > > > > > formatting them ext4, some of which progressed at the rate of > > > > > 10G/hour. > > > > > > > > > > I finally used dd to write /dev/zero to the entire device, which > took > > > > > almost 24 hours. > > > > > > > > > > After that parted mklabel msdos and mkpart worked fine and > mkfs.ext4 > > > > > also worked fine in a couple of minutes. > > > > > > > > > > > > > -- > > > > James Cameron > > > > http://quozl.linux.org.au/ > > > > -- > > James Cameron > > http://quozl.linux.org.au/ > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.laptop.org/pipermail/devel/attachments/20150715/02d447bb/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > > > ------------------------------ > > End of Devel Digest, Vol 112, Issue 3 > ************************************* >
_______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel