Devel Digest, Vol 112, Issue 3
Juan Carlos Camareno Huamán
jchcamareno at gmail.com
Wed Jul 15 01:39:57 EDT 2015
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 <devel-request at lists.laptop.org>:
> Send Devel mailing list submissions to
> devel at lists.laptop.org
>
> 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
> devel-request at lists.laptop.org
>
> You can reach the person managing the list at
> devel-owner at lists.laptop.org
>
> 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 <quozl at laptop.org>
> To: Tim Moody <tim at timmoody.com>
> 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
> Message-ID: <20150715001340.GF21632 at us.netrek.org>
> 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 <tim at timmoody.com>
> To: <xsce-devel at googlegroups.com>
> Cc: server-devel at lists.laptop.org, devel at lists.laptop.org
> Subject: RE: [XSCE] sdcard for /opt and /library on xo 1.5
> Message-ID: <BLU405-EAS3406E6198351B4225C603ACC59A0 at phx.gbl>
> 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: 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/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 at 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 <quozl at laptop.org>
> To: xsce-devel at googlegroups.com
> Cc: server-devel at lists.laptop.org, devel at lists.laptop.org
> Subject: Re: [XSCE] sdcard for /opt and /library on xo 1.5
> Message-ID: <20150715040916.GP21632 at us.netrek.org>
> 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: 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.
>
> 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 at 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 <samuel at greenfeld.org>
> To: xsce-devel <xsce-devel at googlegroups.com>
> Cc: XS Devel <server-devel at lists.laptop.org>, OLPC Devel
> <devel at lists.laptop.org>
> Subject: Re: [XSCE] sdcard for /opt and /library on xo 1.5
> Message-ID:
> <
> CA+cAqjPJfsMhXeiAQ++OrEXDN73dS8u2TrPSLxQd+G6vw757Xg at mail.gmail.com>
> 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 <quozl at laptop.org> 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: 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.
> >
> > 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 at 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
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
>
> ------------------------------
>
> End of Devel Digest, Vol 112, Issue 3
> *************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20150715/6328e7af/attachment.html>
More information about the Devel
mailing list