Re: Devel Digest, Vol 112, Issue 3

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: Devel Digest, Vol 112, Issue 3

Juan Carlos Camareno Huamán
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 <[hidden email]>:
Send Devel mailing list submissions to
        [hidden email]

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
        [hidden email]

You can reach the person managing the list at
        [hidden email]

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 <[hidden email]>
To: Tim Moody <[hidden email]>
Cc: [hidden email], [hidden email],
        [hidden email]
Subject: Re: [XSCE] sdcard for /opt and /library on xo 1.5
Message-ID: <[hidden email]>
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 <[hidden email]>
To: <[hidden email]>
Cc: [hidden email], [hidden email]
Subject: RE: [XSCE] sdcard for /opt and /library on xo 1.5
Message-ID: <[hidden email]>
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: [hidden email] [mailto:[hidden email]
> [hidden email]] On Behalf Of James Cameron
> Sent: Tuesday, July 14, 2015 8:14 PM
> To: Tim Moody
> Cc: [hidden email]; [hidden email]; xsce-
> [hidden email]
> 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 <[hidden email]>
To: [hidden email]
Cc: [hidden email], [hidden email]
Subject: Re: [XSCE] sdcard for /opt and /library on xo 1.5
Message-ID: <[hidden email]>
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: [hidden email] [mailto:[hidden email]
> > [hidden email]] On Behalf Of James Cameron
> > Sent: Tuesday, July 14, 2015 8:14 PM
> > To: Tim Moody
> > Cc: [hidden email]; [hidden email]; xsce-
> > [hidden email]
> > 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 <[hidden email]>
To: xsce-devel <[hidden email]>
Cc: XS Devel <[hidden email]>, OLPC Devel
        <[hidden email]>
Subject: Re: [XSCE] sdcard for /opt and /library on xo 1.5
Message-ID:
        <[hidden email]>
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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]
> > > [hidden email]] On Behalf Of James Cameron
> > > Sent: Tuesday, July 14, 2015 8:14 PM
> > > To: Tim Moody
> > > Cc: [hidden email]; [hidden email]; xsce-
> > > [hidden email]
> > > 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
[hidden email]
http://lists.laptop.org/listinfo/devel


------------------------------

End of Devel Digest, Vol 112, Issue 3
*************************************


_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel