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

Tim Moody tim at timmoody.com
Tue Jul 14 23:49:29 EDT 2015

I think the bottom line is that on this xo1.5 I need to use a usb thumb
drive instead of this micro sdcard and its holder.

> -----Original Message-----
> From: xsce-devel at googlegroups.com [mailto:xsce-
> devel at googlegroups.com] On Behalf Of James Cameron
> Sent: Tuesday, July 14, 2015 8:14 PM
> To: Tim Moody
> Cc: server-devel at lists.laptop.org; devel at lists.laptop.org; xsce-
> devel at googlegroups.com
> Subject: Re: [XSCE] sdcard for /opt and /library on xo 1.5
> G'day Tim,
> Thanks, that's interesting.
> My best guess is you have a bad connector and the 24-hour thermal test you
> did fixed it.  The problem may return.
> Another guess is that the card has the production state awareness feature
> [1], part of e.MMC v5.0, which uses the storage cells differently before
> are enabled for normal use.  The state can be changed with suitable tools,
> will clear itself once enough data is written; followed by a power cycle.
> 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
/dev/mmcblk1p2 on /home type ext4
/dev/mmcblk1p2 on /versions type ext4
/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
cgroup on /sys/fs/cgroup/cpu type cgroup
systemd-1 on /proc/sys/fs/binfmt_misc type autofs
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
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
none on /var/cache/httpd/proxy type tmpfs
none on /var/cache/php-pear type tmpfs
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
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
/dev/mmcblk1p1 on /etc/NetworkManager/system-connections type ext4
/dev/sda2 on /library type ext4
/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"
/dev/mmcblk1p2: LABEL="OLPCRoot" UUID="61a34c92-0f69-409d-9b61-23a5522d296d"
/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

> 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 at schoolserver zims]# which erase
/usr/bin/which: no erase in
> - 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/

More information about the Devel mailing list