[Sugar-devel] Hello, was Re: Hack to get a USB/SD to autologin to only "Sugar-desktop on a stick". from a F12-alpha live CD

[Douglas McClendon]

Martin Langhoff wrote:
> On Thu, Sep 10, 2009 at 12:11 PM, Douglas McClendon
> <dmc.sugar at filteredperception.org> wrote:
>> Basically if these tests are against installed systems, I really don't have
>> anything useful to add.  But if this involves LiveOS style boot with overlay,
>> then I still don't have much to add other than I assume/hope your tests don't
>> trigger overlay exhaustion and confuse that with media error.
> 
> Those tests are on NAND flash, without an FTL, direct MTD and JFFS2 or UBIFS.
> 
> I do have a couple of questions for you re diagnosing the issues we've seen.
> 
>  - During boot, how early is the overlay being mounted (initramfs?)

Yes.  Also, there is probably room for clearer terminology.  I.e. the overlay 
in question here is a a device (or device image on loopback accessed file), 
which gets combined with a base device, into a virtual device.  These loops are 
indeed set up, and combined with devicemapper, in the initramfs at precisely 
the time when a normal initramfs would be mounting the real rootfs.  I.e. once 
it is put together, it is then mounted as the real rootfs.

> and could something be done to fail more gracefully if the overlay is
> found to be corrupt? Hints to what code is controlling this would be
> great.

I think the relevent code may have somewhat recently moved from the 
livecd-tools package, to the mkinitramfs/dracut package.  I.e. in f10 which I'm 
currently looking at, you want to look at /usr/libexec/mkliveinitrd in the 
mkinitrd package.  But for f12 thats probably in dracut somewhere.  In either 
you probably want to search for 'dmsetup' calls which create the virtual root 
device from the base and overlay devices(files).

Yes, there may be room to detect and handle problems better there.


> 
>  - When we do have LiveUSB that refuses to boot, what fs is in the
> overlay? The 'livecd' tools that create the overlay just dd the file.
> It all seems to be internal to the Linux kernel -- if it is a FS in
> disguise, we could fsck it...

Again, it is a devicemapper snapshot device, which last I looked was rather 
tragically inadequately documented in the devicemapper documentation, (actually 
maybe that was the devicemapper mirror device I use for rebootless 
installation.  hopefully all are better documented by now).

And a normal ext4fs lives in the virtual device.  I.e. the overlay is just 
that, an overlay, like a partially transparent tablecloth on a table.  I.e. the 
table is really holding the food up, and the tablecloth by itself is quite useless.

Yes you can fsck the resultant virtual device, though perhaps this relates to 
what I read in I think the most recent lwn about how raid/ssd/flash corruption, 
because it works in 'megablocks' can trash your fs rather much more badly than 
usual filesystem corruption.

Also, there may be room to fsck that housing filesystem, i.e. the vfat or 
whatever fs is actually on the stick that contains the various components of 
the virtual rootfs.  That gets to my other post asking about how fsck.vfat 
seems to be ignoring me.

Finally, as you might gather from above, despite GDK's generous and amusing 
'GodFather' comment, I haven't been following closely the most recent 
developments with livecd tools, i.e. in case maybe they've already implemented 
some of these things.  But those places I mentioned are where you would find out.


> 
> With this kind of info, we can hopefully do more valuable testing & diagnosis...

I hope I lessen the overall confusion/complexity rather than add to it :)

-dmc


> 
> cheers,
> 
> 
> 
> m