Re: [XSCE] sdcard for /opt and /library on xo 1.5

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [XSCE] sdcard for /opt and /library on xo 1.5

James Cameron-2
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/
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

RE: [XSCE] sdcard for /opt and /library on xo 1.5

Tim Moody
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:xsce-
> [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/
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [XSCE] sdcard for /opt and /library on xo 1.5

James Cameron-2
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:xsce-
> > [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/
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [XSCE] sdcard for /opt and /library on xo 1.5

Samuel Greenfeld-2
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/


_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [XSCE] sdcard for /opt and /library on xo 1.5

James Cameron-2
On Wed, Jul 15, 2015 at 12:47:10AM -0400, Samuel Greenfeld wrote:
> Would periodically erasing SD cards and eMMC storage help to extend
> their useful life?

No, I don't think so.  Nor would it hurt their life.  It is just a few
writes to metadata mapping tables kept in a different physical area of
the device.  (The tables relate virtual block numbers used by the host
to physical pages used by the device.)

> Or is this potentially dangerous for chips known to be used which
> implement these instructions incorrectly?

Doesn't seem likely, but good point; there may exist a set of devices
that implement the command incorrectly.

Although the same could be said for other corner cases, like writing a
block in the last position of a page after the page has triggered the
read disturb rewrite handler.

Hopefully the test suites will have caught both scenarios.

> 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.

If I recall correctly it was because certain SD cards would refuse the
command; they didn't really hang, they just gave an error.

While investigating we found that the erasure was only covering a tiny
part of the device block numbers (our mistake), so it wasn't being
effective anyway.

We didn't want to increase the time taken to fs-update, so we removed
it.

We also switched from linear to sparse input files.

> 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.

Yes.  TRIM is like ERASE except the device is not obligated to return
a block of zeros.

Both become a write to the mapping table.

Acting on the wrong block seems unlikely though.

A secure ERASE is different; in addition to a mapping table write they
also COPY the page less any unerased blocks and then do an erase page.

I guess writing zero to all blocks might not erase any page; it might
instead just write to the mapping table to map each block to a zero
page.

--
James Cameron
http://quozl.linux.org.au/
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

RE: [XSCE] sdcard for /opt and /library on xo 1.5

Tim Moody
In reply to this post by James Cameron-2


> -----Original Message-----
> From: Jerry Vonau [mailto:[hidden email]]
> Sent: Wednesday, July 15, 2015 3:56 AM
> To: [hidden email]; Tim Moody
> Cc: [hidden email]; [hidden email]
> Subject: RE: [XSCE] sdcard for /opt and /library on xo 1.5
>
>
>
> > On July 14, 2015 at 10:49 PM Tim Moody <[hidden email]> 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.
> >
>
> For what it's worth I've never had much luck using micro/SD adapters in
> general.
> If I recall correctly the 1.5's internal micro card is held in a replaceable holder,
> might be just plain easier to replace that one with the larger card and not
> have the filesystem dangling out the side of the XO. ;) The XO's image file will
> resize to fit the larger card but you'd have skip the custom partitioning

Very interesting idea.  James?

> proposed.
>
> Hope it helps,
>
> Jerry
>
>
>
>
> > > -----Original Message-----
> > > From: [hidden email] [mailto:xsce-
> > > [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/system
> > d-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/s
> > bin:/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_ever
> > > yt
> > > 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/
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [XSCE] sdcard for /opt and /library on xo 1.5

Kevin Gordon Gmail
We too had issues with various combinations of micro SD in adapters on the 1.5' slots. Ended up having to use older Class 4, 8GB micros. Original SanDisk, with original SanDisk adapters. Even then, we had about a 10% failure rate on the adapters. We had poor luck using higher capacity, higher class cards, and no luck using non-SanDisk ebay sourced adapters.

Just for clarity, we also used the same cards with adapters on XO-1's too, but only for swap and static library/book content. We never used the 'external' SD slot on either platform as load-source/boot, or for the main file system.  

However, we were also able to use the same SanDisk class 4 8GB micro SD cards, without adapters of course, internally in the XO 1.5's as main storage. We were unsuccessful in finding reliable larger, newer, higher class cards to work there either.

KG

On Wednesday, July 15, 2015, Tim Moody <[hidden email]> wrote:

>
>
>> -----Original Message-----
>> From: Jerry Vonau [mailto:[hidden email]]
>> Sent: Wednesday, July 15, 2015 3:56 AM
>> To: [hidden email]; Tim Moody
>> Cc: [hidden email]; [hidden email]
>> Subject: RE: [XSCE] sdcard for /opt and /library on xo 1.5
>>
>>
>>
>> > On July 14, 2015 at 10:49 PM Tim Moody <[hidden email]> 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.
>> >
>>
>> For what it's worth I've never had much luck using micro/SD adapters in
>> general.
>> If I recall correctly the 1.5's internal micro card is held in a replaceable holder,
>> might be just plain easier to replace that one with the larger card and not
>> have the filesystem dangling out the side of the XO. ;) The XO's image file will
>> resize to fit the larger card but you'd have skip the custom partitioning
>
> Very interesting idea.  James?
>
>> proposed.
>>
>> Hope it helps,
>>
>> Jerry
>>
>>
>>
>>
>> > > -----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/system
>> > d-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/s
>> > bin:/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_ever
>> > > yt
>> > > 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/
>
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [XSCE] sdcard for /opt and /library on xo 1.5

James Cameron-2
In reply to this post by Tim Moody
On Wed, Jul 15, 2015 at 09:27:49AM -0400, Tim Moody wrote:

>
>
> > -----Original Message-----
> > From: Jerry Vonau [mailto:[hidden email]]
> > Sent: Wednesday, July 15, 2015 3:56 AM
> > To: [hidden email]; Tim Moody
> > Cc: [hidden email]; [hidden email]
> > Subject: RE: [XSCE] sdcard for /opt and /library on xo 1.5
> >
> >
> >
> > > On July 14, 2015 at 10:49 PM Tim Moody <[hidden email]> 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.
> > >
> >
> > For what it's worth I've never had much luck using micro/SD
> > adapters in general.  If I recall correctly the 1.5's internal
> > micro card is held in a replaceable holder, might be just plain
> > easier to replace that one with the larger card and not have the
> > filesystem dangling out the side of the XO. ;) The XO's image file
> > will resize to fit the larger card but you'd have skip the custom
> > partitioning
>
> Very interesting idea.  James?

Me?  It will void your warranty.  Oh, wait.  Already out of warranty.
;-)

Yes, the XO-1.5 internal storage is microSD card in a cage, accessible
after disassembly of back panel.

http://wiki.laptop.org/go/Disassembly
http://wiki.laptop.org/go/Disassembly_top

Test the microSD card in the SD slot first; to make sure firmware can
operate with it.  No point if that won't work.

http://wiki.laptop.org/images/f/f0/XO_1.5_B1_Annotated_Motherboard.png

In that image, the cage is in locked position.  Record what you find,
especially the length of the card exposed to the right of the shiny
metal.

Failing to lock it afterwards will cause unpredictable behaviour;
thermal cycles and vibration may set the card adrift in the case.

To unlock, push the cage to the right with a force parallel to the
board.

To open, lift the left edge.

Remove and replace the card.  (Continue to use ESD precautions on
these microSD cards, they are vulnerable).

Lower the left edge then push the cage to the left, with a force
parallel to the board, until (a) you have felt a click, and (b) you
see the same exposed width of the card.

Then with the system still disassembled, try an fs-update, and then
try booting at least ten times.

Yes, the filesystem should resize on first boot.  13.2.5 will quickly
resize to 16 GB, but beyond that it will take quite some time.  Use
the tick (check) key on first boot and watch the storage indicator so
you can tell what it is doing.

--
James Cameron
http://quozl.linux.org.au/
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel