Ken Moffat wrote: >> I've never seen this, but I'm the lilo enthusiast on the editorial >>team, so I'd better respond ;) Let's try to work this out. >> >> The message you are getting seems to come from mbr.S in lilo, and >>is produced becasue it cannot find the 'LILO' text at offset 6 in >>the potential mbr it is looking at. On my machine booting on >>/dev/sda the start of the mbr looks like this: >> >>[EMAIL PROTECTED] /home/ken/lilo-22.7.1 #hexdump -C -n 512 /dev/sda >>00000000 fa eb 21 01 b2 01 4c 49 4c 4f 16 07 44 63 77 44 >>|..!...LILO..DcwD| >> >> You seem to have started to boot from lilo (otherwise, it could not >>produce the error message), so maybe it is looking in the wrong >>place. I'm not clear about your setup - >> >>(1.) which partition contains the host system ? >> >>(2.) can you still boot the host system ? (Actually, if you can't, >>trying to fix it will be an interesting exercise). >> >>(3.) but most importantly, what is in your lilo.conf ? >>In particular, where does 'boot=' point to ? >> >> I've never tried booting from other than the first hard disk, but >>I can recall that people used to have to do things when upgrading a >>disk (install on the slave, then pull out the original disk and make >>the new one the master) - in that case, people had to use >> >>disk=/dev/hdb bios=0x80 # Tell LILO to treat the second >> # disk as if it were the first >> # disk (BIOS ID 0x80). >>boot=/dev/hdb # Install LILO on second hard >> # disk. >> >>(taken from www.tldp.org/HOWTO/Hard-Disk-Upgrade/prepare.html) >> >> >> I'm not clear if you have a first disk (sda) connected ? >> >>Ken >> >> Hi Ken, First let me try to clear up exactly what I am trying to do and with what. I have two SATA drives. The motherboard has two onboard SATA RAID controllers. I have one disk connected to each controller. The only disk I was able to install on and then successfully boot was the disk connected to the Silicone Image controller. I have FC5 x86_64 installed on that disk which comes up as /dev/sda on the host system. Since I have not been able to boot from sdb my intent was to build my LFS on sdb on the host then switch the cables and make the LFS disk sda and boot from it. I have not been able to do that. I keep getting the stated error. Now, to your questions. I ran the hexdump command you gave and got the following: root:/# hexdump -C -n 512 /dev/sdb 00000000 fa eb 31 12 00 00 4c 49 4c 4f 16 07 10 00 01 00 |�1...LILO......| 00000010 00 7c 00 00 00 00 00 00 00 00 00 00 5e ac 08 c0 |.|..........^�.� 00000020 74 09 b4 0e bb 07 00 cd 10 eb f2 b9 13 00 b4 86 |t.�.�..���..�.|
This by the way is coming from running the chroot environment from the book. LFS is on /dev/sdb. /boot is on it's own partition /dev/sdb1. / is on /dev/sdb2. Another BTW, in the hexdump output I see the error message that I have been getting. This is the first time I have been sure that LILO was putting that up. There was always a chance in my mind that it was coming from the BIOS. The answer to question 1 is just above. The fact that I am trying to switch the cables should mean that when I am actually trying to boot it should be seen as sda not sdb. Question 2: Yes, as long as have the FC5 disk connected to the SI controller it boots fine. That is what I'm running now to get this information. Question 3: My lilo.conf file looks like this: root:/# cat /etc/lilo.conf # Begin /etc/lilo.conf # lilo.conf # # global options boot=/dev/sda # keytable=/boot/<keytable> lba32 map=/boot/System.map-2.6.16.16 prompt # set the name of the default image to boot default=lfs # define an image image=/boot/lfskernel-2.6.16.16 label=lfs root=/dev/sda2 read-only # optionally add parameters to pass, e.g. # append="video=radeonfb:[EMAIL PROTECTED]" # repeat for any other kernel images # optionally, add legacy operating systems # see man lilo.conf for examples # End /etc/lilo.conf I did note that our hexdump started out the same but only in the first two bytes. I did a google for a sub-string of the error message 'boot signature' and it came back with a link to a page that said the "signature" was for an x86 system "It then checks the sector for a valid boot signature (the last two bytes must be 55AAh).". The last two bytes being the last two in the boot block. Mine in fact are 55AAh although I am running pure 64 on an AMD64 Athlon. Like I said before I am out if ideas. What are your next thoughts? Arnie _______________________________________________ Clfs-support mailing list [email protected] http://ninja.linux-phreak.biz/mailman/listinfo/clfs-support
