Kilian <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow wrote:
>> Kilian <[EMAIL PROTECTED]> writes:
>>
>>> Goswin von Brederlow wrote:
> [...]
>>>> I went ahead and fixed mbr up for amd64. Apart from the obvious
>>>> (Build-depends, gcc -m32) I also fixed up some of the more serious
>>>> warnings and included running the testsuite as much as possible.
>>>> The package compiles but someone has to risk his/her system and
>>>> install the mbr now.
>>> Thanks a lot for your work! I'd be willing to do that, unfortunately
>>> it doesn't compile on my box; I get:
>>>
>>> Making all in harness
>>> make[1]: Entering directory `/usr/local/src/mbr-1.1.5.orig/harness'
>>> gcc -DPACKAGE=\"mbr\" -DVERSION=\"1.1.5\"  -I. -I.      -Wall
>>> -Wstrict-prototypes -Wmissing-prototypes -g -c bios.c
>> Did you apply the patch?
>
> Here is what I did:
>
>   $ apt-get source mbr
>   $ tar xzvf mbr_1.1.5.orig.tar.gz
>   $ cd mbr-1.1.5.orig
>   $ zcat ../mbr_1.1.5-2.diff.gz | patch -p1

'apt-get source mbr' should already run dpkg-source -x on the dsc file
to extract. Why do you have to untar and patch it manualy and why
don't you use 'dpkg-source -x *dsc' for it?

>   $ patch -p1 < ../mbr-x86_64.patch   # your patch
>   $ ./configure
>   $ make
>
> Both patches applied smoothly, no rejects at all.
>
>> This should be "gcc -m32" there. Without it it will create 64bit code
>> which won't work.
>
> Hm. Should this flag '-m32' be in your patch? Because I don't find it
> there..

The patch includes this:

| -CC = gcc
| -CFLAGS = -g -Wall
| +KERNEL_ARCH := $(shell uname -m)
| +
| +CC = gcc -m32
| +LD = ld -melf_i386

>>> In file included from bios.c:2:
>>> vm86.h:4:22: asm/vm86.h: No such file or directory
>> sh-3.1# cat /usr/include/asm/vm86.h /* All asm/ files are generated
>> and point to the corresponding
>>  * file in asm-x86_64 or asm-i386.
>>  */
>> #ifdef __i386__
>> # include <asm-i386/vm86.h>
>> #else
>> # error This header is not available for x86_64
>> #endif
>
> $ cat /usr/include/asm/vm86.h
> cat: /usr/include/asm/vm86.h: No such file or directory
>
>> sh-3.1# dpkg -S /usr/include/asm/vm86.h linux-kernel-headers:
>> /usr/include/asm/vm86.h
>
> $ dpkg -S /usr/include/i386-linux/asm/vm86.h
> linux-kernel-headers: /usr/include/i386-linux/asm/vm86.h
>
>> And you don't seem to be on sid. I don't have that file either on
>> sarge so it won't work there.
>
> OK, does that mean that there is no reasonable way I can get mbr on
> sarge to compile?

You need the sid linux-kernel-headers and also have to set "CC =
gcc-3.4 -m32". The Build-Depends need to change to ia32-libs-dev as
well.

>> http://mrvn.homeip.net/mbr/mbr_1.1.5-2.1_amd64.deb
>
> This won't install here:
>
> $ dpkg -i mbr_1.1.5-2.1_amd64.deb
> (Reading database ... 18347 files and directories currently installed.)
> Preparing to replace mbr 1.1.5-2.1 (using mbr_1.1.5-2.1_amd64.deb) ...
> Unpacking replacement mbr ...
> dpkg: dependency problems prevent configuration of mbr:
>   mbr depends on libc6-i386 (>= 2.3.5-1); however:
>    Package libc6-i386 is not installed.
> dpkg: error processing mbr (--install):
>   dependency problems - leaving unconfigured
> Errors were encountered while processing:
>   mbr

In sarge the 32bit libc6 is included in ia32-libs. For testing
purposed you can --force-depends.

> And I can't install libc6-i386 on my system:
>
> Package libc6-i386 is not available, but is referred to by another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
> E: Package libc6-i386 has no installation candidate
>
>
> I'm really stuck. Apparently lilo would be the best choice because it
> supports md-devices, right? But I can't use lilo because I don't have
> a working install-mbr.

Lilo only suggests mbr. Why can't you use it to install lilo directly
into the mbr?

> I would give grub a try, but I am not quite sure about the steps
> required for this. First off, the NEWS says that since 0.90 -
> 2001-07-11, "Linux software RAID support is added (only for
> RAID-1)". Well great, I have (or better want) a RAID-1. But everything
> I read about grub and RAID talks of sda/sdb or the like, not of
> mdX. Does grub support it, but not really, or what?
>
> Now, is it sufficient if I run
>
>    grub-install --root-directory=/boot --no-floppy /dev/sda
>    grub-install --root-directory=/boot --no-floppy /dev/sdb

man grub-install:
       grub-install copies GRUB images into the DIR/boot directory specfied by
       --root-directory, and uses the grub shell to install grub into the boot
       sector.

Your command line would install to /boot/boot/.

grub-install --no-floppy /dev/md0

should be sufficient to boot but not to get failsave booting in case
sda dies. It will only install on the first device mdadm -D lists for
the raid and I assume this is sda.

Running grub-install on the individual disks will also not result in a
bootable sdb disk. As shown below your device.map lists sdb as second
bios disk. But if sda fail sdb becomes the first bios disk and grub
fails to find the second. You have to tell grub that sdb will be the
first disk by putting "(hd0) /dev/sdb" into device.map when installing
on sdb.

> ? There exists no menu.lst, device.map or whatever on my system yet,
> do I have to manually set them up before running grub-install? If yes,
> how should they look like? I would figure device.map needs to state
>
>    (hd0)      /dev/sda
>    (hd1)      /dev/sdb
>
> But how does menu.lst have to look like?
>
> My fstab for the RAID system will look like this:
>
>   /dev/md0   /boot       xfs     defaults    0  0
>   /dev/md1   none        swap    swap
>   /dev/md2   /           xfs     defaults    0  0
>   /dev/md3   /home       xfs     defaults    0  0
>   /dev/md4   /var        xfs     defaults    0  0
>   /dev/md5   /var/log    xfs     defaults    0  0
>   /dev/md6   /var/tmp    xfs     defaults    0  0
>   /dev/md7   /tmp        xfs     defaults    0  0
>   proc       /proc       proc

You should look into lvm. My usual setup is:

/dev/md0 / (includes /boot)
/dev/md1 swap
/dev/md2 lvm

/usr, /var, /home on lvm.
tmp as tmpfs


Alternatively you could use partitions on raid to limit the number of
actual raid devices. The maximum number of raid devices used to be 8
which would put you at the limit.

> Thanks very much for your time, I really appreciate the help I've
> gotten from all you guys so far very much!
>
>       -- Kilian

MfG
        Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to