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

Tim Moody tim at timmoody.com
Wed Jul 15 09:27:49 EDT 2015 


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

More information about the Devel mailing list