@eclectic: "<quote>
I tried both the rc1 debian-testing-i386-netinst.iso and the daily
build as of a few days ago.  Same result.
Ok, I downloaded these 4 again.  It turns out that the daily build iso
was the exact same I had tried last.  The boot.imb.gz was different so
I re-made the usb stick "disk" with the one in the daily build link
above and the daily build iso.  So the backtrace below applies to the
daily builds above.
Actually, I was able to capture the problem in non-expert mode.
I figure the least amount of changes made in the flow of execution
of the program, the easier it would be to duplicate the problem.
I chose the defaults in the language selection, locale, etc...
Ok, it happens immediately after the identifying network hardware
screen.  So soon after in fact that I thought I would have no time to
swtich to console 4, but quick fingers did it and quite a bit scrolled
off the screen, ending in this:
[   23.523397] EAX: ffffffff EBX: df6f0000 ECX: ffffffff EDX: df413440
[   23.523397] ESI: df6f0000 EDI: 00000000 EBP: ffffffff ESP: df449f84
[   23.523397]  DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
[   23.523397] Process events/0 (pid: 5, ti=df448000 task=df43e860 task.ti=df448000)
[   23.523397] Stack: c025d42d df6f0000 00000002 c025830e df413440 c0356f00 c025833e 00000000
[   23.523397]        c025835b c012716d df413440 c01276e9 df413448 c0127794 00000000 df43e860
[   23.523397]        c012990b df449fc8 df449fc8 df413440 00000000 c0129763 c012972d 00000000
[   23.523397] Call Trace:
[   23.523397]  [<c025d42d>] dev_deactivate+0x1e/0xbd
[   23.523397]  [<c025830e>] __linkwatch_run_queue+0x118/0x148
[   23.523397]  [<c025833e>] linkwatch_event+0x0/0x22
[   23.523397]  [<c025835b>] linkwatch_event+0x1d/0x22
[   23.523397]  [<c012716d>] run_workqueue+0x75/0xee
[   23.523397]  [<c01276e9>] worker_thread+0x0/0xb5
[   23.523397]  [<c0127794>] worker_thread+0xab/0xb5
[   23.523397]  [<c012990b>] autoremove_wake_function=0x0/0x2d
[   23.523397]  [<c0129763>] kthread+0x36/0x5b
[   23.523397]  [<c012972d>] kthread+0x0/0x5b
[   23.523397]  [<c0104937>] kernel_thread_helper+0x7/0x10
[   23.523397]  =======================
[   23.523397] Code: ff 42 50 5b c3 89 c1 8d 90 80 00 00 00 89 12 8d 81 a4 00 00 00 89 52 04 c7 42 08 00 00 00 00 83 c2 0c 39 c2 75 e7 31 c0 c3 89 c1 <8b> 40 10 8b 50 30 85 d2 74 04 89 c8 ff d2 c3 53 89 c3 e8 a8 af
[   23.523397] EIP: [<c025d074>] qdisc_reset+0x2/0x11 SS:ESP 0068:df449f84
[   23.915430] Kernel panic - not syncing: Fatall exception in interrupt
Of course, the machine is now totally frozen, so no scrolling back.
Any other tests? Let me know.
To UNSUBSCRIBE, email to <email_address>
with a subject of "unsubscribe". Trouble? Contact <email_address>"
    @eclectic: "Quoting Christian Perrier <email_address>
<quote>
Actually, before I gave up on CDs (ruined 11 CD-Rs, probably marginal
media, drive or wodim problems) I had a CD made on a windows machine
of the lenny installer RC1.  This is what I just tried again.
I get the same panic at the same point in the installation process.
Of course the addresses are slightly different as the underlying
kernel code is different.
Correct.
Ok, tried a few more times.  I usually get the same kernel panic screen,
but on one occasion (in expert mode), it crashed a little differently
and I saw this:
Dec 21 17:21:46 kernel: [  173.096981] ipw2100: Intel(R) PRO/Wireless 2100 Network Driver, git-1.2.2
Dec 21 17:21:46 kernel: [  173.096987] ipw2100:
Dec 21 17:21:46 kernel: [  173.096987] ipw2100: Copyright(c) 2003-2006 Intel Corpration
Dec 21 17:21:46 kernel: [  173.206202] ACPI: PCI Interrupt 0000:02:03:0[A] -> Link [LKNB] -> GSI 5 (level, low) -> IRQ 5
Dec 21 17:21:46 kernel: [  173.206206] ipw2100: Detected Intel PRO/WIreless 2100 Network Connection
Dec 21 17:21:46 kernel: [  173.206619] firmware: requesting ipw2100-1.3.fw
Dec 21 17:21:46 net/hw-detect.hotplug: Detected hotpluggable network interface eth0
Dec 21 17:21:46 kernel: [  173.349107] ipw2100: eth1: Firmware 'ipw2100-1.3.fw' not available or load failed.
Dec 21 17:21:46 kernel: [  173.349114] ipw2100: eth1: ipw2100_get_firmware failed: -2
Dec 21 17:21:46 kernel: [  173.349118] ipw2100: eth1: Failed to power on the adapter.
Dec 21 17:21:46 kernel: [  173.349121] ipw2100: eth1: Failed to start the firmware.
Dec 21 17:21:46 kernel: [  173.349125] ipw2100Error calling register_netdev.
Dec 21 17:21:46 kernel: [  173.349443] ACPI: PCI interrupt for device 0000:02:03.0 disabled
Dec 21 17:21:46 kernel: [  173.349450] ipw2100: probe of 0000:02:03.0 failed with error -5
Dec 21 17:21:46 hw-detect: insmod /lib/modules/2.6.26-1-486/kernel/drivers ieee1394/sbp2.ko
Dec 21 17:21:46 kernel: [  173.480359] eth1394: eth1: IPv4 over IEEE 1394 (fw-host0)
Dec 21 17:21:46 net/hw-detect.hotplug: Detected hotpluggable network interface e
This is exactly as the screen froze.  I wonder if the only line visible that
refers to eth0 is when it actually detected the main (wired) ethernet
interface.  As this is the interface I want to use and it appears that it
generated no errors, it seems to be a good sign.  All the ipw2100 lines
refer to the wireless interface, which works fine on 2.6.18.  I never knew
it required separate firmware.  Since it appears not to be included in the
installer, I presume I'd have to find it in the additional drivers media.
In any case, the errors notwithstanding, it looks like the installer handled
the wireless interface correctly.  Am I right that it seems it's the
eth1394 driver that is causing the crash?
I've tried (based on the help example: hw-detect/start_pcmcia=false) to add
hw-detect/start_eth1394=false but it doesn't seem to have an effect.  It
still crashes.  BTW, the eth1394 driver is loaded without errors under
2.6.18, although it is not used.  I have no fire-wire devices to test it.
Early on, I passed the option to protect the firewire interface addresses
(faffd800 - faffdfff) but it still crashed.
I suppose it would help if I could get more lines in the console screens.
What option can I pass the installer to have smaller type, or even better
2 side by side pages?  I have a WUXGA (1920 X 1200) screen so it should be
possible to see a much longer backtrace.
If you point me to a boot.img.gz of the latest kernel, that I can
zcat to the usb memory stick, I'd be happy to test it.
Anything else I can do? More tests?
To UNSUBSCRIBE, email to <email_address>
with a subject of "unsubscribe". Trouble? Contact <email_address>"
    @eclectic: "Quoting Christian Perrier <email_address>
<quote>
Yes, I tried expert as well as regular.
No question about PCMCIA before getting to the network detection
screen/status bar.
That explains the missing firmware.
Correct.
Ok, did that and also vga=771.  I was hoping to get a smaller font to
see more of the backtrace.  This is what I got:
[ output of ethdetect -x - lsifaces (3 lines) sed (4), grep (4) and sed (3) ]
Dec 22 15:42:48 main-menu[1328]: (process:9628) + ip link set eth0 up
Dec 22 15:42:48 main-menu[1328]: (process:9628) + ip link set eth0 down
Dec 22 15:42:48 main-menu[1328]: (process:9628) + ip link set eth1 up
Dec 22 15:42:48 main-menu[1328]: (process:9628) + ip link set eth1 down
Dec 22 15:42:48 main-menu[1328]: (process:9628) + check-missing-firmware
Dec 22 15:42:48 main-menu[1328]: (process:9628) + sysfs-update-devnames
Dec 22 15:42:48 main-menu[1328]: (process:9628) + cleanup
Dec 22 15:42:48 main-menu[1328]: (process:9628) + rm -f /tmp/devnames-static.txt
Dec 22 15:42:48 main-menu[1328]: DEBUG: resolver (libslang2-udeb): package doesn't exist (ignored)
It didn't crash!  After that I proceeded to console 1 and did see the
screen explaining that I needed the missing firmware - ipw2100-1.3.fw.
As I had thought, even with the missing firmware, the culprit wasn't
the wireless device.
First thought: race condition (the panic message contained a backtrace
of different threads), so then I tried multiple times with only one
change at at time: expert mode, regular mode, ethdetect -x, vga=771,
vga normal.  It turns out that the culprit was the vga option.  With
vga=771, I get no crash/panic in either expert or regular mode, with
sh -x in ethdetect or not.  It might still be a race condition but if
so it seems to be triggered by something related to the display.  Very
strange.  The display works fine (with a big font) in normal mode.  In
771 mode, the font is smaller and the curses windows sharper.
Even though I now have a work-around, I'm willing to keep debugging
if if would be useful.
To UNSUBSCRIBE, email to <email_address>
with a subject of "unsubscribe". Trouble? Contact <email_address>"
    @eclectic: "<quote>
Correct.
To UNSUBSCRIBE, email to <email_address>
with a subject of "unsubscribe". Trouble? Contact <email_address>"
    @eclectic: "Quoting: Christian Perrier <email_address>
<quote>
I had not tried the graphical installer, figuring that the more
basic the better, but I just did.  It appears that just before
going to graphical, the installer puts the screen in mode 771.
I get the smaller, sharper fonts.  So, no. It doesn't crash in
the graphical installer.
BTW, the graphical installer looks good!
That's probably the reasonable thing to do.
Yes.  A prominent (easy to find) note that would say something
like "If your laptop crashes completely during installation,
try replacing the boot option vga=normal with vga=771 or use
the graphical installer" would have saved some time, but then
the problem would not have become known.  
Thank you very much for your help!
To UNSUBSCRIBE, email to <email_address>
with a subject of "unsubscribe". Trouble? Contact <email_address>"
{'source': 'USENET', 'other_information': '{"reply_count": 4, "forum_name": "linux.debian.maint.boot.20141009.mbox"}', 'file': 'data/output/usenet-linux.debian.parquet'}