On Mon, 2009-01-26 at 10:08 +0100, Harald Schiöberg wrote:
> it is the very image that ends up in ${TOPDIR}/bin/openwrt-avila-zImage
> and is usually flashed in a seperate flash partition. (on another arch
> it will certainly have another name.)
Let's see if I can clarify even more. It's the imag
On Mon, 2009-01-26 at 10:08 +0100, Harald Schiöberg wrote:
>
> it is the very image that ends up in ${TOPDIR}/bin/openwrt-avila-zImage
Hrm. My ${TOPDIR}/bin contains:
-rw-r--r-- 1 brian brian 1024 2009-01-23 03:38 md5sums
-rw-r--r-- 1 brian brian 1654563 2009-01-23 03:38
openwrt-brcm47xx-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian J. Murrell wrote:
> On Wed, 2009-01-21 at 17:46 +0100, Harald Schiöberg wrote:
>> here is the script we use to boot an Openwrt from a running Openwrt.
>
> Thanx!
>
>> Make sure to have kexec-tools installed
>
> Indeed.
>
>> kexec -l /mnt/
On Wed, 2009-01-21 at 17:46 +0100, Harald Schiöberg wrote:
>
> here is the script we use to boot an Openwrt from a running Openwrt.
Thanx!
> Make sure to have kexec-tools installed
Indeed.
> kexec -l /mnt/openwrt-avila-zImage --append="rtc-ds1672.probe=0,0x68
> root=$1 rootfstype=ext2 noin
Hi,
Brian J. Murrell wrote:
> I wonder what the feasibility is of instead of putting a linux kernel in
> the kernel portion of the flash image and essentially what's an initrd
> in the filesystem portion (because remember, all the / in the flash
> image does for me is mount USB storage on /), putt
On Thu, Jan 22, 2009 at 06:46:10PM +0100, Steven Barth wrote:
> Why emulate a 1 dimensional limited configuration system for all platforms,
> with a maximum capacity of 32kiB just because ONLY some old broadcom based
> routers use it?
Right.
NVRAM was usually a 32k block of consecutive name=val
> I disagree because that would create an unwanted relationship between
> ipkg and sysupgrade and also will result in having old configuration
> files if new versions of packages also have updated
> configuration files.
Why would you not want such a relationship. [io]pkg's conffiles are
meant to
> > thats why UCI was invented
>
> I would have suggested some kind of "on disk" nvram emulation for such
> non-nvram capable systems so that the nvram paradigm remains the same
> for nvram capable systems and is emulated for others that have, say,
> persistent disk.
Why emulate a 1 dimensional lim
On Thu, 2009-01-22 at 09:39 +0100, Bastian Bittorf wrote:
>
> only very few computersystems have NVRAM
s/computersystems/[wireless] routers/ ? OpenWRT is targeted at
[wireless] routers.
> thats why UCI was invented
I would have suggested some kind of "on disk" nvram emulation for such
non-nvra
* Brian J. Murrell [21.01.2009 16:15]:
> On Wed, 2009-01-21 at 15:41 +0100, Bastian Bittorf wrote:
> >
> > KISS!
>
> Heh. KISS would have been leaving the config in the NVRAM as it was
> intended. :-)
only very few computersystems have NVRAM - thats why UCI was invented
> Maybe the list of c
On Wed, 2009-01-21 at 20:30 +0100, Steven Barth wrote:
> > Is it, or will it some day get Luci driven to operate as seamlessly as
> > native firmware upgrades?
>
> Is this seamless enough:
> http://dev.luci.freifunk-halle.net/sysupgrade.png
Sure, as long as when it's done that, it comes back on t
> Is it, or will it some day get Luci driven to operate as seamlessly as
> native firmware upgrades?
Is this seamless enough:
http://dev.luci.freifunk-halle.net/sysupgrade.png
;-)
Greetings
Cyrus
___
openwrt-devel mailing list
openwrt-devel@lists.open
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
| Is it, or will it some day get Luci driven to operate as seamlessly as
| native firmware upgrades?
LuCI's firmware upgrade pages already use sysupgrade (or better it's shell
libraries)
internally.
~ JoW
-BEGIN PGP SIGNATURE-
Version: GnuPG
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I wonder what the feasibility is of instead of putting a linux kernel in
> the kernel portion of the flash image and essentially what's an initrd
> in the filesystem portion (because remember, all the / in the flash
> image does for me is mount USB
On Wed, 2009-01-21 at 17:01 +0100, Jo-Philipp Wich wrote:
>
> Yes. For squashfs + jffs based systems you could also investigate the
> contents of /jffs,
> which contains only files that where modified compared to the initial rom
> file system.
Yes, that is an interesting approach for such syste
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Right. But that's a list that will continually need updating as new
> packages are brought in. As I said in a previous message, having
> package maintainers identify config files within their packaging is
> still error-prone but probably less so th
On Wed, 2009-01-21 at 16:39 +0100, Jo-Philipp Wich wrote:
>
> It has a builtin list of important configs like /etc/opkg.conf, /etc/dropbear
> etc.
Right. But that's a list that will continually need updating as new
packages are brought in. As I said in a previous message, having
package mainta
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian J. Murrell wrote:
| On Wed, 2009-01-21 at 08:51 +0100, Markus Wigge wrote:
|> Hello,
|
| Hi,
|
|> Have you ever tried "sysupgrade"?
|
| No.
|
|> A nice little tool to save your
|> config,
|
| And how does it know where all of the various config i
On Wed, 2009-01-21 at 15:41 +0100, Bastian Bittorf wrote:
>
> KISS!
Heh. KISS would have been leaving the config in the NVRAM as it was
intended. :-)
> Just write an script which tar->gzip->uuencode's your prefered config-files
So now I need to know what all configuration files are behind wha
* Brian J. Murrell [21.01.2009 15:30]:
> restore" process? This is _exactly_ the kind of rigmarole I am talking
KISS! Just write an script which tar->gzip->uuencode's your prefered
config-files
into nvram-partition (if your hardware has one), which is (if existent) restored
at firstboot (just
On Wed, 2009-01-21 at 08:51 +0100, Markus Wigge wrote:
> Hello,
Hi,
> Have you ever tried "sysupgrade"?
No.
> A nice little tool to save your
> config,
And how does it know where all of the various config is? Are you sure
it's not missing any, now or in the future?
> flash a new image and re
Hello,
> This assurance is gone with Kamikaze. Upgrading is much more of PITA,
> ensuring that I've saved all my settings from /etc/[config] and having
> to reload them back, but only after I've gone through the gyrations of
> fixing up the default router address re-assignment [you all know the
>
> It's worth recognizing and mentioning that perhaps this boot loader
> could actually be a full linux kernel and a very small / that simply
> "kexec"s a new kernel from the USB storage once it's mounted at /.
> I wonder how portable kexec is amongst the processors Linux runs on.
That would be nic
One of the most frustrating tasks in regard to OpenWRT is needing to
upgrade. There are several factors that instigate it further.
Firstly, with any given router's traditional WAP/router firmware (as
well as OpenWRT's White Russian), configuration settings were stored in
NVRAM and survived up/dow
24 matches
Mail list logo
