Hi James, OLPC community,
I'm looking to be able to run a forth script in secured laptops in the
Peru deployment. I'm the buildmaster for the current production image,
and hold the crypto keys necessary.
Please point me to some docs or simple procedure off the top of your
head, if you have
(if
there is no lease), will verify the signature, and will then execute
the script.
In the bios-crypto build tree;
./sign-os.sh o1 olpc.fth runos.zip
cp runos.zip actos.zip
This is further documented on the Wiki [1], with a couple of usage
examples [2] [3], but is possibly best described
more exception
handling and 1.75 specifics to the procedures once we return to Canada,
but
the combination of OOB 4.1 and the olpc.fth boot are making the frequent
process of updating/enhancing things while here in Kenya just fly!!!
Cheers,
KG
On Tue, Jun 12, 2012 at 8:00 PM, James
once we return to Canada, but
the combination of OOB 4.1 and the olpc.fth boot are making the frequent
process of updating/enhancing things while here in Kenya just fly!!!
Cheers,
KG
Can you post it some place when done?
Sameer
On Tue, Jun 12, 2012 at 8:00 PM, James Cameron qu...@laptop.org
will add some more exception
handling and 1.75 specifics to the procedures once we return to Canada,
but
the combination of OOB 4.1 and the olpc.fth boot are making the frequent
process of updating/enhancing things while here in Kenya just fly!!!
Cheers,
KG
Can you post it some
Jerry, James and Martin:
Adam and I thank you all ... a lot We are now 100% operational using 1 USB
stick to update all versions of XO. We will add some more exception
handling and 1.75 specifics to the procedures once we return to Canada, but
the combination of OOB 4.1 and the olpc.fth boot
versions of XO. We will add some more exception
handling and 1.75 specifics to the procedures once we return to Canada, but
the combination of OOB 4.1 and the olpc.fth boot are making the frequent
process of updating/enhancing things while here in Kenya just fly!!!
Cheers,
KG
On Tue, Jun 12
oodles of forth code from various sources and put together
a nice little olpc.fth file which is sitting in the /boot directory on the
USB stick.
We then have an 885 .img file with the XO1 image, and an 885 .zd4 file with
the XO1.5 image in the root of the stick.
We hae coded it such that If we hit
much humming along nicely, to a point:
We have borrowed oodles of forth code from various sources and put
together a nice little olpc.fth file which is sitting in the /boot
directory on the USB stick.
We then have an 885 .img file with the XO1 image, and an 885 .zd4 file
with the XO1.5
On Tue, Jun 12, 2012 at 11:08:29AM -0400, Kevin Gordon wrote:
Disclaimer: Newbie Forth question :-)
Always welcome.
We are trying to create a consolidated unsecured update stick.
I worked on a secured update drive last week, so the techniques are on
my mind.
[...]
So for those coming
On Fri, Mar 16, 2012 at 11:55:54PM -0400, Paul Fox wrote:
i'm a little confused. i know i reported that filesystem resize was
quite fast now, but then james reported that a resize took a really
long time still, and i haven't retested. if a resize takes a really
long time, then i don't think
Hi James,
On Fri, Mar 16, 2012 at 5:58 PM, James Cameron qu...@laptop.org wrote:
Consensus is to implement a partition resize in OpenFirmware as the last
step of ''fs-update''. This doesn't preclude the initramfs doing it,
and the initramfs will do the filesystem resize.
In OpenFirmware, we
On Mon, Mar 19, 2012 at 4:30 PM, Daniel Drake d...@laptop.org wrote:
I think I see a potential problem here. The problem is that during
upgrades, we run fs-update before upgrading firmware, and a firmware
upgrade is necessary for this new functionality.
(...)
Maybe I have just made a good
On Mon, Mar 19, 2012 at 02:30:22PM -0600, Daniel Drake wrote:
Maybe I have just made a good argument as to why this needs to be done
in the initramfs: to avoid tricky upgrade considerations.
Yes, you must do it in initramfs for that reason.
However the initramfs implementation is not yet
On Mar 16, 2012 11:03 PM, James Cameron qu...@laptop.org wrote:
Attached is a revised patch, which places the resize: before
zblocks-end: with a wrapper to prevent warning. This allows the resize:
request to be added to olpc-os-builder without requiring OpenFirmware
support.
This completely
On Sun, Mar 18, 2012 at 10:20:26PM -0400, Martin Langhoff wrote:
On Mar 16, 2012 11:03 PM, James Cameron qu...@laptop.org wrote:
Attached is a revised patch, which places the resize: before
zblocks-end: with a wrapper to prevent warning. This allows the resize:
request to be added to
Nice work, I like it. It is already XO-1.75 aware. Please could we
have a Linux initramfs expert adopt it for OLPC builds?
On Thu, Mar 15, 2012 at 02:21:04PM -0300, Emiliano Pastorino wrote:
Hi everyone!
I wrote a dracut module a couple of weeks ago which runs during pre-mount and
On Fri, Mar 16, 2012 at 12:10 AM, James Cameron qu...@laptop.org wrote:
Nice work, I like it. It is already XO-1.75 aware. Please could we
have a Linux initramfs expert adopt it for OLPC builds?
Thanks Emiliano!
I'll try to take on this project this release cycle.
Posted some thoughts at
On Fri, Mar 16, 2012 at 11:58:51AM -0600, Daniel Drake wrote:
I'll try to take on this project this release cycle.
Posted some thoughts at http://dev.laptop.org/ticket/10040
Thanks.
Consensus is to implement a partition resize in OpenFirmware as the last
step of ''fs-update''. This doesn't
On Sat, Mar 17, 2012 at 10:58:05AM +1100, James Cameron wrote:
On Fri, Mar 16, 2012 at 11:58:51AM -0600, Daniel Drake wrote:
In OpenFirmware, we might either:
* do the resize only if the .zd file requests it, (a new ''resize:''
line after ''zblocks-end:''), or
This has been written and
james wrote:
On Fri, Mar 16, 2012 at 11:58:51AM -0600, Daniel Drake wrote:
I'll try to take on this project this release cycle.
Posted some thoughts at http://dev.laptop.org/ticket/10040
Thanks.
Consensus is to implement a partition resize in OpenFirmware as the last
step of
On Fri, Mar 16, 2012 at 11:55:54PM -0400, Paul Fox wrote:
james wrote:
On Fri, Mar 16, 2012 at 11:58:51AM -0600, Daniel Drake wrote:
I'll try to take on this project this release cycle.
Posted some thoughts at http://dev.laptop.org/ticket/10040
Thanks.
Consensus is to
130ms).
I don't think its necessary to do this check every boot. I propose
you
move it to after fs-update has installed an image.
Also, olpc.fth isn't executed in the secure boot path, so it does
need
to be put somewhere else. I like Richard's suggestion
On Thu, Mar 15, 2012 at 1:58 AM, Peter Robinson pbrobin...@gmail.com wrote:
Well it works fine for 100s of devices in our datacenter at work,
maybe there's some mechanism not implemented in mmc or the linux code.
cjb might be able to fill in some of the gaps..
It only works if the device is
Hi everyone!
I wrote a dracut module a couple of weeks ago which runs during pre-mount
and
basically performs this steps:
- If 99% of disk capacity is partitioned, exit.
- else, expand the partition to full disk without losing data.
I'm attaching a tar.gz file, without the extension becasue
On Wed, Mar 14, 2012 at 1:35 AM, James Cameron qu...@laptop.org wrote:
Grows the second partition so that it takes up all remaining space on
the eMMC or microSD card. Fix for #11690. Part of #10040.
Costs 120ms. (Use of a flag file costs 130ms).
I don't think its necessary to do this
of a flag file costs 130ms).
I don't think its necessary to do this check every boot. I propose you
move it to after fs-update has installed an image.
Also, olpc.fth isn't executed in the secure boot path, so it does need
to be put somewhere else. I like Richard's suggestion.
Daniel
or microSD card. ?Fix for #11690. ?Part of #10040.
Costs 120ms. ?(Use of a flag file costs 130ms).
I don't think its necessary to do this check every boot. I propose you
move it to after fs-update has installed an image.
Also, olpc.fth isn't executed in the secure boot path, so it does need
that it takes up all remaining space on
the eMMC or microSD card. ?Fix for #11690. ?Part of #10040.
Costs 120ms. ?(Use of a flag file costs 130ms).
I don't think its necessary to do this check every boot. I propose you
move it to after fs-update has installed an image.
Also, olpc.fth isn't
move it to after fs-update has installed an image.
Also, olpc.fth isn't executed in the secure boot path, so it does need
to be put somewhere else. I like Richard's suggestion.
This would break fs-verify, and is therefore unacceptable.
Is this really a concern ? It doesn't break
don't think its necessary to do this check every boot. I propose you
move it to after fs-update has installed an image.
Also, olpc.fth isn't executed in the secure boot path, so it does need
to be put somewhere else. I like Richard's suggestion.
This would break fs-verify
for #11690. ?Part of #10040.
Costs 120ms. ?(Use of a flag file costs 130ms).
I don't think its necessary to do this check every boot. I propose you
move it to after fs-update has installed an image.
Also, olpc.fth isn't executed in the secure boot path, so it does need
to be put
On Wed, Mar 14, 2012 at 5:48 PM, James Cameron qu...@laptop.org wrote:
I would prefer to solve this by having Linux expand the partition, but
I'm told that can't work because Linux doesn't see the new size until
next boot. Do you know a way to avoid a reboot?
Yes, we can do it from the
instead place it in the olpc.fth path for insecure boot, and in
the fs-update path for secure install.
Or we might add it to the tail of fs-update, and add an
fs-update-no-resize for the factory to use, with an fs-resize for them
to use after fs-verify.
This sounds like the right compromise
, olpc.fth isn't executed in the secure boot path, so it does need
to be put somewhere else. I like Richard's suggestion.
This would break fs-verify, and is therefore unacceptable.
Is this really a concern ? ? It doesn't break fs-verify if one is using
the correct
image for the storage
) in the first place, resulting in no change by the resize
operation.
The patch does change the size of the partition in this case, and
providing one image to rule them all would simplify manufacturing ... in
that it would remove a possible source of error.
We might instead place it in the olpc.fth path
. I propose
you
move it to after fs-update has installed an image.
Also, olpc.fth isn't executed in the secure boot path, so it does
need
to be put somewhere else. I like Richard's suggestion.
This would break fs-verify, and is therefore unacceptable
be run by the operating system for the space to be
available to the user.
olpc/olpc.fth | 43 +++
1 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/olpc/olpc.fth b/olpc/olpc.fth
index 368e3c5..cd3b723 100644
--- a/olpc/olpc.fth
+++ b/olpc
Hi all:
Just a quick question is it possible to run commands that are available
at OFW prompt inside the olpc.fth file? I'm looking at trying to run
add-tag-from-file from within olpc.fth.
Any hints will be welcome,
Jerry
___
Devel mailing list
On Thu, Feb 3, 2011 at 4:16 PM, Jerry Vonau jvo...@shaw.ca wrote:
Just a quick question is it possible to run commands that are available
at OFW prompt inside the olpc.fth file? I'm looking at trying to run
add-tag-from-file from within olpc.fth.
I used to think you could, but according
On Thu, 2011-02-03 at 16:21 -0500, Martin Langhoff wrote:
On Thu, Feb 3, 2011 at 4:16 PM, Jerry Vonau jvo...@shaw.ca wrote:
Just a quick question is it possible to run commands that are available
at OFW prompt inside the olpc.fth file? I'm looking at trying to run
add-tag-from-file from
On Thu, 2011-02-03 at 15:37 -0600, Jerry Vonau wrote:
On Thu, 2011-02-03 at 16:21 -0500, Martin Langhoff wrote:
On Thu, Feb 3, 2011 at 4:16 PM, Jerry Vonau jvo...@shaw.ca wrote:
Just a quick question is it possible to run commands that are available
at OFW prompt inside the olpc.fth file
that are available
at OFW prompt inside the olpc.fth file? I'm looking at trying to run
add-tag-from-file from within olpc.fth.
I used to think you could, but according to Reuben and Mitch... you
can't. By the time boot.fth gets executed, OFW has put the memory back
in readonly
On Thu, Feb 03, 2011 at 03:16:43PM -0600, Jerry Vonau wrote:
Just a quick question is it possible to run commands that are
available at OFW prompt inside the olpc.fth file? I'm looking at
trying to run add-tag-from-file from within olpc.fth.
Yes, certainly, provided the laptop is not secured
:
Just a quick question is it possible to run commands that are
available
at OFW prompt inside the olpc.fth file? I'm looking at trying to run
add-tag-from-file from within olpc.fth.
I used to think you could, but according to Reuben and Mitch... you
can't. By the time
On Fri, 2011-02-04 at 10:16 +1100, James Cameron wrote:
On Thu, Feb 03, 2011 at 03:16:43PM -0600, Jerry Vonau wrote:
Just a quick question is it possible to run commands that are
available at OFW prompt inside the olpc.fth file? I'm looking at
trying to run add-tag-from-file from within
On Thu, Feb 03, 2011 at 05:20:26PM -0600, Jerry Vonau wrote:
ok the buffer is too small, the key gets truncated, but this looks to
be viable. Anybody got a quick fix?
I've not validated your code, but in the newkatag.fth example the size
of the buffer keybuf is set by the value on the stack
, Feb 3, 2011 at 4:16 PM, Jerry Vonau jvo...@shaw.ca wrote:
Just a quick question is it possible to run commands that are
available
at OFW prompt inside the olpc.fth file? I'm looking at trying to run
add-tag-from-file from within olpc.fth.
I used to think you could
Hi Richard,
Sorry to turn around on this -- we no longer want the XO-1.5-specific
kernel parameters in olpc.fth since we are now building them into the
kernel.
For future XO-1.5 bootfw releases please replace olpc.fth with the one
included here
This isn't critical - everything still works fine
On 12/13/2009 06:54 AM, Daniel Drake wrote:
Hi Richard,
Sorry to turn around on this -- we no longer want the XO-1.5-specific
kernel parameters in olpc.fth since we are now building them into the
kernel.
Ok. Great. I'm going to release a firmware tonight so I'll add this in.
--
Richard
like you
would boot SOAS.
My problem is with making the olpc.fth file
currently i'm trying with the following
\ Boot script for SD Boot
\ created from http://wiki.laptop.org/go/Custom_bootloader
ro boot=casper rootdelay=1 splash console=ttyS0,115200 console=tty0
fbcon=font:SUN12x22 to boot-file
Hello I'm trying to boot into Trisquel like you
would boot SOAS.
My problem is with making the olpc.fth file
currently i'm trying with the following
\ Boot script for SD Boot
\ created from http://wiki.laptop.org/go/Custom_bootloader
ro boot=casper rootdelay=1 splash console=ttyS0,115200
[EMAIL PROTECTED] wrote:
mitch wrote:
My recent rewrite of the Olpc.fth wiki page documents the basics from
the XO perspective.
thanks. that page is now the excellent boot reference i was
hoping for. :-)
I put all the pages I could find that describe aspects of XO startup
rewrite of the Olpc.fth wiki page documents the basics from
the XO perspective.
thanks. that page is now the excellent boot reference i was
hoping for. :-)
The primary documentation for the client interface is in the IEEE Open
Firmware standard; you might be able to find a near-final
recent rewrite of the Olpc.fth wiki page documents the basics from
the XO perspective.
thanks. that page is now the excellent boot reference i was
hoping for. :-)
The primary documentation for the client interface is in the IEEE
Open
Firmware standard; you might be able to find a near
G'day,
Build joyride-1563 is broken, it lacks an olpc.fth.
Reproducer is to olpc-update from joyride-1551 to joyride-1563, try to
boot, the result is Boot device: /usb/wlan and Can't open boot
device. Verify using OFW commands:
dir n:\versions\pristine\fe9d1dbbe15c2391d8f48b120148f0a5
You don't really need the entire olpc.fth - the following lines should
suffice:
ok setenv ramdisk n:\boot\olpcrd.img
ok boot n:\boot\vmlinuz root=mtd0 rootfstype=jffs2
Those lines are short enough to type manually.
The rest of olpc.fth is just automated reflash and support for boot-alt.
Most
the IP address and telnet to it from another system,
% telnet 10.0.0.147
3. on this other system, obtain a copy of /boot/olpc.fth from build
joyride-1551 and display it on your screen, without any line-wraps,
rsync \
rsync://updates.laptop.org/build-joyride-1551/root/boot
58 matches
Mail list logo
