Re: OFW sad face doesn't say why
On Jul 19, 2008, at 9:36 PM, John Gilmore wrote: But a certain former security wizard at OLPC removed that recommendation from the Wiki page, thus leading to your current troubles. This is untrue; please support your claims with diffs. As per: http://wiki.laptop.org/index.php?title=Activation_and_developer_keysdiff=90142oldid=89333 I removed the line 23 suggestion for one to immediately _get_ their devkey, nothing else. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OFW sad face doesn't say why
On 21.07.2008 11:53, Ivan Krstić wrote: On Jul 19, 2008, at 9:36 PM, John Gilmore wrote: But a certain former security wizard at OLPC removed that recommendation from the Wiki page, thus leading to your current troubles. This is untrue; please support your claims with diffs. As per: http://wiki.laptop.org/index.php?title=Activation_and_developer_keysdiff=90142oldid=89333 I removed the line 23 suggestion for one to immediately _get_ their devkey, nothing else. Sorry, but that's untrue, unless your definition of nothing else is political stuff. That very changeset made by you also had political edits. I would have fallen for your claim if you had not linked to the changeset which disproves it. If there was any other context attached to nothing else, you failed to make that clear. (And as a security guru, leaving ambiguities is not exactly good practice.) Regards, Carl-Daniel -- http://www.hailfinger.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OFW sad face doesn't say why
On Jul 21, 2008, at 8:38 AM, Carl-Daniel Hailfinger wrote: Sorry, but that's untrue, unless your definition of nothing else is political stuff. My definition of nothing else is nothing else relevant to the claim the poster was making. John was quite aware of the changes to the political stuff, we discussed them, I stand behind them, and I clearly wasn't trying to hide anything from anyone given that I linked to the URL. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OFW sad face doesn't say why
On Sat, Jul 19, 2008 at 9:36 PM, John Gilmore [EMAIL PROTECTED] wrote: security wizard at OLPC removed that recommendation from the Wiki page, thus leading to your current troubles. If Mikus had followed your suggestion, we would not have found this (legitimate) bug. Thank you, Mikus. It's sad watching a good team continue idiotic wrestling with how much cost, trouble, fragility and end-user hassle they can insert into a system that's required by its software licenses and its own philosophy to be wide open to alteration by its users. John, I always appreciate your loyal opposition, but I wish you would be a little more understanding that OLPC's country clients *insist* on having a theft-deterrence system in place. We are doing our best to provide this while maintaining an open system. Constructive advice toward this end is always welcome. I went to the olpc-sf physical meeting today, and tried to help a woman update her XO to something later than the G1G1 650 that she received in January. Someone had showed her yum update but that didn't actually improve anything in the UI or activities. She was at the level that's having trouble remembering to put the space in between su and -l. I absolutely failed to upgrade her -- I couldn't use any automated means like olpc-update, because it required the (%*$[EMAIL PROTECTED](@ USB-only activity upgrade, and it isn't documented what release number you can safely feed the damn thing if you don't have an Activity upgrade pack handy. I followed all the instructions on the Activity upgrade pack, and it failed on me (the un-debuggable secure update script failed to mount my USB stick and panicked, even though in a normal boot, the Journal mounts the same stick as /dev/sda1. Hasn't the author heard of the Python try statement?). Result: She's still running 650, and we'll chat again in a month at the next olpc-sf meeting. olpc-update 656. That does not require upgraded activities. The forthcoming 8.2 release will provide for automatic upgrade of activities to match; that was a feature left out of 8.1 due to time constraints, and I sympathize. I'd appreciate more details on your failure to upgrade. Both Michael and I know of the try statement, but it's not clear which of our codes failed you. Maybe it was OFW, and in that case I assure you that forth has its own equivalent of the try statement, and that Mitch uses it. The 'secure' update script (whichever one you are referring to, it's not clear) is, in fact, debuggable. Mitch, Michael, and I do so regularly. Again, with a little more information on your troubles I'd be happy to help you figure out what's going on. Morals: don't assume that your Wiki readers know anything more than the English language (or their native language). And don't make five different ways to upgrade your *(%*%^$ product, each of which only does a third of the job and either depends upon or wipes out what the other ones do. I try to use olpc-update for everything, but unfortunately our users have many different use cases, and one tool does not seem sufficient for all uses. The one thing olpc-update doesn't do is one touch upgrades; if someone can give me a good design, I'd be willing to address that. But there will likely always be at least two upgrade mechanisms: olpc-update if you've got a functioning system to start with, and in bad situtations OFW for a 'clean start' that depends on as little else as possible. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OFW sad face doesn't say why
Scott wrote (regarding me booting with the wrong develop.sig on an SD card): Do you normally use a developer key in order to boot -- ie, are you running a joyride build on BB? Is the root problem here, perhaps, that after OFW finds a develop.sig on the SD card which doesn't work, it doesn't continue to look in other places (like NAND)? Yes, I am running a joyride build on that system. This whole business of what indicators need to be placed where is a complete mystery to me. That is why I use a permanent SD card, with my develop.sig on that card -- then if I need to re-flash NAND I don't have to worry about who/how puts a develop.sig file in NAND. [Yes, there was the correct develop.sig for that system in NAND; only the SD card (looked at first by OFW) had the incorrect one.] mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OFW sad face doesn't say why
Mitch wrote: If you hold down the check key while booting, the firmware will give additional information about the boot progress, in both iconic and textual form. I did not realize that. Now that I went searching for this, saw it mentioned in the wiki on the 'XO_Troubleshooting_PowerOn' page. And yes, with the check key pressed, the firmware did print trying sd:\security\devel.sig and some sort of invalid message. [These stand out from the other texts if one KNOWS to look for them.] [I haven't been using chatty (check key held) mode for booting -- but I've been seeing icons-drawn-by-firmware anyway.] I WISH there was a comprehensive description accessible of the __iconic__ information shown by the boot process. For instance, for me the green 'olpc' icon disappears from the firmware display whenever I have a SD card plugged in (but then I normally *would* see an orange 'SD card' icon). I seem to get the additional red? 'plugin' icon whenever I have an USB stick or an ethernet adapter plugged in. And I have only vague notions about what the various symbols (that can appear underneath an icon) are trying to tell me. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OFW sad face doesn't say why
On Sat, Jul 19, 2008 at 5:52 AM, Mikus Grinbergs [EMAIL PROTECTED] wrote: Yes, I am running a joyride build on that system. This whole business of what indicators need to be placed where is a complete mystery to me. That is why I use a permanent SD card, with my develop.sig on that card -- then if I need to re-flash NAND I don't have to worry about who/how puts a develop.sig file in NAND. [Yes, there was the correct develop.sig for that system in NAND; only the SD card (looked at first by OFW) had the incorrect one.] Mitch, it looks like the real issue here, then, is that OFW doesn't continue to look for develop.sig on other devices once it's found one which doesn't work. If it had, then the presence of a bogus develop.sig on SD wouldn't have preventing OFW from finding the correct develop.sig on NAND and booting the system correctly. That sounds like a bug we can fix. (Mikus: the info you're looking for is http://wiki.laptop.org/go/Startup_Diagnosis ) --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OFW sad face doesn't say why
C. Scott Ananian wrote: On Sat, Jul 19, 2008 at 5:52 AM, Mikus Grinbergs [EMAIL PROTECTED] wrote: Yes, I am running a joyride build on that system. This whole business of what indicators need to be placed where is a complete mystery to me. That is why I use a permanent SD card, with my develop.sig on that card -- then if I need to re-flash NAND I don't have to worry about who/how puts a develop.sig file in NAND. [Yes, there was the correct develop.sig for that system in NAND; only the SD card (looked at first by OFW) had the incorrect one.] Mitch, it looks like the real issue here, then, is that OFW doesn't continue to look for develop.sig on other devices once it's found one which doesn't work. If it had, then the presence of a bogus develop.sig on SD wouldn't have preventing OFW from finding the correct develop.sig on NAND and booting the system correctly. I had come to the same conclusion. That sounds like a bug we can fix. (Mikus: the info you're looking for is http://wiki.laptop.org/go/Startup_Diagnosis ) --scott ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OFW sad face doesn't say why
While Startup_Diagnosis was the repository for that information in the past, the relevant bits for the vast majority of users/repairpeople have been moved to XO_Troubleshooting_PowerOn and I stopped linking to Startup_Diagnosis (which was left as a developer resource.) Much thanks to the authors of Startup_Diagnosis. Cheers, wad On Jul 19, 2008, at 10:45 AM, C. Scott Ananian wrote: On Sat, Jul 19, 2008 at 5:52 AM, Mikus Grinbergs [EMAIL PROTECTED] wrote: Yes, I am running a joyride build on that system. This whole business of what indicators need to be placed where is a complete mystery to me. That is why I use a permanent SD card, with my develop.sig on that card -- then if I need to re-flash NAND I don't have to worry about who/how puts a develop.sig file in NAND. [Yes, there was the correct develop.sig for that system in NAND; only the SD card (looked at first by OFW) had the incorrect one.] Mitch, it looks like the real issue here, then, is that OFW doesn't continue to look for develop.sig on other devices once it's found one which doesn't work. If it had, then the presence of a bogus develop.sig on SD wouldn't have preventing OFW from finding the correct develop.sig on NAND and booting the system correctly. That sounds like a bug we can fix. (Mikus: the info you're looking for is http://wiki.laptop.org/go/Startup_Diagnosis ) --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OFW sad face doesn't say why
mystery to me. That is why I use a permanent SD card, with my develop.sig on that card -- then if I need to re-flash NAND I don't have to worry about who/how puts a develop.sig file in NAND. Back near Christmas, I put text into the Activation and Developer Keys page recommending that people use the simple and straightforward disable-security command to put their devkey into the boot flash (not the NAND) to avoid all future trouble about keys or security crap, no matter how much you re-flash your NAND. But a certain former security wizard at OLPC removed that recommendation from the Wiki page, thus leading to your current troubles. It's sad watching a good team continue idiotic wrestling with how much cost, trouble, fragility and end-user hassle they can insert into a system that's required by its software licenses and its own philosophy to be wide open to alteration by its users. While Startup_Diagnosis was the repository for that information in the past, the relevant bits for the vast majority of users/repairpeople have been moved to XO_Troubleshooting_PowerOn and I stopped linking to Startup_Diagnosis (which was left as a developer resource.) The other day I added a link to Startup_Diagnosis from XO_Troubleshooting_Guide. The XO_ stuff seemed to be *very* hardware oriented, i.e. if you didn't have a soldering iron in your hand, with the laptop guts opened and a raft of nearby spare parts, it just wasn't useful. I went to the olpc-sf physical meeting today, and tried to help a woman update her XO to something later than the G1G1 650 that she received in January. Someone had showed her yum update but that didn't actually improve anything in the UI or activities. She was at the level that's having trouble remembering to put the space in between su and -l. I absolutely failed to upgrade her -- I couldn't use any automated means like olpc-update, because it required the (%*$[EMAIL PROTECTED](@ USB-only activity upgrade, and it isn't documented what release number you can safely feed the damn thing if you don't have an Activity upgrade pack handy. I followed all the instructions on the Activity upgrade pack, and it failed on me (the un-debuggable secure update script failed to mount my USB stick and panicked, even though in a normal boot, the Journal mounts the same stick as /dev/sda1. Hasn't the author heard of the Python try statement?). Result: She's still running 650, and we'll chat again in a month at the next olpc-sf meeting. Morals: don't assume that your Wiki readers know anything more than the English language (or their native language). And don't make five different ways to upgrade your *(%*%^$ product, each of which only does a third of the job and either depends upon or wipes out what the other ones do. Much thanks to the authors of Startup_Diagnosis. You're welcome. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OFW sad face doesn't say why
On Fri, Jul 18, 2008 at 4:29 PM, Mitch Bradley [EMAIL PROTECTED] wrote: If you hold down the check key while booting, the firmware will give additional information about the boot progress, in both iconic and textual form. I put in the sad face because I needed some way to indicate failure. The published design specified what is supposed to happen when everything works but didn't give detailed guidance for the myriad of possible failure scenarios. I see. So this isn't the we couldn't find a lease screen. Its a something weird happened screen instead? Do we still have the lock icon couldn't find a lease screen in place as specified? Mitch, what might actually be best is if you could write a ticket (or tickets) for all of the cases you need to handle, so I can make a mockup of what they should look like in the future. (I'll assume that we don't have a) access to user colors b) access to animation c) access to translation in all cases unless otherwise noted.) This would include cases like you need to plug into AC power to continue as well. I'll see what I can do, and hopefully we can make the feedback all much more meaningful and reliable. Note that, in the normal (no check key) case, there is no SD icon - at NN's insistence. Interesting, I hadn't noticed that (I guess I need to update). What's the reasoning there? Isn't the SD card a valid place for a lease file? - Eben Eben Eliason wrote: On Fri, Jul 18, 2008 at 2:57 PM, Mikus Grinbergs [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: Happened to put in laptop BB a SD card copied over from laptop AA. Pushed power-on, laptop BB showed me a sad face and powered down. Figured out why -- that SD card had a directory on it called /security, and in that directory there was a file called develop.sig. Since this file's content did not match BB's identity, BB powered down. I erased that file - then BB would boot o.k. If you have a cheap SD card, and an enemy with an XO, why not create /security/develop.sig on that SD card, and surreptitiously insert that SD card into his OLPC - he would be extremely UNLIKELY to think of examining the sd-card-slot for the cause of his XO not booting. If the OFW identified its reason for not proceeding with booting, this opportunity for mischief would not work. Hmm, A big lock icon is supposed to appear when no lease is found. A sad face was never part of the design; I wonder if that slipped in as a temporary placeholder and never got fixed. Mitch, do you know where this lives (I assume firmware, but maybe not), and if it's possible to clean up with little effort? It seems to me that we should only be doing positive checks, not negative, against the security info in external devices. It should simply move on and illustrate that no valid key was found (adding the lock icon next to the SD icon, for instance). It shouldn't be possible to prevent an XO from booting at all if any of the devices (including the XO itself) have a valid key, right? - Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OFW sad face doesn't say why
Truth be known, I'm not terribly keen on stirring the firmware graphics pot again. When the firmware encounters a nonexistent or expired lease, there is no error message from the firmware. It just boots the OS in activation mode. The OS then tries to acquire a new lease, and if it can't, the OS displays the graphics. Normally, the only thing that the firmware shows is the XO and one dot below it. Note that the original question was related to a bad developer key, not a lease. The firmware only displays device icons in chatty mode, i.e. when you hold down the check key. Eben Eliason wrote: On Fri, Jul 18, 2008 at 4:29 PM, Mitch Bradley [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: If you hold down the check key while booting, the firmware will give additional information about the boot progress, in both iconic and textual form. I put in the sad face because I needed some way to indicate failure. The published design specified what is supposed to happen when everything works but didn't give detailed guidance for the myriad of possible failure scenarios. I see. So this isn't the we couldn't find a lease screen. Its a something weird happened screen instead? Do we still have the lock icon couldn't find a lease screen in place as specified? Mitch, what might actually be best is if you could write a ticket (or tickets) for all of the cases you need to handle, so I can make a mockup of what they should look like in the future. (I'll assume that we don't have a) access to user colors b) access to animation c) access to translation in all cases unless otherwise noted.) This would include cases like you need to plug into AC power to continue as well. I'll see what I can do, and hopefully we can make the feedback all much more meaningful and reliable. Note that, in the normal (no check key) case, there is no SD icon - at NN's insistence. Interesting, I hadn't noticed that (I guess I need to update). What's the reasoning there? Isn't the SD card a valid place for a lease file? - Eben Eben Eliason wrote: On Fri, Jul 18, 2008 at 2:57 PM, Mikus Grinbergs [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Happened to put in laptop BB a SD card copied over from laptop AA. Pushed power-on, laptop BB showed me a sad face and powered down. Figured out why -- that SD card had a directory on it called /security, and in that directory there was a file called develop.sig. Since this file's content did not match BB's identity, BB powered down. I erased that file - then BB would boot o.k. If you have a cheap SD card, and an enemy with an XO, why not create /security/develop.sig on that SD card, and surreptitiously insert that SD card into his OLPC - he would be extremely UNLIKELY to think of examining the sd-card-slot for the cause of his XO not booting. If the OFW identified its reason for not proceeding with booting, this opportunity for mischief would not work. Hmm, A big lock icon is supposed to appear when no lease is found. A sad face was never part of the design; I wonder if that slipped in as a temporary placeholder and never got fixed. Mitch, do you know where this lives (I assume firmware, but maybe not), and if it's possible to clean up with little effort? It seems to me that we should only be doing positive checks, not negative, against the security info in external devices. It should simply move on and illustrate that no valid key was found (adding the lock icon next to the SD icon, for instance). It shouldn't be possible to prevent an XO from booting at all if any of the devices (including the XO itself) have a valid key, right? - Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
