Bug 8601 - bootnet doesn't work
Summary: bootnet doesn't work
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: installer
Version: 6.1
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jay Turner
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-01-19 11:44 UTC by Riley H Williams
Modified: 2015-01-07 23:40 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-02-10 03:48:07 UTC


Attachments (Terms of Use)

Description Riley H Williams 2000-01-19 11:44:22 UTC
I recently tried doing a network install of RH 6.1 using the bootnet image,
and I was unable to do so. I tried writing the image to three different
floppies, and booting them from three different floppy drives, but on every
occasion, I achieved the same result: SYSLINUX loaded and displayed its
signup screen, where I typed "text" to start a text based install (the
graphics installer can't be used here as the system has no mouse support,
nor any easy means of adding it). In response, the system started loading
the initrd, but half way through it, it bombed out, reporting that it
couldn't do so and inviting me to insert another disk and press any key to
reboot.

I have no direct means of determining this, but a comparison against
booting with the boot.img image indicates that it gets about 40% of the way
through the initrd before bombing out, judging by the number of dots
printed.

ANY help would be much appreciated...

Comment 1 Riley H Williams 2000-02-03 17:21:59 UTC
Addendum to the above: This problem appears to be hardware specific.

I have now used the very same image on all three of the above floppies, and a
second machine was quite happy to both boot the floppy and complete the install.
I've since tried swapping components between the two, and it appears that the
problem is connected with the PC Chips motherboard in the first machine, as I
can swap everything else (including the SIMMs) between the two machines without
affecting the location.

Can anybody suggest a reason for this apparently crazy behaviour?


Note You need to log in before you can comment on or make changes to this bug.