[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#679377: Segmentation fault when initramfs is booting

A Dimecres, 4 de juliol de 2012 18:08:30, Michael Tokarev va escriure:
> tags 679377 + moreinfo
> thanks
> On 28.06.2012 13:14, Jordi Pujol wrote:
> > Package: busybox
> > Version: 1:1.20.0-4
> > Severity: important
> > 
> > the patch "shell-ash-export-HOME.patch" causes a segmentation fault when
> > initramfs boots,
> > I believe that this fault occurs the first time that initramfs looks for
> > some executable in the initramfs filesystem,
> Does whole thing actually work?  Why do you think it is this patch
> which causes the SIGSEGV?  The change in this patch is quite, well,
> innocent, it does not look like it can be a cause for any such issues.
This works now, using the modified version,
There are a few weeks, after the upgrade 
of Busybox, the system not booted; 
automatically it entered in the Busybox shell, and we see "Segmentation 
fault..." in the file /run/initramfs/initramfs.debug
Trying the new version 1.20.1 from upstream, with their stable patches, 
allways boots.
Adding the old patches to that, this little patch makes the boot fail,

I believe that some built-in Busybox commands access to internal memory tables 
that are not initialized yet,
These tables may be initialized with some commands that manage paths or 
directories. (It's supposed, from experiences).

> Can you describe your initramfs/environment a bit?  Maybe give me
> access to your initramfs for testing?
my initramfs is based in Debian Live initramfs, in their mailing-list they 
have been talking about that and it's solved with a workaround. This 
workaround re-creates a directory (mkdir -p) that already exists.


> > Also, the latest release of busybox, 1.20.1 is a bit different of that,
> > and
> Different of what, exactly?  The version of busybox you're
> filing bugreport against is actually 1.20.1, so there are
> two questions actually: what is different, and different
> between what and what? -- since you're comparing the same
> thing with itself.
Sorry, a detailed look shows that I was magnifying the things, there is only 
one diff,

diff -Naurp ../busybox-1.20.0/shell/ash.c ../busybox-1.20.1-lnet1/shell/ash.c
--- ../busybox-1.20.0/shell/ash.c	2012-07-05 12:11:06.000000000 +0200
+++ ../busybox-1.20.1-lnet1/shell/ash.c	2012-04-22 03:45:24.000000000 +0200
@@ -6846,7 +6846,8 @@ evalvar(char *p, int flags, struct strli
 		patloc = expdest - (char *)stackblock();
 		if (NULL == subevalvar(p, /* varname: */ NULL, patloc, subtype,
 				startloc, varflags,
-				/* quotes: */ flags & (EXP_FULL | EXP_CASE | EXP_REDIR),
+//TODO: | EXP_REDIR too? All other such places do it too
+				/* quotes: */ flags & (EXP_FULL | EXP_CASE),
 		) {
 			int amount = expdest - (

> So, I really want to know more about your environment and
> the segfault.  I don't see any segfaults here.
This Segmentation fault is really difficult to debug, it's supposed that occurs 
depending on the instruccions contained in every script,

Here is a saved log of an execution, using a modified Debian Live initramfs 
that traps all errors,

+ maybe_break mount
+ [  = mount ]
+ log_begin_msg Mounting root file system
+ _log_msg Begin: Mounting root file system ... 
+ [ n = y ]
+ printf Begin: Mounting root file system ... 
Begin: Mounting root file system ... + . /scripts/lnet
+ export LANG=C
+ mountpoint=/lnet/image
+ LNET_LIVEVARS=/etc/lnet.vars
+ LNET_USERFULLNAME=Live never ending Tale user
+ [ -z -qb ]
+ . /scripts/functions
+ set -e
+ trap set +e ; trap - 0 ; panic "Error in ${0}" 0
+ touch /etc/mtab
+ mkdir -p /lnet
+ awk /MemTotal:/{print $2} /proc/meminfo
Segmentation fault...
(next the panic routine is executed...)

All the commands are built-in Busybox commands,

It has been not possible to save a log in Debian Live; in this environment 
after the error the shell was locked or unresponsible,

it seems that everyone has solved this, in a form or other, change the 
severity to normal, if you want.


Jordi Pujol

Live never ending Tale
GNU/Linux Live forever!

Reply to: