Re: Almost there
On Thu, Jul 21, 2005 at 10:39:21PM +0200, Goswin von Brederlow wrote: > Afaik neither lilo nor grub support lvm. I thought lilo does support LVM, since it merely stores a block list for the kernel, so as long as it can work out where on the disk the kernel is. I don't have the spare hardware around at the moment to test this on to get definitive answers on each question, unfortunately. Hugo. -- === Hugo Mills: [EMAIL PROTECTED] carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 1C335860 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- No names... I want to remain anomalous. --- signature.asc Description: Digital signature
Re: Almost there
Hugo Mills <[EMAIL PROTECTED]> writes: > On Thu, Jul 21, 2005 at 11:53:15AM -0400, Lennart Sorensen wrote: >> Grub is WAY more flexible and friendly, and doesn't go broken on >> upgrades just because you forget to run that stupid lilo command to >> update the block map. >> >> I have certainly had more problems with lilo than grub in my time of >> using both. I prefer grub for sure. > >Me too. > >> lilo has nothing to offer that grub doesn't have (it used to, but not >> any more). > >Does it work with LVM2 now? That's about the only difference I'm > aware of at the moment. > >Hugo. Afaik neither lilo nor grub support lvm. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Almost there
On Thu, Jul 21, 2005 at 12:50:05PM -0400, Lennart Sorensen wrote: > On Thu, Jul 21, 2005 at 05:25:12PM +0100, Hugo Mills wrote: > >Does it work with LVM2 now? That's about the only difference I'm > > aware of at the moment. > > I think it might, but I haven't tried. I run this way: > > md raid1 ext2 /boot > md raid1 ext3 / > md raid1 lvm pv This is roughly how I have mine set up. I was just interested in whether grub knew about LVM yet. The patches for grub to handle this have been around for a couple of years, but nobody seems to have taken them on. Hugo. -- === Hugo Mills: [EMAIL PROTECTED] carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 1C335860 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- You've read the project plan. Forget that. We're going to Do --- Stuff and Have Fun doing it. signature.asc Description: Digital signature
Re: Almost there
On Thu, Jul 21, 2005 at 05:25:12PM +0100, Hugo Mills wrote: >Does it work with LVM2 now? That's about the only difference I'm > aware of at the moment. I think it might, but I haven't tried. I run this way: md raid1 ext2 /boot md raid1 ext3 / md raid1 lvm pv Everything else like swap and all is inside the lvm. I used to have non raid but cloned partition for /boot (cloned with dd using a script) since grub didn't support md raid at all until a few months ago, but now it is much simpler. Not having / in lvm just seems saner when you have to recover anything after a disaster (like I had to this morning since a power surge/failure/something rather badly corruted part of one of the disks in the raid1 for /. For some reason the secondary disk was fine, but the primary had lots of corrupt data, so using knoppix I rebuilt the raid using the secondary disk as the source drive and the system came back perfectly. No other power failure or event ever caused me problems like this though. So far ext3 has been great, while XFS seemed to have no end of trouble when run on lvm on raid on sata here. That was on the 32bit machine. The 64bit machine had no problems at all. Most of the windows servers fell over spectacularly too when whatever the event was happened. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Almost there
On Thu, Jul 21, 2005 at 11:53:15AM -0400, Lennart Sorensen wrote: > Grub is WAY more flexible and friendly, and doesn't go broken on > upgrades just because you forget to run that stupid lilo command to > update the block map. > > I have certainly had more problems with lilo than grub in my time of > using both. I prefer grub for sure. Me too. > lilo has nothing to offer that grub doesn't have (it used to, but not > any more). Does it work with LVM2 now? That's about the only difference I'm aware of at the moment. Hugo. -- === Hugo Mills: [EMAIL PROTECTED] carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 1C335860 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- You've read the project plan. Forget that. We're going to Do --- Stuff and Have Fun doing it. signature.asc Description: Digital signature
Re: Almost there
On Tue, Jul 19, 2005 at 11:30:47AM +0100, A J Stiles wrote: > There seem to be many reports on this list of people having problems with the > grub bootloader. Is there a good reason for using grub instead of lilo, or > is it just "trendy" ? Grub is WAY more flexible and friendly, and doesn't go broken on upgrades just because you forget to run that stupid lilo command to update the block map. I have certainly had more problems with lilo than grub in my time of using both. I prefer grub for sure. lilo has nothing to offer that grub doesn't have (it used to, but not any more). Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Almost there
> I believe I have made a significant oversight. I need to recompile the > kernel, right? Yes you do, it is a compile time option, unforunately and I guess the Ubuntu Kernel already has it enabled (even though it is an "experimental" feature (which works fine for me, though). ~David
Re: Almost there
David Mohr wrote: On 7/19/05, Gary Hodges <[EMAIL PROTECTED]> wrote: I made the change as instructed. #undef ATA_NDEBUG /* define to disable quick runtime checks */ #define ATA_ENABLE_ATAPI/* define to enable ATAPI support */ #undef ATA_ENABLE_PATA /* define to enable PATA support in some After rebooting I see the following with dmesg: cloud:/home/hodges# dmesg | grep ata2 ata2: SATA max UDMA/133 cmd 0x1C38 ctl 0x1C32 bmdma 0x1C18 irq 23 ata2: dev 0 cfg 49:0f00 82: 83: 84: 85: 86: 87: 88:101f ata2: dev 0 ATAPI, max UDMA/66 ata2: dev 0 configured for UDMA/66 So it looks like the drive is seen as I only have the one SATA device. My question is how do I mount it? I'm not seeing ata2 in /dev or anything that looks like it would work. It turns up as a scsi device. Running a 'cat /proc/scsi/scsi' should give you a bit more output and the CD should be mountable as device /dev/scd0. I believe I have made a significant oversight. I need to recompile the kernel, right? Cheers, Gary -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Almost there
On 7/19/05, Gary Hodges <[EMAIL PROTECTED]> wrote: > I made the change as instructed. > #undef ATA_NDEBUG /* define to disable quick runtime checks */ > #define ATA_ENABLE_ATAPI/* define to enable ATAPI support */ > #undef ATA_ENABLE_PATA /* define to enable PATA support in some > > After rebooting I see the following with dmesg: > cloud:/home/hodges# dmesg | grep ata2 > ata2: SATA max UDMA/133 cmd 0x1C38 ctl 0x1C32 bmdma 0x1C18 irq 23 > ata2: dev 0 cfg 49:0f00 82: 83: 84: 85: 86: 87: > 88:101f > ata2: dev 0 ATAPI, max UDMA/66 > ata2: dev 0 configured for UDMA/66 > > So it looks like the drive is seen as I only have the one SATA device. > My question is how do I mount it? I'm not seeing ata2 in /dev or > anything that looks like it would work. It turns up as a scsi device. Running a 'cat /proc/scsi/scsi' should give you a bit more output and the CD should be mountable as device /dev/scd0. ~David
Re: Almost there
David Mohr wrote: On 7/19/05, Gary Hodges <[EMAIL PROTECTED]> wrote: Oh, last week I did install Ubuntu on the machine and the Plextor SATA drive was found and worked fine, so I'm guessing I'll be able to get that to work with a little experimentation. You need to patch the kernel to get that to work, at least with the nv_sata controller it was just this small change: /include/linux/libata.h: change #undef ATA_ENABLE_ATAPI to #define ATA_ENABLE_ATAPI After that your SATA Plextor will show up. I made the change as instructed. #undef ATA_NDEBUG /* define to disable quick runtime checks */ #define ATA_ENABLE_ATAPI/* define to enable ATAPI support */ #undef ATA_ENABLE_PATA /* define to enable PATA support in some After rebooting I see the following with dmesg: cloud:/home/hodges# dmesg | grep ata2 ata2: SATA max UDMA/133 cmd 0x1C38 ctl 0x1C32 bmdma 0x1C18 irq 23 ata2: dev 0 cfg 49:0f00 82: 83: 84: 85: 86: 87: 88:101f ata2: dev 0 ATAPI, max UDMA/66 ata2: dev 0 configured for UDMA/66 So it looks like the drive is seen as I only have the one SATA device. My question is how do I mount it? I'm not seeing ata2 in /dev or anything that looks like it would work. Gary -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Almost there
On 7/19/05, Gary Hodges <[EMAIL PROTECTED]> wrote: > Oh, last week I did install Ubuntu on the machine and the Plextor SATA > drive was found and worked fine, so I'm guessing I'll be able to get > that to work with a little experimentation. You need to patch the kernel to get that to work, at least with the nv_sata controller it was just this small change: /include/linux/libata.h: change #undef ATA_ENABLE_ATAPI to #define ATA_ENABLE_ATAPI After that your SATA Plextor will show up. ~David
Re: Almost there
On Tuesday 19 July 2005 01:58 pm, Gary Hodges wrote: ... > Oh, last week I did install Ubuntu on the machine and the Plextor SATA > drive was found and worked fine, so I'm guessing I'll be able to get > that to work with a little experimentation. > > Thanks much to everyone who took the time to respond to my posts on > this. I hope what I've outlined above will help someone else with this > or similar hardware. > > Cheers, > Gary Congratulations! I'm glad I could be of some small help. Enough people have helped me over the years. By the way, my first AMD64 install was to a system with SATA drives only and the installer didn't support SATA drives. I lost count of how many installations I tried & the hoops that I had to jump through before I finally had a working system! Aren't computers grand? ;-) cmr -- Debian 'Sarge': Registered Linux User #241964 "More laws, less justice." -- Marcus Tullius Ciceroca, 42 BC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Almost there
A J Stiles wrote: There seem to be many reports on this list of people having problems with the grub bootloader. Is there a good reason for using grub instead of lilo, or is it just "trendy" ? I would have been happy to use LILO but I could never get LILO to install. I forget the error exactly, but it was something like "needs to install on a partition of a drive. No partition found." I tried installing on a floppy, the MBR and other partitions. Always got the same error. Grub would install so I went with that. Gary -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Almost there
OK, where do I start... Mike Reinehr wrote: On Monday 18 July 2005 05:52 pm, Gary Hodges wrote: ... /dev/sda1 (/boot) is ext2 and all the other partitions are ReiserFS. I'm using the standard kernel included with the debian installer. Note that I'm not using what is considered to be the stable installer, but a daily build I found somewhere. It is build 7-6-2005. The stable installer doesn't see the on-board NIC. I believe all the installers are using the same kernel (2.6.8-11). I don't know if initrd was created correctly. Is there a way to test it? It's looking as if GRUB is not the problem, which leaves the initrd. The short answer to your question is "I don't know." The long answer is that it might be documented in /usr/share/doc/kernel ... I would think that if the installer allowed you to create a ReiserFS file system, that the kernel & initrd supplied with the installer would be capable of mounting it, but stranger things have happened. At this point, I have two thoughts. First, it's time to go home, have a beer and a good night's sleep & work on this again, in the morning -- which is what I'm about to do! I was way ahead of you on heading home! My second thought is to fire-up Knoppix again. Chroot into /dev/sda2. Mount /dev/sda1 as boot on /dev/sda2 and then install another, more current kernel or, even, compile your own with make-kpkg. But, if you're not familiar with all this, this too would be better left until tomorrow. This is where I started this morning. I actually tried this a lot the past couple of days, but was never able to get chroot to work. Googling around today I found a comment about having to use a 64 bit live CD for 64 bit installs. Makes perfect sense, but that rather important point was left off by all the folks who suggested chroot previously. I'm sure a certain level of knowledge was assumed :-). So, I now have sarge installed on this machine. This install took me close to five full days. Ran into some bugs, lots of small steps made until it finally worked. Below are the steps distilled down a bit. I don't by any means claim this is the most concise way, but it worked for me. I repeated all of these this morning just to make sure it would work a second time. Hardware refresher for those searching: Tyan K8WE w/2x Opteron 244s LSI21320RB SCSI Controller Plextor PX-716SA (SATA) 1. Install with a beta version of the sarge installer. I searched through the Debian amd64 mailing list archives and found a kind person hosting the older installer. I think what makes it special is it used the 2.6.10 kernel before the installer team reverted back to 2.6.8. The stable installer didn't see my SCSI controller. The beta doesn't see the on-board NIC so you have to temporarily install an older NIC. The beta installer has a bug in grub. The K8WE board also has a BIOS bug (I have the newest BIOS installed). It won't cascade down the boot list to find bootable media or drives. You have to set the CDROM as first, then change that to SCSI drive after installing. Oh, nothing ever sees the SATA Plextor drive so you have to temporarily install an IDE drive. 2. After installing boot the system with (I used) an Ubuntu live 64 CD. Then you can chroot. My steps were: mount /dev/sda1 /mnt mount /dev/sda2 /mnt/boot etc. chroot /mnt Add sid to your sources list and "apt-get update." Then you can install the newest kernel and headers which today was 2.6.11-9. There was an error that suggested mounting /proc as well. Did that and it worked fine. 3. Because of that bug in grub I then boot the machine with Knoppix (a 32 bit version). OK, so I wasn't patient enough to figure out what I was doing wrong in Ubuntu. Like I said, I never claimed these were the most concise steps. Once booted into Knoppix (3.9 I think): mount /dev/sda2 /boot grub-install /dev/sda 4. Reboot the machine moving your Cat5 plug to the first on-board NIC. You will now be presented with a lovely grub boot menu. Oh, don't forget to change the boot order in your BIOS to the SCSI drive first. Freaking BIOS bug. Anyway... The machine should now boot up OK and go into the usual configuration process. I ran into one more glitch where after downloading all the packages the process hung. I rebooted and followed the steps again and everything worked fine. At this point X isn't working, but I'll get that figured out. I'm just really happy to finally have sarge installed on this beast. Oh, last week I did install Ubuntu on the machine and the Plextor SATA drive was found and worked fine, so I'm guessing I'll be able to get that to work with a little experimentation. Thanks much to everyone who took the time to respond to my posts on this. I hope what I've outlined above will help someone else with this or similar hardware. Cheers, Gary -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscr
Re: Almost there
On Tue July 19 2005 03:30 am, A J Stiles wrote: > There seem to be many reports on this list of people having problems with > the grub bootloader. Is there a good reason for using grub instead of > lilo, or is it just "trendy" ? Trendy? Grub is to old now to be called trendy. Lilo is the trendy one.. ;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Almost there
On 7/19/05, A J Stiles <[EMAIL PROTECTED]> wrote: There seem to be many reports on this list of people having problems with thegrub bootloader. Is there a good reason for using grub instead of lilo, oris it just "trendy" ? I use grub since years now and did not have any issues at all with it. I find it much more comfortable to simply edit the menu.lst on changes, e.g. updated kernels, and having easy-to-configure fallback boot environments in the menu.lst. Grub is also very handy when you need to change your boot configuration from the outside, e.g. from a Knoppix or chrooted system. Of course you need to know what you are doing, like with all bootloaders, but at least for me grub is more than just trendy (compared to lilo). -- Best regards / Mit den besten GrüssenSven Krahn
Re: Almost there
There seem to be many reports on this list of people having problems with the grub bootloader. Is there a good reason for using grub instead of lilo, or is it just "trendy" ? -- AJS delta echo bravo six four at earthshod dot co dot uk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Almost there
On Monday 18 July 2005 05:52 pm, Gary Hodges wrote: ... > /dev/sda1 (/boot) is ext2 and all the other partitions are ReiserFS. > I'm using the standard kernel included with the debian installer. Note > that I'm not using what is considered to be the stable installer, but a > daily build I found somewhere. It is build 7-6-2005. The stable > installer doesn't see the on-board NIC. I believe all the installers > are using the same kernel (2.6.8-11). I don't know if initrd was > created correctly. Is there a way to test it? It's looking as if GRUB is not the problem, which leaves the initrd. The short answer to your question is "I don't know." The long answer is that it might be documented in /usr/share/doc/kernel ... I would think that if the installer allowed you to create a ReiserFS file system, that the kernel & initrd supplied with the installer would be capable of mounting it, but stranger things have happened. At this point, I have two thoughts. First, it's time to go home, have a beer and a good night's sleep & work on this again, in the morning -- which is what I'm about to do! My second thought is to fire-up Knoppix again. Chroot into /dev/sda2. Mount /dev/sda1 as boot on /dev/sda2 and then install another, more current kernel or, even, compile your own with make-kpkg. But, if you're not familiar with all this, this too would be better left until tomorrow. Cheers, and have a good night! cmr > > There's basically two possible problems, here. Either grub is not > > looking in the right place for your root file system, or it is, but initd > > is unable to mount it. As Sherlock Holmes used to say, "When you've > > eliminated the impossible, whatever is left, however, improbable, must be > > the answer!" ;-) > > Thanks for the comments! > > Gary -- Debian 'Sarge': Registered Linux User #241964 "More laws, less justice." -- Marcus Tullius Ciceroca, 42 BC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Almost there
Mike Reinehr wrote: Gary, On Monday 18 July 2005 04:45 pm, Gary Hodges wrote: Mike Reinehr wrote: Gary, On Monday 18 July 2005 03:31 pm, Gary Hodges wrote: Frederik Schueler wrote: Hello, On Mon, Jul 18, 2005 at 01:07:22PM -0600, Gary Hodges wrote: pivot_root: No such file or directory /sbin/init: 432: cannot open dev/console: No such file Kernel panic: Attempted to kill init! Make sure your boot-loader loads the initrd along with the kernel. There's no question that the initd is being loaded. That is what is giving you the error message. All the drivers necessary to mounting the HD have been loaded and it is attempting to mount the root partition and switch to it. Thanks for the reply. I just went through the boot steps by hand and I'm fairly sure initrd has been loaded. Here is what one of my grub menu options looks like: root (hd0,0) kernel /vmlinuz root=/dev/sda2 ro console=tty0 initrd /initrd.img savedefault boot When you were running Knoppix, did you actually take a look at /dev/sda2 to make sure that you had a root file system there? It should already have been mounted automatically by Knoppix and shown up on the desktop as an icon. I just booted to Knoppix again to make sure. Here is what I found: [EMAIL PROTECTED] df -h FilesystemSize Used Avail Use% Mounted on /dev/root 3.4M 17K 3.4M 1% / /dev/hda 696M 696M 0 100% /cdrom /dev/cloop1.9G 1.9G 0 100% /KNOPPIX /ramdisk 2.6G 4.8M 2.6G 1% /ramdisk /UNIONFS 4.5G 1.9G 2.6G 43% /UNIONFS /UNIONFS/dev/sda1 89M 6.7M 77M 8% /mnt/sda1 /UNIONFS/dev/sda2 957M 88M 870M 10% /mnt/sda2 [EMAIL PROTECTED] ls /mnt/sda1 System.map-2.6.8-11-amd64-k8-smp initrd.img-2.6.8-11-amd64-k8-smp config-2.6.8-11-amd64-k8-smp lost+found grub vmlinuz initrd.imgvmlinuz-2.6.8-11-amd64-k8-smp [EMAIL PROTECTED] ls /mnt/sda2 bin cdrom etc initrd lib64 mnt proc sbin sys usr boot devhome lib media opt root srv tmp var If all else fails, you might have to boot off of a Knoppix cd & rerun grub-install. I have booted off a knoppix CD and tried running grub-install. For kicks I just went through the procedure again. Here are the steps performed while booted under Knoppix: [EMAIL PROTECTED] grub-install /dev/sda Installation finished. No error reported. This is the contents of the device map /boot/grub/device.map. Check if this is correct or not. If any of the lines is incorrect, fix it and re-run the script `grub-install'. (hd0) /dev/sda (hd1) /dev/sdb [EMAIL PROTECTED] grub GNU GRUB version 0.95 (640K lower / 3072K upper memory) grub> root (hd0,0) Filesystem type is ext2fs, partition type 0x83 grub> setup (hd0) Checking if "/boot/grub/stage1" exists... no Checking if "/grub/stage1" exists... yes Checking if "/grub/stage2" exists... yes Checking if "/grub/e2fs_stage1_5" exists... yes Running "embed /grub/e2fs_stage1_5 (hd0)"... 16 sectors are embedded. succeeded Running "install /grub/stage1 (hd0) (hd0)1+16 p (hd0,0)/grub/stage2 /grub/menu .lst"... succeeded Done. When you did your initial install, did you create a separate boot partition? Grub, definitely, is finding it's boot files on /dev/sda1. I did. That is /dev/sda1. What file system did you use when creating the root file system? Are you using a standard kernel, or did you compile your own? Was the initd created with the correct drivers to mount the root file system? /dev/sda1 (/boot) is ext2 and all the other partitions are ReiserFS. I'm using the standard kernel included with the debian installer. Note that I'm not using what is considered to be the stable installer, but a daily build I found somewhere. It is build 7-6-2005. The stable installer doesn't see the on-board NIC. I believe all the installers are using the same kernel (2.6.8-11). I don't know if initrd was created correctly. Is there a way to test it? There's basically two possible problems, here. Either grub is not looking in the right place for your root file system, or it is, but initd is unable to mount it. As Sherlock Holmes used to say, "When you've eliminated the impossible, whatever is left, however, improbable, must be the answer!" ;-) Thanks for the comments! Gary -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Almost there
Hello, On Mon, Jul 18, 2005 at 01:07:22PM -0600, Gary Hodges wrote: > pivot_root: No such file or directory > /sbin/init: 432: cannot open dev/console: No such file > Kernel panic: Attempted to kill init! Make sure your boot-loader loads the initrd along with the kernel. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Almost there
Gary, On Monday 18 July 2005 04:45 pm, Gary Hodges wrote: > Mike Reinehr wrote: > >Gary, > > > >On Monday 18 July 2005 03:31 pm, Gary Hodges wrote: > >>Frederik Schueler wrote: > >>>Hello, > >>> > >>>On Mon, Jul 18, 2005 at 01:07:22PM -0600, Gary Hodges wrote: > pivot_root: No such file or directory > /sbin/init: 432: cannot open dev/console: No such file > Kernel panic: Attempted to kill init! > >>> > >>>Make sure your boot-loader loads the initrd along with the kernel. > > > > There's no question that the initd is being loaded. That is what is > > giving you the error message. All the drivers necessary to mounting the > > HD have been loaded and it is attempting to mount the root partition and > > switch to it. > > > >>Thanks for the reply. I just went through the boot steps by hand and > >>I'm fairly sure initrd has been loaded. Here is what one of my grub > >>menu options looks like: > >> > >>root (hd0,0) > >>kernel /vmlinuz root=/dev/sda2 ro console=tty0 > >>initrd /initrd.img > >>savedefault > >>boot > >> > >>There is something funny there though. root is actually on sda1. Also > >>the savedefault command doesn't work when running those commands > >>manually. When I step through each command manually, changing to sda1 > >>obviously, everything looks fine to me (with the exception of > >>savedefault responding with a command not found error). > >> > >>When I edit the command to change sda2 to sda1, upon reboot it has been > >>changed back to sda2. All attempts to boot the machine result in the > > > > When you boot and receive the GRUB boot menu, use the cursor key to go > > down or up to highlight the boot option you've quoted above. (This also > > will stop the clock.) Then press 'e' to edit the boot entry. Once there, > > cursor down to the kernel line and again press 'e' to edit the line, > > changing > >'root=/dev/sda2' to 'root=/dev/sda1'. Hit 'esc' to exit the line and then > >press 'b' to boot. If your root file system is, in fact, located on > > /dev/sda1 then you should be able to successfully boot. > > My mistake. My root file system / is actually sda2. I checked some > other machines and slash is what this root refers to. I won't call this > a moot point, but it doesn't matter if it is set to sda1 or sda2 as I > get the same results. When you were running Knoppix, did you actually take a look at /dev/sda2 to make sure that you had a root file system there? It should already have been mounted automatically by Knoppix and shown up on the desktop as an icon. > > If all else fails, you might have to boot off of a Knoppix cd & rerun > >grub-install. > > I have booted off a knoppix CD and tried running grub-install. For > kicks I just went through the procedure again. Here are the steps > performed while booted under Knoppix: > > [EMAIL PROTECTED] grub-install /dev/sda > Due to a bug in xfs_freeze, the following command might produce a > segmentation > fault when /boot/grub is not in an XFS filesystem. This error is > harmless and > can be ignored. > xfs_freeze: specified file ["/boot/grub"] is not on an XFS filesystem > Installation finished. No error reported. > This is the contents of the device map /boot/grub/device.map. > Check if this is correct or not. If any of the lines is incorrect, > fix it and re-run the script `grub-install'. > > (hd0) /dev/sda > (hd1) /dev/sdb > > [EMAIL PROTECTED] grub > GNU GRUB version 0.95 (640K lower / 3072K upper memory) > > [ Minimal BASH-like line editing is supported. For the first word, TAB >lists possible command completions. Anywhere else TAB lists the > possible completions of a device/filename. ] > > grub> root (hd0,0) > Filesystem type is ext2fs, partition type 0x83 > > grub> setup (hd0) > Checking if "/boot/grub/stage1" exists... no > Checking if "/grub/stage1" exists... yes > Checking if "/grub/stage2" exists... yes > Checking if "/grub/e2fs_stage1_5" exists... yes > Running "embed /grub/e2fs_stage1_5 (hd0)"... 16 sectors are embedded. > succeeded > Running "install /grub/stage1 (hd0) (hd0)1+16 p (hd0,0)/grub/stage2 > /grub/menu > .lst"... succeeded > Done. > > Gary When you did your initial install, did you create a separate boot partition? Grub, definitely, is finding it's boot files on /dev/sda1. What file system did you use when creating the root file system? Are you using a standard kernel, or did you compile your own? Was the initd created with the correct drivers to mount the root file system? There's basically two possible problems, here. Either grub is not looking in the right place for your root file system, or it is, but initd is unable to mount it. As Sherlock Holmes used to say, "When you've eliminated the impossible, whatever is left, however, improbable, must be the answer!" ;-) Cheers! cmr -- Debian 'Sarge': Registered Linux User #241964 "More laws, less justice." -- Marcus Tullius Ciceroca, 42 BC -- To
Re: Almost there
Frederik Schueler wrote: Hello, On Mon, Jul 18, 2005 at 01:07:22PM -0600, Gary Hodges wrote: pivot_root: No such file or directory /sbin/init: 432: cannot open dev/console: No such file Kernel panic: Attempted to kill init! Make sure your boot-loader loads the initrd along with the kernel. Thanks for the reply. I just went through the boot steps by hand and I'm fairly sure initrd has been loaded. Here is what one of my grub menu options looks like: root (hd0,0) kernel /vmlinuz root=/dev/sda2 ro console=tty0 initrd /initrd.img savedefault boot There is something funny there though. root is actually on sda1. Also the savedefault command doesn't work when running those commands manually. When I step through each command manually, changing to sda1 obviously, everything looks fine to me (with the exception of savedefault responding with a command not found error). When I edit the command to change sda2 to sda1, upon reboot it has been changed back to sda2. All attempts to boot the machine result in the Kernel panic. Gary -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Almost there
Mike Reinehr wrote: Gary, On Monday 18 July 2005 03:31 pm, Gary Hodges wrote: Frederik Schueler wrote: Hello, On Mon, Jul 18, 2005 at 01:07:22PM -0600, Gary Hodges wrote: pivot_root: No such file or directory /sbin/init: 432: cannot open dev/console: No such file Kernel panic: Attempted to kill init! Make sure your boot-loader loads the initrd along with the kernel. There's no question that the initd is being loaded. That is what is giving you the error message. All the drivers necessary to mounting the HD have been loaded and it is attempting to mount the root partition and switch to it. Thanks for the reply. I just went through the boot steps by hand and I'm fairly sure initrd has been loaded. Here is what one of my grub menu options looks like: root (hd0,0) kernel /vmlinuz root=/dev/sda2 ro console=tty0 initrd /initrd.img savedefault boot There is something funny there though. root is actually on sda1. Also the savedefault command doesn't work when running those commands manually. When I step through each command manually, changing to sda1 obviously, everything looks fine to me (with the exception of savedefault responding with a command not found error). When I edit the command to change sda2 to sda1, upon reboot it has been changed back to sda2. All attempts to boot the machine result in the When you boot and receive the GRUB boot menu, use the cursor key to go down or up to highlight the boot option you've quoted above. (This also will stop the clock.) Then press 'e' to edit the boot entry. Once there, cursor down to the kernel line and again press 'e' to edit the line, changing 'root=/dev/sda2' to 'root=/dev/sda1'. Hit 'esc' to exit the line and then press 'b' to boot. If your root file system is, in fact, located on /dev/sda1 then you should be able to successfully boot. My mistake. My root file system / is actually sda2. I checked some other machines and slash is what this root refers to. I won't call this a moot point, but it doesn't matter if it is set to sda1 or sda2 as I get the same results. If all else fails, you might have to boot off of a Knoppix cd & rerun grub-install. I have booted off a knoppix CD and tried running grub-install. For kicks I just went through the procedure again. Here are the steps performed while booted under Knoppix: [EMAIL PROTECTED] grub-install /dev/sda Due to a bug in xfs_freeze, the following command might produce a segmentation fault when /boot/grub is not in an XFS filesystem. This error is harmless and can be ignored. xfs_freeze: specified file ["/boot/grub"] is not on an XFS filesystem Installation finished. No error reported. This is the contents of the device map /boot/grub/device.map. Check if this is correct or not. If any of the lines is incorrect, fix it and re-run the script `grub-install'. (hd0) /dev/sda (hd1) /dev/sdb [EMAIL PROTECTED] grub GNU GRUB version 0.95 (640K lower / 3072K upper memory) [ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename. ] grub> root (hd0,0) Filesystem type is ext2fs, partition type 0x83 grub> setup (hd0) Checking if "/boot/grub/stage1" exists... no Checking if "/grub/stage1" exists... yes Checking if "/grub/stage2" exists... yes Checking if "/grub/e2fs_stage1_5" exists... yes Running "embed /grub/e2fs_stage1_5 (hd0)"... 16 sectors are embedded. succeeded Running "install /grub/stage1 (hd0) (hd0)1+16 p (hd0,0)/grub/stage2 /grub/menu .lst"... succeeded Done. Gary -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Almost there
Gary, On Monday 18 July 2005 03:31 pm, Gary Hodges wrote: > Frederik Schueler wrote: > >Hello, > > > >On Mon, Jul 18, 2005 at 01:07:22PM -0600, Gary Hodges wrote: > >>pivot_root: No such file or directory > >>/sbin/init: 432: cannot open dev/console: No such file > >>Kernel panic: Attempted to kill init! > > > >Make sure your boot-loader loads the initrd along with the kernel. There's no question that the initd is being loaded. That is what is giving you the error message. All the drivers necessary to mounting the HD have been loaded and it is attempting to mount the root partition and switch to it. > Thanks for the reply. I just went through the boot steps by hand and > I'm fairly sure initrd has been loaded. Here is what one of my grub > menu options looks like: > > root (hd0,0) > kernel /vmlinuz root=/dev/sda2 ro console=tty0 > initrd /initrd.img > savedefault > boot > > There is something funny there though. root is actually on sda1. Also > the savedefault command doesn't work when running those commands > manually. When I step through each command manually, changing to sda1 > obviously, everything looks fine to me (with the exception of > savedefault responding with a command not found error). > > When I edit the command to change sda2 to sda1, upon reboot it has been > changed back to sda2. All attempts to boot the machine result in the When you boot and receive the GRUB boot menu, use the cursor key to go down or up to highlight the boot option you've quoted above. (This also will stop the clock.) Then press 'e' to edit the boot entry. Once there, cursor down to the kernel line and again press 'e' to edit the line, changing 'root=/dev/sda2' to 'root=/dev/sda1'. Hit 'esc' to exit the line and then press 'b' to boot. If your root file system is, in fact, located on /dev/sda1 then you should be able to successfully boot. Once you've booted successfully, look for the file /boot/grub/menu.lst, which will contain the above boot stanza. Edit that and you should have changed it permanently. If all else fails, you might have to boot off of a Knoppix cd & rerun grub-install. > Kernel panic. > > Gary HTH's cmr -- Debian 'Sarge': Registered Linux User #241964 "More laws, less justice." -- Marcus Tullius Ciceroca, 42 BC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]