So are are your terminals configured to boot PXE by default?
So I guess you don't put your netboot upgrade server online on your
network, unless you want to upgrade?
If you register on the Wiki via
http://webconverger.org/ikiwiki.cgi?do=prefs I can give you admin
rights to edit the Wiki. I can also give you edit rights via a ssh pub
key & git.
It would be great if you could document the whole setup (with photos
:) on the wiki. Else at the very least you could use gist.github.com
and I can merge it in via git.
On the latest blog
http://webconverger.org/blog/entry/Webconverger_11.2_release_notes/ I
do mention I want to deal with the http://webconverger.org/upgrade
problem. I think your solution is great for your setup. Though I can
confidently say most people want it transparent like the Chromium
experience on the desktop.
So I'm planning to add some persistence layer in USB images and use
the existing squashfs as a rsync base for a new update squashfs. I
guess at some point it efficiently downloads the new squashfs in the
background, come release.
Then it scripts the boot command line to boot into the updated
squashfs, and if that for some reason it fails, allow it to fall back
to the old squashfs. A bit like how most distros treat a Linux upgrade
at present. That's the rough idea at present. I like to think of
deployment of customised Webconvergers in terms of a squashfs unit, as
it makes things easy at least for my brain. :}
Thank you for writing in,
- really convenient. We are thinking of booting over the network for ascreen cast system, since the screens can end up on difficult to
access places (with ladders and stuff ;-) ), but that is for much
later - the backend still has to be build.
Ok, you should have admin rights. Sorry for the delay here.
May I suggest http://webconverger.org/pxenetboot ?
I like the netboot & dd local disk on demand idea.
People do ask for netboot customisations, but traditional netboot
where images are loaded everytime imo sucks big time (far too fragile)
and hence I don't offer it.
Oh btw, did you have to do some special tweaking to enable multicasting?
> I like the save approach for the upgrade process. Would be a great
> feature!
Not sure what you mean by the "save" approach, do you mean "safe"? :)
Cheers!
I've forgotten about this almost, but yes you could have a netboot
setup, whereby every terminals boot configuration has (something like)
this line:
httpfs=http://192.168.1.1/latest.squashfs
Making it download the squashfs IIRC (haven't tested it for ages).
This sort of deployment could be sped up I assume with a transparent
proxy and maybe some "multicasting" switch, but I haven't tried.
I prefer Koen's netboot then dd to disk process at present. Though
maybe I can at revisit with httpfs= with persistency in mind...