Hi, > - several people think we should be trying to do a full > filesystem resize at boot -- advantage is that we can ship a > single image, and have it work on all SD cards. requires a > splash screen (which should be a good one, with seamless > transition -- this may be the first user experience), and adds > some risk to the boot process. first linux boot happens at the > factory for new laptops, but in the child's hands in most > deployment scenarios (where nandblaster or usb sticks are used).
I still like the flexibility here, but I suspect you're right that the support cost from doing a long resize at the first boot in front of a user (and having corruption result from a poweroff) will be too high. > - several people think we should separate the base OS from > the user data, by giving /home a separate partition. how would > we size the root fs? having a hard constraint that we must fit > into wouldn't be bad thing, as long as we don't pick an > unreasonably small value, and as long as there's a fallback plan > when we blow it. olpc-update may double the space requirement in > the worst case, right? i've never used LVM -- could it help make > the boundary moveable? I don't think we should add this feature into the mix yet, because I disagree that it wouldn't be bad -- we don't know whether a user prefers to create their own content in /home, or mainly to install new applications with yum, so we shouldn't decide for them by setting an artificial size on / vs. /home that they can't change easily. (If there were a way to have yum and rpm install to /home, that might get around this objection, but I don't think it's possible.) I'm not sure that LVM helps here: I don't think it can do online shrinking, so it would have to queue up a boundary change for the next reboot. We'd then have to teach OFW about LVM, and make OFW image reflashes honor the LVM boundary else they'll stomp over /home, which is what we were trying to avoid. > - we could put resize-at-boot code in place (with or without > a splash screen), and ship multiple, somewhat undersized images. > any image could be used on any bigger SD card, and the right > thing would happen, but in the usual case, where an image is > correctly sized, the resize time wouldn't take too long. perhaps > we could suppress the splash screen for resizes that we think > won't take too long? This is sounding more likely. Perhaps I should kick off a build with both images ~100M smaller, so we can see exactly how long it takes to do a near-resize? Do we think ~50M smaller for each would be enough to cover all of the 2G and 4G SD cards we might run into? > - we could make the resizing a manual step, from the control > panel or elsewhere. we sort of need a simple disk management > screen anyway. I'm not sure what to think about a disk management control panel; I think our mental model of control panel users should approximate "will press control panel buttons with no particular rationale", so we should keep any dangerous or non-revertable actions away. > (btw, regardless of our decision, this is clearly more than a > simple bug fix.) Yeah, agreed. Thanks, - Chris. -- Chris Ball <[email protected]> One Laptop Per Child _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
