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