OpenWrt Forum Archive

Topic: Problem with Kamikaze 7 on WRT54GL v1.1

The content of this topic has been archived on 7 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi,

I'm having couple of issue after upgrading to Kamikaze.

One of them are my web does not seem to work totally. Although port 80 is still listening.. my /www directory seem to be empty. While try to upgrade the version via ipkg command, I got this following error


root@OpenWrt:~# ipkg upgrade base-files-brcm-2.4
Upgrading base-files-brcm-2.4 on root from 8-7431 to 8-7485...
Downloading http://downloads.openwrt.org/kamikaze/7 … mipsel.ipk
Segmentation fault


Routing seem to be working. Able to go to internet but I not too sure what should I do now..

Anyone has any advise for me please?

Below are list of package installed on my router:

root@OpenWrt:~# ipkg list_installed
base-files-brcm-2.4 - 8-7431 -
bridge - 1.0.6-1 -
busybox - 1.4.2-1 -
dnsmasq - 2.38-1 -
dropbear - 0.49-1 -
haserl - 0.8.0-1 -
iptables - 1.3.5-1 -
kernel - 2.4.34-brcm-1 -
kmod-brcm-wl - 2.4.34+4.80.53.0-1 -
kmod-diag - 1+2.4.34-brcm-1 -
kmod-ipt-nathelper - 2.4.34-brcm-1 -
kmod-ppp - 2.4.34-brcm-1 -
kmod-pppoe - 2.4.34-brcm-1 -
kmod-switch - 2.4.34-brcm-1 -
kmod-wlcompat - 2.4.34+brcm-4 -
libgcc - 3.4.6-8 -
mtd - 5 -
nas - 4.80.53.0-1 -
nvram - 1 -
ppp - 2.4.3-7 -
ppp-mod-pppoe - 2.4.3-7 -
uclibc - 0.9.28-8 -
wireless-tools - 28-1 -
wlc - 4.80.53.0-1 -
Done.

(Last edited by xiao_xin3 on 16 Jun 2007, 22:09)

your probably out of space, your not supposed to use ipkg to update/upgrade. reflash

I have exactly the same problem.

root@OpenWRT:/etc# ipkg upgrade
Upgrading base-files-brcm-2.4 on root from 8-7431 to 8-7485...
Downloading http://downloads.openwrt.org/kamikaze/7 … mipsel.ipk
Segmentation fault
root@OpenWRT:/etc#

doing a "dmesg" will give the following Kernel Ooop:

ASSERTION FAILED: src != NULL at mini_fo.h:394 (fist_copy_attr_times)
Unable to handle kernel paging request at virtual address 00000000, epc == 80064b08, ra == 80064b08
Oops in fault.c::do_page_fault, line 206:
$0 : 00000000 1000fc00 00000049 814ca000 00000019 00000000 0000001f 811286a0
$8 : 00000000 00001a7f 00001a7f 00001a36 801a0000 801a0000 801a0000 ffffffff
$16: 00000000 817d62f0 811f8000 815ac9c0 ffffffea fffffff0 817d6260 00000000
$24: 00000002 00000002                   814ca000 814cbe88 00000000 80064b08
Hi : 00000000
Lo : 00000300
epc   : 80064b08    Tainted: P
Status: 1000fc03
Cause : 0000000c
PrId  : 00029006
Process ipkg (pid: 1320, stackpage=814ca000)
Stack:    817d6260 801550ec 801550e0 0000018a 8014d0d4 00000000 817d6110
817d62f0 811f8000 815ac9c0 817d6260 fffffff0 10096b38 80045ad0 00000000
80044744 8004467c 80044664 815ac9c0 815ac9c0 811f8000 10096b38 1009f478
102b9ee8 10096b38 80045d10 10344000 811286a0 00008000 814cbf30 815aca40
8105e4a0 811f800c 00000005 1370fd29 00000010 00000000 102ba520 102ba710
7fff7c70 ...
Call Trace:   [<801550ec>] [<801550e0>] [<8014d0d4>] [<80045ad0>] [<80044744>]
[<8004467c>] [<80044664>] [<80045d10>] [<80008a60>] [<8005b9ec>]

Code: 2407018a  0c004d45  afa20010 <a2000000> 8e020058  8e040054  8e030050  aec20058  aec40054


And no, there is plenty of disk space available

(Last edited by anfalas on 20 Jun 2007, 09:23)

both of you reflash, and never run ipkg upgrade again -_-

Thank you for your very intelligent answer. What kind of help would it be for the developers since this IS a matter of a bug in Kamikaze?

its not a "bug" because you cant replace the kernel with ipkg, so your updating your box with an unsupport method.

As far as I know this package does not contain the kernel.

But I've found a few Bug Tickets regarding this problem (for example 1871 and 1823). The answer of the guys were both to not use ipkg upgrade.
But I do not understand two things:
- if ipkg upgrade should not be used - why not disable this feature or at least give a warning message?
- This IS a bug. Why not fix it?

IMHO the mini_fo is a overlay filesystem to make certain read-only filesystems writable, redirecting write operations to somwhere else, leaving the original FS untouched. This is exactly what I expect doing a ipkg upgrade: the ro base file system is not writable and therefore the "overinstalled" packages will be linked or somewhat else (overlayed in the kernel?). It's true  - it may have no much sense to replace files this way. Looking at "Common mistakes" we will find the following:

#7 WRONG:
"You can use 'ipkg upgrade' to upgrade to the latest firmware"

My opinion is: the Assertion handed to the kernel from the mini_fo routines should not happen, the mechanism should at least to what one expect. Even if it does not make much sense. Sure, the developers may have much mor important problems. But a bug remains a bug.

I'm also lost what to do. Reflash? Fine, but using which file then?..
Last time I flashed:
[   ] openwrt-wrt54g-2.4-squashfs.bin                    01-Jun-2007 15:51  1.7M
There is no newer version until today.
And there are a lot of new files in the packages directory. Mostly all of them dated with 05-Jun, including base-files:
[   ] base-files-brcm-2.4_8-7431_mipsel.ipk              01-Jun-2007 15:48   24K 
[   ] base-files-brcm-2.4_8-7485_mipsel.ipk              05-Jun-2007 02:08   24K 

So what is the right way to upgrade it?.. Could you show what is the correct way? Is any manual how to do it?..
Thanks.

(Last edited by anton_kg on 3 Jul 2007, 01:46)

Same problem here. Same segmetation fault, same packet.

The discussion might have continued from here.