bb-tar "cjf" does not create a valid tbz2-archive -- if fact the result is a
plain tar-file (no compression) -- but does not warn about the unrecognized
parameter combination "cj" (bb does not have bzip2-compression yet, right?).
to fix this I have added an error message stating this does not work.
He also reported
cosmetic: versose "-v" does not show any output when used with "create"
which I have now fixed as well.
-Erik
I've found a problem with job control when the init process is restarted.
If the system boots for the first time, I get job control on a serial terminal -
no problems. However, when I restart init by issuing "init -q", then the shell
no longer has job control.
I traced this a problem in console_init in the file init.c. What was happening
after the restart is that the first compare
if (ioctl(0, TIOCGSERIAL, &sr) == 0) {
...
} else if (ioctl(0, VT_GETSTATE, &vt) == 0) {
...
} else {
... // assume /dev/console
}
returned error and subsequently the code assumes /dev/console as the console,
which does not support job control.
Checking the errno after the first call showed that the system was complaining
about the file descriptor. This is probably because the previous init process
had closed all its file descriptors which the new init process had inherited.
This patch fixes endian problems with get_netmask(). I don't know if
this is the cleanest solution, but it makes 'ipcalc -n' work on both
an i386 system and a ppc system.
He took a look into the recent reports of tar problems, and found an obvious
typo in last_patch91 from vodz which converted tar to use bb_getopt_ulflags.
Erik, et al.
The attached patch makes the following changes to networking/ifupdown.c:
(1) It swaps all calls to 'ip link set' and 'ip addr set'. This solves
two problems:
(a) Calling 'ip link set <dev> up' before assigning an address
generates an error message, and
(b) Under User Mode Linux, running in with ethernet interfaces
in daemon mode, the MAC address for an interface is selected
based on the IP address assigned to that interface. If the
interface is brought up before being assigned an IP address,
it gets a null MAC.
(2) It further cleans up run_mapping().
This patch is against ifupdown.c revision 1.25.
-- Lars
andersen@busybox.net wrote:
>Message: 4
>Modified Files:
> init.c
>Log Message:
>Remove code for unsupported kernel versions
Hmm. Current init.c have check >= 2.2.0 kernel one time too.
Ok. Last patch removed this point and move common init code to new file for
/init dir
Hello, I think the test for an unconfigured httpd is wrong in
the CVS (busybox-unstable-20030620.tar.bz2)
flg_deny_all is default 0
vodz then wrote:
Oops. You are right.
Also, this mistake haved from two place.
Last patch rewroted to my new get_ularg() function for overcompensate size
from this error found ;-)
I've had some issues with modprobe which I reported a few months ago. This
is still an issue so I decided to sort it out.
The attached diff includes the changes against the unstable cvs tree that
work for me.
Changes are:
mod_process() will report success if the module at the head of the list
loads successfully. It will also report success if any module unloads
successfully.
The net result being that modprobe will succeed in the cases outlined below.
I've also added error reporting to modprobe -r. Previously it would silently
fail (but report success) if the module could not be unloaded.
Andrew
"rootfs" entry as well as the traditional "/dev/root" entry. This caused
applets such as mount and df to display two root filesystem entries....
This teaches the relevant utilities to ignore the "rootfs" entry.
-Erik
I'm building BusyBox using a development kit for MontaVista Hardhat Linux
(PPC) -- which, at least in this instance, is based around kernel 2.2.14.
I've had to massage a few files in networking/libiproute/ to make it
compile. Specifically:
(1) Added a #include <sys/uio.h> for the iovec structure in
libnetlink.c,
(2) Put ifdefs in ll_types.c and ll_proto.c around various
constants (ETH_P_xxx and ARPHRD_xxx) that weren't defined,
(3) Make do_changename() in iplink.c require a kernel >=
2.4.0 -- the ifr structure in my environment doesn't
have the ifr_name attribute. I've assumed this is
a kernel dependency -- let me know if I ought to be
checking something else.
In the absence of the correct kernel, do_changename()
always returns 0.
Attached is a patch against the current CVS that will make these changes.
-- Lars
