Mailing List Archive

On Thu, Jul 05, 2007 at 12:07:14PM +0100, Ian McDonald wrote:
> I figure I'm probably trying to do something stupid, but here goes.
>
> I'm trying to boot a hard disk image (with one 420MB partition, lilo in
> the MBR) containing debian etch (kernel 2.6.18) using memdisk (onto a
> dell 2950 with 8G of ram).
>
> Lilo (22.6.1) fails on memdisk 3.35, 3.36, 3.50, 3.51, and 3.52-pre,
> with L 99 99 99 99 et al, but works on 2.x, 3.00 and 3.31.
>
> However, the kernel fails to snag the emulated hard disk, and fails to
> boot past it's initramfs as it can't find the rootfs.

Correct. The Linux kernel and new (from the last decade) operating
systems ignore the BIOS and access the hardware directly. The HDD you're
emulating with memdisk is available to lilo (or should be), because lilo
uses BIOS calls to access the disk.

However, the kernel will never see it, as it accesses the hardware
directly.

--
lfr
0/0

Luciano Rocha wrote:
> On Thu, Jul 05, 2007 at 12:07:14PM +0100, Ian McDonald wrote:
>
>> I figure I'm probably trying to do something stupid, but here goes.
>>
>> I'm trying to boot a hard disk image (with one 420MB partition, lilo in
>> the MBR) containing debian etch (kernel 2.6.18) using memdisk (onto a
>> dell 2950 with 8G of ram).
>>
>> Lilo (22.6.1) fails on memdisk 3.35, 3.36, 3.50, 3.51, and 3.52-pre,
>> with L 99 99 99 99 et al, but works on 2.x, 3.00 and 3.31.
>>
>> However, the kernel fails to snag the emulated hard disk, and fails to
>> boot past it's initramfs as it can't find the rootfs.
>>
>
> Correct. The Linux kernel and new (from the last decade) operating
> systems ignore the BIOS and access the hardware directly. The HDD you're
> emulating with memdisk is available to lilo (or should be), because lilo
> uses BIOS calls to access the disk.
>
> However, the kernel will never see it, as it accesses the hardware
> directly.
>
>

I did kind of wonder if there was a way of getting the kernel to look at
the bios information.

Aside from the above, I'm still not sure why Lilo fails on memdisk newer
than 3.31.

--
ian

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Ian McDonald wrote:
> I did kind of wonder if there was a way of getting the kernel to look at
> the bios information.

Nope. A MEMDISK-on-Linux driver could be written, but there has been
zero interest so far. Also, using memdisk to boot Linux is rather silly.

> Aside from the above, I'm still not sure why Lilo fails on memdisk newer
> than 3.31.

I suggest asking the LILO people about that...

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

H. Peter Anvin wrote:
> Ian McDonald wrote:
>> I did kind of wonder if there was a way of getting the kernel to look at
>> the bios information.
>
> Nope. A MEMDISK-on-Linux driver could be written, but there has been
> zero interest so far. Also, using memdisk to boot Linux is rather silly.

I know it's a wee bit strange, but I was rather taken by the idea of
being able to just build a small linux install in vmware, make
modifications to it as a running system, then boot said installation
trivially using memdisk, having dd'd a copy of the disk (from a pxelinux
image we use for our deployment system already).

I'll just build a kernel, and use a large initrd as I've done in the
past, but that has the disadvantage of not being so easily modifiable as
a "running" install. What I'm attempting to do is build a small linux
PXE-able system so I can apply a SAS backplane firmware update to a Dell
2950 which is running neither Windows, nor Linux. I've used memdisk for
many moons to punt dos images at servers for updates, but for some
reason this binary update needs Windows or "RedHat" (and a great list of
dependencies, which would be more difficult to resolve on a non-running
system).

>
>> Aside from the above, I'm still not sure why Lilo fails on memdisk newer
>> than 3.31.
>
> I suggest asking the LILO people about that...

I was actually wondering what behaviour had changed between 3.31 and
3.35 (and later) that had made something that had worked since memdisk
2.x "suddenly" break.

However, seeing as I'll not be using it much longer...

--
ian


_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Ian McDonald wrote:
> H. Peter Anvin wrote:
>> Ian McDonald wrote:
>>> I did kind of wonder if there was a way of getting the kernel to look at
>>> the bios information.
>> Nope. A MEMDISK-on-Linux driver could be written, but there has been
>> zero interest so far. Also, using memdisk to boot Linux is rather silly.
>
> I know it's a wee bit strange, but I was rather taken by the idea of
> being able to just build a small linux install in vmware, make
> modifications to it as a running system, then boot said installation
> trivially using memdisk, having dd'd a copy of the disk (from a pxelinux
> image we use for our deployment system already).
>
> I'll just build a kernel, and use a large initrd as I've done in the
> past, but that has the disadvantage of not being so easily modifiable as
> a "running" install. What I'm attempting to do is build a small linux
> PXE-able system so I can apply a SAS backplane firmware update to a Dell
> 2950 which is running neither Windows, nor Linux. I've used memdisk for
> many moons to punt dos images at servers for updates, but for some
> reason this binary update needs Windows or "RedHat" (and a great list of
> dependencies, which would be more difficult to resolve on a non-running
> system).

Joy.

As I said, a driver could be written (actually, writing it as some kind
of plugin to the Linux MTD driver would probably work.)

However, for most Linux uses, you're better off using a kernel+initramfs.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Ian McDonald wrote:
>
> I was actually wondering what behaviour had changed between 3.31 and
> 3.35 (and later) that had made something that had worked since memdisk
> 2.x "suddenly" break.
>

I believe the EDD code was new in 3.35, and it seems to have caused a
lot of grief. I'm not sure if it's due to the EDD code, or if it's due
to software incorrectly assuming EDD == EDD 3.0 (which is impossible to
implement correctly in the general case, since it requires 64-bit-clean
addressing, which neither BIOS nor all hardware supports.)

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Hello,

* H. Peter Anvin <hpa@zytor.com> [20070705 22:51]:
> > I'll just build a kernel, and use a large initrd as I've done in the
> > past, but that has the disadvantage of not being so easily modifiable as
> > a "running" install. What I'm attempting to do is build a small linux
> > PXE-able system so I can apply a SAS backplane firmware update to a Dell
> > 2950 which is running neither Windows, nor Linux. I've used memdisk for
> > many moons to punt dos images at servers for updates, but for some
> > reason this binary update needs Windows or "RedHat" (and a great list of
> > dependencies, which would be more difficult to resolve on a non-running
> > system).
>
[..]
>
> However, for most Linux uses, you're better off using a kernel+initramfs.

I second that. In the end, you only need the RedHat once, to unpack the
BIOS file and the flashing binary. Then you can simply collect the
neeeded libraries via ldd and solve the (comparatively small) dependencies
that way.

If you have the right kernel with the right modules you might end up
with a initramfs with only a dozen or two files in it, doing the job to
your full satisfaction.

Br,

Andreas

--
"At the end of knowledge, wisdom begins, and at the end of wisdom, there is no
grief ... but hope."
-- Lloyd Alexander, 30.1.1924-17.5.2007

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

On Thu, Jul 05, 2007 at 08:53:11PM +0100, Ian McDonald wrote:
> H. Peter Anvin wrote:
> > Ian McDonald wrote:
> >> I did kind of wonder if there was a way of getting the kernel to look at
> >> the bios information.
> >
> > Nope. A MEMDISK-on-Linux driver could be written, but there has been
> > zero interest so far. Also, using memdisk to boot Linux is rather silly.
>
> I know it's a wee bit strange, but I was rather taken by the idea of
> being able to just build a small linux install in vmware, make
> modifications to it as a running system, then boot said installation
> trivially using memdisk, having dd'd a copy of the disk (from a pxelinux
> image we use for our deployment system already).

You should be able to use the dd of the partition as an initrd,
if you have enough free memory (and the filesystem driver in the kernel,
not a module). Or use an initramfs:
ln -s sbin/init /init
find / -xdev ! -wholename /rd -print0 | cpio -o0Hnewc | gzip -9 > /rd

In both those cases, you'll have to have a correct /etc/fstab, or fix
the boot process to use a correct one.

Or an initrd that boots the hdd image via nbd, nfs, etc.

--
lfr
0/0

> [..]
>> However, for most Linux uses, you're better off using a kernel+initramfs.
>
> I second that. In the end, you only need the RedHat once, to unpack the
> BIOS file and the flashing binary. Then you can simply collect the
> neeeded libraries via ldd and solve the (comparatively small) dependencies
> that way.
>
> If you have the right kernel with the right modules you might end up
> with a initramfs with only a dozen or two files in it, doing the job to
> your full satisfaction.
>
> Br,
>
> Andreas
>

Aye. I thought of this, but it's a static binary, which then calls on
all sorts of system utilities, requiring libstdc++5 (which is in
compatibility libs for a start).

I've got it running on debian just fine, and actually know what I need
to put in the initramfs, which isn't a problem. I wanted to rule out the
idea of booting an image of a running system, because if I'd been able
to boot said image, I'd have only had to work the dependencies once, and
then not re-create the thing in an initramfs for future updates.

This being not the case, I'll just build the kernel+initramfs I need.

--
ian

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.