[Novalug] basic Q's about flash boot of live CD

Bryan J Smith b.j.smith@ieee.org
Wed Mar 24 10:52:45 EDT 2010


First off, I was hoping the "red Fedora" comment would get
a few to pipe up. Paul, you don't even have a tenth of my technically
"opinionated attitude" (either you mispelled that as "skill" or that's
the best joke of 2010 so far - might as well have come from Alan
or Andrew, same difference ;).  So when I start beating the dead
horse, especially when I am forward and admit some ignorance,
it's always good to step in a verify some things while pointing
out other things.  And by "ignorant," I mean I haven't pulled it
apart, like I did Mayflower, post-Mayflower F9/F10, or modes and
options I overlooked or did not dive into.

Secondly, and I think we're pretty consenual on this point, users
should be updating their images every month or two.  I have had
several people complain about "yum update" failing, over and over,
and I'd just re-send them to the HOWTO and show them the builder
tool.  I wasn't aware it had evolved into a full overlay, capable of
things, and always defaulted showing people how to rebuild
images.  I still run into many people who download the Live ISO from
the time of release, many months later, and then try to yum update.
Just horrendous practice, and why I adamant on "no, it's not just
like a hard drive.". People need to be made aware that it's a pre-made,
read-only system image.  I beat that like a dead horse.

Third, this crosses one of my pet peeves as well, so I beat that
horse even more - commodity NAND EEPROM failure rates.
Now  am still ignorant of how writes may be coalesced to the
persistent area, and really need to graduated my "old dog" NOR
JFFS2 approaches to modern Linux NAND overlayed Ext2
with device-transparent wear-leveling.  But if you ask 9 out of
10 IT professionals, they will assume NAND EEPROM power,
failure rates and other things are better than 1.8" and 2.5"
disks.  The failure rates are still worse than 1.8"/2.5" (although
not over an order of magnitude like they were in 2008-2009,
although some was helped by more read-only OS images being shipped).
The rates are even far worse for cheap NAND EEPROM
USB dongles.
I wouldn't say this if I haven't seen this over and over,
even into 2010.

Fourth, the point that browser temp files, like cache, are worse
than updating binaries could be true if we're not either mapping to
tmpfs or the persistent/disk cache disabled in prefs.js.  This is
now definitely driving my interest to play with a Rawhide build dongle,
trace and stap operations to see VM and block operations,
to find out if we need a package for configuring root and skel to
enable such.  I bet I'm not the only person who's thought of this,
so I'm curious to find out what was done. Maybe it's realated
to how the overlays are done, with writes coalesced.  If not, then
I'm wondering what could be done.  I've done patches for this before
(although most were not accepted upstream due to "new 
developments," long story).

Thanx for the [implicitly] solicited input, and I'm going to have some
fun the next two weekends pulling this stuff apart even more than
the couple of hours I've done so far.

--  
Bryan J Smith - mailto:b.j.smith@ieee.org  
http://www.linkedin.com/in/bjsmith
Sent via BlackBerry from T-Mobile  
    

-----Original Message-----
From: "Paul W. Frields" <stickster@gmail.com>
Date: Wed, 24 Mar 2010 09:09:22 
To: <novalug@calypso.tux.org>
Subject: Re: [Novalug] basic Q's about flash boot of live CD

On Tue, Mar 23, 2010 at 09:22:31PM -0700, Bryan J. Smith wrote:
> Allow me to step back ...
> 
> 
> First off, "the big deal" is because of first-hand experience.  Since I
> "have a red Fedora," people love to bark at me.  I've had _so_many_
> people complain they can't update Fedora 9, 10, 11, etc... on their USB
> stick.  I quick discover they are running "yum update" on the stick itself.
> 
> That's when I point them at the builder tool.  Most work with that and,
> no, most users have _no_problem_ using it.  If they can put the image
> on the USB stick in the first place, they have _no_problem_ using the
> tool to build a new squashfs.  It easy enough.
> 
> That's why I'm adamant about telling users to rebuild the image instead
> of just downloading the "release" version of the Live CD and turning it
> into a USB device and running "yum update" on it (and getting all those
> updates).  Teach them "The Right Way(TM)."  I would _never_ proliferate
> them to use "yum update" on the media live.  Again, that's what really
> got me going.  ;)
> 
> Secondly, every time I build a read-only image, I clean out a lot of things
> that aren't needed.  There is so much under /usr/share/ that is not, let
> alone even the RPM database will let you reclaim 10s of MiBs.  I've fit
> both RHEL 5 and Fedora 9-10 in as little as 128MiB of NAND EEPROM,
> with accessibility support.  At first I got it down to 192MiB, but eventually
> 128MiB.  Maybe that's no longer a bit deal now that NAND EEPROM has
> over quadrupled in capacity in just the last 18 or so months.  But it can
> mean a drastically reduced firmware update cycle and network traffic
> for embedded devices.  ;)
> 
> Third, as far as Gecko files, I pre-setup Gecko to use a fixed profile
> location, and the ./cache/ directory points to tmpfs.  I have been doing
> this for years.  Creating mandatory and default Firefox profiles is none-
> too-difficult.  It's one of the reasons I've been meaning to look at what
> the Live tools create, and add this if it doesn't already.
> 
> Maybe it just defaults to no disk cache, which would also work.
> 
> Lastly, I think we agree that a few packages would be just fine.  But
> I will re-iterate that if it's more than a few, one should be rebuilding
> the image.  And, again, if an user can figure out how to put it to the
> USB device, then they don't have a problem using the tool.  I didn't
> understand that argument one bit.
> 
> This goes back to the first part, where people assume the Live USB is
> just "like a hard drive."  It's not.  It shouldn't be either, at least not with
> today's NAND EEPROM lifespan (which is absolutely atrocious and still
> results in NAND EEPROM device failure rates in excess of 2.5" disk
> failure rates, sadly enough).  Using NAND EEPROM as read-only as
> possible, not doing heavy read-write changes like mass binary swap
> outs with YUM-RPM operations, is what NAND EEPROM is ideal for.
> 
> Again, I wouldn't be taking issue if I didn't feel this point wasn't being
> discarded so quickly.  ;)

I do agree re: Live USB not being just like a hard disk.  However,
IIRC some allowance has been made for how yum operates, and the
downloading and other caching-type operations are performed in a
RAMdisk wherever possible.  I don't pretend to have a tenth of the
technical skill Bryan does, so do take this with a grain of salt,
although I remember looking into this because of Live images I was
preparing and giving out at the last Red Hat Summit.

I don't think Mozilla/Gecko does this by default, but I've seen people
who cleverly have their browser cache going to the RAMdisk and then
rsync'ing it periodically.

I've used Live USB sticks for protracted periods -- not six months
mind you, but for weeks at a time when it was appropriate, and
updating them as I go.  Provided the overlay isn't tiny they hold up
pretty well, although I'd probably not trust my entire life to a USB
key that I wasn't backing up regularly somewhere more reliable.


-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
          Where open source multiplies: http://opensource.com
_______________________________________________
Novalug mailing list
Novalug@calypso.tux.org
http://calypso.tux.org/mailman/listinfo/novalug


More information about the Novalug mailing list