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

Kevin Gordon kgordon420 at gmail.com
Wed Jul 15 10:14:01 EDT 2015 

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 <tim at timmoody.com> wrote:
>
>
>> -----Original Message-----
>> From: Jerry Vonau [mailto:me at jvonau.ca]
>> Sent: Wednesday, July 15, 2015 3:56 AM
>> To: xsce-devel at googlegroups.com; Tim Moody
>> Cc: devel at lists.laptop.org; server-devel at lists.laptop.org
>> Subject: RE: [XSCE] sdcard for /opt and /library on xo 1.5
>>
>>
>>
>> > On July 14, 2015 at 10:49 PM Tim Moody <tim at timmoody.com> 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: 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
>> > 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 at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20150715/97383930/attachment.html>

More information about the Devel mailing list