Re: trouble with the boot-block..
All this makes sense, of course. What I don't understand is how something got written to the MBR and why my floppy drive is ignored now. To clear my SCSI drives 1 and 3, I'll have to do a low-level format. From an earlier message, I gathered that you DID tell the installation program to install lilo at least during one installation attempt. If you did that then lilo installed the lilo boot loader code in the MBR. When lilo does this, it creates some files in /boot/ directory including a copy of the original boot block. Lilo csn then later be told to 'remove itself' and replace the original boot code. However, in your case, you re-attempted initial installation which 'wipes out' the files saved by lilo. Thus, there is no longer any way for lilo to restore the original boot code since it really does not exist. So even if the installation code authors examined the drive to look for a previous installation of lilo, there is no way that they could 'uninstall' it anyway. In addition, many people have multiple installation of Linux on the same machine (I usually have two or three myself). It would be a _real_ disaster for me if lilo removed the lilo boot code when I did a second or third linux installation. I am at a complete loss as to what linux could possibly have done to make your floppy be ignored. As far as I know, recognizing and booting from your floppy is an activity that takes place long before ANY linux code is loaded and executed (you do have the CMOS set for A: then C: and not the otherway around, yes?) Actual low-level formatting of scsi drives is a pretty unusual activity. Drives vary between just plain ignoring the command, immediately returning an operation complete response, running a bad block scan, to actually DOING a low level format. Many scsi drives actually can not be low level formated without special (manufacture specific) software. As I think I mentioned to Jean Pierre, my knowledge of DOS could be stuffed into a thimble. At any rate, DOS is gone, and /dev/fd0 is useless. (I just knew there was something I liked about you!) Last night I catenated /target/etc/lilo.conf to stdout and saw something like what you've got below. But it didn't do much good because I'm not familiar with the file. Also, didn't find anything in the boot that came with v1.3. Can you tell me what to edit to what to get rid of lilo from the master boot rec? Short of the DOS FDISK/mbr I don't know of anything (simple) that you can do to get rid of lilo at this point. You can edit /etc/lilo.conf so that it looks something like this: boot = /dev/sda prompt timeout = 50 compact delay = 20 install = /boot/boot.b map = /boot/map vga = normal image = /vmlinuz root = /dev/sda3 label = Linux read-only other=/dev/sda1 table = /dev/sda label = DOS Substitute your drive designation for 'boot = /dev/sda' (but I think that is correct for your system. Substitute your drive/partition designation for 'root = /dev/sda3' of your (attempted) linux installation. Substitute your drive/partition disignation for 'other=dev/sda1' for the location of your DOS partition (if you have one). I think but am not positive that the 'table = /dev/sda' has to point to the drive that contains the linux root filesystem (regardless of where the dos partition is located). After editing that file (/etc/lilo.conf) then run lilo itself: lilo -t -r /target The '-t' tells lilo to just tell you what it wants to do but not to change anything. A '-v' tells lilo to be somewhat verbose. The '-r /target' tells lilo to the directory '/target' as the 'root' for its' operations (otherwise lilo would want to modify the ram filesystem which would be a bit useless). This should give you an output like: [EMAIL PROTECTED]:/home/wrl# lilo -q -t Linux * DOS If you use the '-v' option then it might look something like this: [EMAIL PROTECTED]:/home/wrl# lilo -v -q LILO version 20, Copyright 1992-1997 Werner Almesberger Reading boot sector from /dev/hda Global settings: Delay before booting: 2.0 seconds Command-line timeout: 5.0 seconds Always enter boot prompt Serial line access is disabled No message for boot prompt No default boot command line Images: Linux * No password Boot command-line won't be locked No single-key activation VGA mode: 9 (0x0009) Kernel is loaded high, at 0x0010 No initial RAM disk No fallback Options: ro root=304 DOS No password Boot command-line won't be locked No single-key activation No fallback (Your lilo version is probably different than mine so the message may well not be an exact match. If what you get does look pretty much like the above (and in particular lilo does not report any errors) then type: lilo -r /target Lilo should then correctly install itself but remember the
Re: trouble with the boot-block..
The install and rescue floppies are indeed supposed to use the ramfs. Obviously the install floppy has to since at least most of the time there will be no other linux filesystem available. However, the rescue floppy does also because it has to be able to boot fully even if the root partition is corrupt (and allow you to attempt to repair same). So a boot floppy is yet a different critter and contains a kernel that has been patched (with rdev) to have your normal root partition set. When you boot the installation disks and answer the first few questions (color monitor, keyboard, etc), the hit an alt-F2 to access the second console. type 'mount -t ext2 /dev/hda1 /target [replacing /dev/hda1 with whatever is appropriate for your configuration of course] Lilo can remove lilo but the installation disks do not 'know' that lilo was previously installed and thus take no action when you choose not to use lilo--so yes, if you installed lilo and did not do something like fdisk/mbr is DOS or explicitly replace the boot record using the lilo command then lilo is still present. A lilo config file looks something like this: bash-2.01$ cat /etc/lilo.conf boot = /dev/hda - disk to boot from prompt - prompt for boot choices during boot timeout = 50 - continue boot with default if no response compact - kernel is compressed install = /boot/boot.b - location of the boot code map = /boot/map - location of the system map file vga = normal - vga display mode to use delay = 20 - i don't remember image = /vmlinuz - name location of the linux kernel to load root = /dev/hda4 - system root device to use label = Linux - name for this instance of system read-only - always initially mount root read only vga = 9 - vga mode to use for this instance image = /vmlinuz.old - last kernel root = /dev/hda4 label = bklinux read-only vga = 9 image = /boot/vmlinuz-2.0.27 - a linux bo distribution system. root = /dev/hdb3 label = olinux read-only vga = 9 image = /vmlinuz.test - a linux testing partition root = /dev/hdb5 label = test read-only vga = 9 other=/dev/hda1 - an non-linux system table = /dev/hda - location of drive structure label = DOS - instance lable (and it is MSDOS) The lilo documentation is extensive and probably the about the best documentation in the entire Linux project but you do need to study it rather carefully if you want to be able to handle everything without problems. Most things can be given 'defaults' in the general section (the section before the first image = line and then overridden in the individual sections. Gary Kline wrote: According to Jean Pierre LeJacq: On Thu, 26 Feb 1998, Gary Kline wrote: According to Jean Pierre LeJacq: On Wed, 25 Feb 1998, Gary Kline wrote: However, after installing Debian on my first and third SCSI drives and *not* using LILO as the boot manager, I found that I __always__ boot into Debian, into a RAM file system. After re-installing both OS's from scratch several times I've come to the conclusion that something is causing the master boot track to always throw me into the re-install RAM-fs of Linux. Are you booting from the rescue floppy disk. If yes, then indeed you will be using the RAM-fs. You can either use the boot floppy disk or LILO installed on the hard disk. Both the hard drive and the rescue floppy throw me into the RAM-fs. (In fact, trying to re-install FreeBSD from its floppy disk is impossible.) Does the same thing happen when booting from your boot floppy? Did you install LILO on the harddisk? If so, send me the /etc/lilo.conf. Yes, once I did install LILO to my harddisk; then I brought up the menu again and chose ``NO'' when asked. Evidently, once the loader installs, it's forever! I'll have to check /etc/lilo.conf (if I can get to it) tonight my time. Last night I poked around using the ash shell but couldn't make much sense of the fs layout. Would lilo.conf perhaps be in /target/etc/lilo.conf? BTW, this (Debian + FBSD) is on a separate box. Not yet linked to the rest of the world... . gary -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] . -- best, -bill [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] from a 1996 Micro$loth ad campaign: The less you know about computers the more you want Micro$oft! See! They do get some things right! -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL
Re: trouble with the boot-block..
According to Bill Leach: The install and rescue floppies are indeed supposed to use the ramfs. Obviously the install floppy has to since at least most of the time there will be no other linux filesystem available. However, the rescue floppy does also because it has to be able to boot fully even if the root partition is corrupt (and allow you to attempt to repair same). So a boot floppy is yet a different critter and contains a kernel that has been patched (with rdev) to have your normal root partition set. When you boot the installation disks and answer the first few questions (color monitor, keyboard, etc), the hit an alt-F2 to access the second console. All this makes sense, of course. What I don't understand is how something got written to the MBR and why my floppy drive is ignored now. To clear my SCSI drives 1 and 3, I'll have to do a low-level format. type 'mount -t ext2 /dev/hda1 /target [replacing /dev/hda1 with whatever is appropriate for your configuration of course] All right. Lilo can remove lilo but the installation disks do not 'know' that lilo was previously installed and thus take no action when you choose not to use lilo--so yes, if you installed lilo and did not do something like fdisk/mbr is DOS or explicitly replace the boot record using the lilo command then lilo is still present. As I think I mentioned to Jean Pierre, my knowledge of DOS could be stuffed into a thimble. At any rate, DOS is gone, and /dev/fd0 is useless. Last night I catenated /target/etc/lilo.conf to stdout and saw something like what you've got below. But it didn't do much good because I'm not familiar with the file. Also, didn't find anything in the boot that came with v1.3. Can you tell me what to edit to what to get rid of lilo from the master boot rec? A lilo config file looks something like this: bash-2.01$ cat /etc/lilo.conf boot = /dev/hda - disk to boot from prompt - prompt for boot choices during boot timeout = 50 - continue boot with default if no response compact - kernel is compressed install = /boot/boot.b - location of the boot code map = /boot/map - location of the system map file vga = normal - vga display mode to use delay = 20 - i don't remember image = /vmlinuz - name location of the linux kernel to load root = /dev/hda4 - system root device to use label = Linux - name for this instance of system read-only - always initially mount root read only vga = 9 - vga mode to use for this instance image = /vmlinuz.old - last kernel root = /dev/hda4 label = bklinux read-only vga = 9 image = /boot/vmlinuz-2.0.27 - a linux bo distribution system. root = /dev/hdb3 label = olinux read-only vga = 9 image = /vmlinuz.test - a linux testing partition root = /dev/hdb5 label = test read-only vga = 9 other=/dev/hda1 - an non-linux system table = /dev/hda - location of drive structure label = DOS - instance lable (and it is MSDOS) The lilo documentation is extensive and probably the about the best documentation in the entire Linux project but you do need to study it rather carefully if you want to be able to handle everything without problems. Most things can be given 'defaults' in the general section (the section before the first image = line and then overridden in the individual sections. From what I've read so far, the Linux docs are great...and I know how murderous writing techical documentation is. The reason I want to go Debian over other Linux version is that Debian seems to be the BSD of Linux. --Flames to /dev/null, guys!-- Given its strengths toward quality-control and attention to detail, hopefully Debian will be around for a long, long time. gary -- best, -bill [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] from a 1996 Micro$loth ad campaign: The less you know about computers the more you want Micro$oft! See! They do get some things right! -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
trouble with the boot-block..
My Debian-1.3 came about a week ago. It didn't take that long to figure out the installation procedure; it is similiar to FreeBSD that I've used for around 3 years. However, after installing Debian on my first and third SCSI drives and *not* using LILO as the boot manager, I found that I __always__ boot into Debian, into a RAM file system. I have FreeBSD on my 2nd SCSI drive but cannot get to it. After re-installing both OS's from scratch several times I've come to the conclusion that something is causing the master boot track to always throw me into the re-install RAM-fs of Linux. I'd be much obliged for some work-arounds here. Am I using the wrong rescue disk or what? (*mumble*) thanks, gary kline -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: trouble with the boot-block..
This is just some quick 'off the top of my head' sort of things... First, the 'ramdisk' problem. This is probably not caused by anything associated with the booting process (though _can_ be--at least when using LILO) but rather that the kernel is configured to use a 'ramdisk' as root (/). I use and have always used lilo so I am not very familiar with the other methods. You are probably already familiar with 'rdev' but if you can find your debian kernel then you can tell that kernel to use whatever device/ partition you want. What boot manager are you using if not lilo? -- best, -bill [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] from a 1996 Micro$loth ad campaign: The less you know about computers the more you want Micro$oft! See! They do get some things right! -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: trouble with the boot-block..
On Wed, 25 Feb 1998, Gary Kline wrote: However, after installing Debian on my first and third SCSI drives and *not* using LILO as the boot manager, I found that I __always__ boot into Debian, into a RAM file system. After re-installing both OS's from scratch several times I've come to the conclusion that something is causing the master boot track to always throw me into the re-install RAM-fs of Linux. I'd be much obliged for some work-arounds here. Am I using the wrong rescue disk or what? Are you booting from the rescue floppy disk. If yes, then indeed you will be using the RAM-fs. You can either use the boot floppy disk or LILO installed on the hard disk. -- Jean Pierre -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: trouble with the boot-block..
According to Jean Pierre LeJacq: On Wed, 25 Feb 1998, Gary Kline wrote: However, after installing Debian on my first and third SCSI drives and *not* using LILO as the boot manager, I found that I __always__ boot into Debian, into a RAM file system. After re-installing both OS's from scratch several times I've come to the conclusion that something is causing the master boot track to always throw me into the re-install RAM-fs of Linux. I'd be much obliged for some work-arounds here. Am I using the wrong rescue disk or what? Are you booting from the rescue floppy disk. If yes, then indeed you will be using the RAM-fs. You can either use the boot floppy disk or LILO installed on the hard disk. Both the hard drive and the rescue floppy throw me into the RAM-fs. (In fact, trying to re-install FreeBSD from its floppy disk is impossible.) I'd like BSD on my second SCSI; Debian on my first and third, but (??) gary -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: trouble with the boot-block..
On Thu, 26 Feb 1998, Gary Kline wrote: According to Jean Pierre LeJacq: On Wed, 25 Feb 1998, Gary Kline wrote: However, after installing Debian on my first and third SCSI drives and *not* using LILO as the boot manager, I found that I __always__ boot into Debian, into a RAM file system. After re-installing both OS's from scratch several times I've come to the conclusion that something is causing the master boot track to always throw me into the re-install RAM-fs of Linux. Are you booting from the rescue floppy disk. If yes, then indeed you will be using the RAM-fs. You can either use the boot floppy disk or LILO installed on the hard disk. Both the hard drive and the rescue floppy throw me into the RAM-fs. (In fact, trying to re-install FreeBSD from its floppy disk is impossible.) Does the same thing happen when booting from your boot floppy? Did you install LILO on the harddisk? If so, send me the /etc/lilo.conf. -- Jean Pierre -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: trouble with the boot-block..
According to Jean Pierre LeJacq: On Thu, 26 Feb 1998, Gary Kline wrote: According to Jean Pierre LeJacq: On Wed, 25 Feb 1998, Gary Kline wrote: However, after installing Debian on my first and third SCSI drives and *not* using LILO as the boot manager, I found that I __always__ boot into Debian, into a RAM file system. After re-installing both OS's from scratch several times I've come to the conclusion that something is causing the master boot track to always throw me into the re-install RAM-fs of Linux. Are you booting from the rescue floppy disk. If yes, then indeed you will be using the RAM-fs. You can either use the boot floppy disk or LILO installed on the hard disk. Both the hard drive and the rescue floppy throw me into the RAM-fs. (In fact, trying to re-install FreeBSD from its floppy disk is impossible.) Does the same thing happen when booting from your boot floppy? Did you install LILO on the harddisk? If so, send me the /etc/lilo.conf. Yes, once I did install LILO to my harddisk; then I brought up the menu again and chose ``NO'' when asked. Evidently, once the loader installs, it's forever! I'll have to check /etc/lilo.conf (if I can get to it) tonight my time. Last night I poked around using the ash shell but couldn't make much sense of the fs layout. Would lilo.conf perhaps be in /target/etc/lilo.conf? BTW, this (Debian + FBSD) is on a separate box. Not yet linked to the rest of the world... . gary -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: trouble with the boot-block..
Gary Kline wrote: My Debian-1.3 came about a week ago. It didn't take that long to figure out the installation procedure; it is similiar to FreeBSD that I've used for around 3 years. However, after installing Debian on my first and third SCSI drives and *not* using LILO as the boot manager, I found that I __always__ boot into Debian, into a RAM file system. The solution that I'd suggest would be to use lilo, but since you specifically specify that you're not using lilo, I assume that you have a good reason why you don't want to. I have FreeBSD on my 2nd SCSI drive but cannot get to it. After re-installing both OS's from scratch several times I've come to the conclusion that something is causing the master boot track to always throw me into the re-install RAM-fs of Linux. I'd be much obliged for some work-arounds here. Am I using the wrong rescue disk or what? Are you using a FreeBSD rescue disk when you try to access freeBSD? Or are you trying to boot FreeBSD using the Debian rescue? I don't know much about FreeBSD, but I'd be surprised if that approach were feasible. (*mumble*) thanks, gary kline -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] . -- - Ralph Winslow [EMAIL PROTECTED] Mary bought a pair of skates upon the ice to frisk now wasn't that a crazy way her sweet young *? -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
