Bug#626851: linux-image-2.6.38-2-amd64: after last update fails to boot

[Jonathan Nieder <jrnieder@gmail.com>]

Hi,

Rares Aioanei wrote:
> Jonathan Nieder <jrnieder@gmail.com> wrote:

>> If I am and the .config indeed seems to be a red herring, would you be
>> willing to bisect between 2.6.38.4 and 2.6.38.5?  I can guide you
>> through the process if you'd like (and it probably would have been
>> worth writing a patch for the kernel guide for that by now; sorry).
>
> Yes, I could use some guidance. :-)

Sorry for the long silence.  Now the aforementioned patch is at [1]
but I'd rather give more pertinent advice directly.

First I would suggest testing with 2.6.39-1 from experimental.  If
that doesn't work, here is how to bisect:

	apt-get install build-essential git
	git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
	cd linux-2.6
	git remote add stable git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.38.y.git
	git fetch stable

The above grabs the kernel sources and in addition fetches the 2.6.38.y
series.

	git checkout v2.6.38.5
	git log v2.6.38.4..v2.6.38.5; # look over the changes
	git revert 068e0202; # back out the most relevant-seeming one
	make localmodconfig; # minimal configuration
	make -j4 deb-pkg

This spends its time building, so go for a hot beverage of your
choice.  Then you can test the resulting .deb:

	cd ..
	dpkg -i linux-image-*.deb
	reboot

If it also exhibits the problem, it would be time to test more
systematically.  It works like this (git-bisect(1) has details):

	cd ~/src/linux-2.6
	git bisect start
	git bisect bad; # current revision is bad
	git bisect bad v2.6.38.5
	git bisect good v2.6.38.4

Now it checks out a version halfway between to test:

	make silentoldconfig; # reuse configuration
	make -j4 deb-pkg

Hopefully this would be faster than the original build.  One can
test by installing the resulting package and rebooting.  Then
report back:

	git bisect good; # if it boots correctly
	git bisect bad; # if it exhibits the problem
	git bisect skip; # if some other problem makes it hard to test 

and it will check out a next version.  Since there are 56 patches
between 2.6.38.4 and 2.6.38.5, this would take log(56)/log(2) ~= 6
rounds to pinpoint to an individual patch.  The result of testing is
still useful to narrow it down if one gets bored before then. :)
You can get a picture of what's happening at any time with "git bisect
visualize" if the gitk package is installed.

Thanks again, and sorry I don't have any more clever ideas.

Regards,
Jonathan

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;bug=627960