On Mon, 27 Sep 2010 21:19:28 -0400 (EDT), bri...@aracnet.com wrote: > On Mon, 27 Sep 2010 10:09:15 -0400 (EDT), Stephen Powell wrote: >> >> You had several unrelated problems. >> >> (1) The initial RAM disk specifications were missing from the two >> boot menu items in /etc/lilo.conf that used the standard symlinks. >> Therefore, neither of these two entries would boot at all. > > yep. interestingly that was _not_ the problem with one of the > entries that I tried: > > image=/boot/vmlinuz-2.6.32-5-amd64 > label="Lin 2.6.32img5" > initrd=/boot/initrd.img-2.6.32-5-amd64 > read-only > > so there's a bit of a mystery there.
If I recall correctly, you got farther with this one than you did with the one that had a missing initrd entry. You were able to boot this one with a root file system override, whereas the one with the missing initrd entry would not boot at all. >> >> Now, with your indulgence, I'd like to suggest some >> further changes that will make your setup more robust. For example, >> I notice that you have other kernels in your boot menu, such as >> 2.6.32-3. This kernel currently will probably not boot. I suggest >> the following changes in /etc/lilo.conf: > > I see what you're doing here but I'm very reluctant to change a working > set-up. Right now, it's only a working setup for one kernel: 2.6.32-5-amd64. If you're not going to make these changes, you might as well de-install the other kernels. They will not boot, so what good are they? What 2.6.32-5-amd64 calls /dev/sda is a PATA disk, which will be treated as /dev/hda by all the other kernels. > > You're right, of course. The first time I throw a new disk in the > machine things will break. So eventually I need to switch over to > uuid/by-id. That's not the point. It is possible that adding another disk may change the device names. But it is certain that booting any kernel other than 2.6.32-5 will change the device names. > > uuid is very annoying because I can't look at it and know what's > going on. I agree. That's why I add comments to /etc/fstab. >> Change >> >> boot=/dev/sda >> >> to >> >> boot=/dev/disk/by-id/ata-WDC_WD2500YS-01SHB0_WD-WCANY2148692 >> >> Change >> >> root=/dev/sda2 >> >> to >> >> root="UUID=a948d6b6-8395-49a1-9f0f-21a10ceee9c2" >> >> In /etc/initramfs-tools/conf.d/resume, change >> >> RESUME=/dev/sda4 >> >> to >> >> RESUME=UUID=558d7790-5914-494d-938f-3387296eed45 > > well the problem with this is that it DID use the UUID form, and that > wouldn't work. So I'm _very_ reluctant to put it back. I understand. But there were multiple problems, any one of which may have caused a boot failure. We have them all fixed now. And I will stay with you until you get it working. In the case of the resume file, I suspect that although it used the uuid form, it was using the wrong uuid (an old one). By default, the uuid changes whenever the partition is re-formatted (mkswap). Do you share a swap partition between, say, a Debian system and an Ubuntu system? The Ubuntu installer is known to reformat a swap partition, which will change its uuid, which will break the Debian system. That's just one example. (Perhaps there is an option to skip the formatting of the swap partition, or to re-use its existing uuid. But I've never installed Ubuntu; so I don't know.) >> >> You never did post the contents of your /etc/fstab file. >> I'd still like to see that. >> > > # /etc/fstab: static file system information. > # > # <file system> <mount point> <type> <options> <dump> <pass> > proc /proc proc defaults 0 0 > /dev/sda2 / ext3 defaults,errors=remount-ro 0 1 > /dev/sda3 /home ext3 defaults 0 2 > /dev/sda4 none swap sw 0 0 > ... > > bunch of other crap like temporary devices and nfs mounts deleted... Thanks. I suggest the following here: # /etc/fstab: static file system information. # # <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc defaults 0 0 UUID=a948d6b6-8395-49a1-9f0f-21a10ceee9c2 / ext3 defaults,errors=remount-ro 0 1 # /dev/sda2 / ext3 defaults,errors=remount-ro 0 1 UUID=4b764501-da53-4323-a751-3da37d7e2a91 /home ext3 defaults 0 2 # /dev/sda3 /home ext3 defaults 0 2 UUID=558d7790-5914-494d-938f-3387296eed45 none swap sw 0 0 # /dev/sda4 none swap sw 0 0 ... >> I see from other posts that you use an Nvidia graphics >> card. I now have a new section at the end of my kernel building >> guide that explains how to create a custom kernel that uses the >> proprietary Nvidia drivers built the traditional Debian way. It is >> called "A Specific Example". You may wish to review that section. > > Naturally :-) I just did an upgrade yesterday and I noticed that new versions of the 71xx and 96xx legacy driver packages have been recently uploaded to the archive. If your machine needs one of those driver packages, then the web page is out-of-date already. :-( I will have to experiment with the new packages and revise the web page accordingly. If you use the 173xx legacy or the current package, then the web page should (hopefully) still be current. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1980597816.332928.1285687246910.javamail.r...@md01.wow.synacor.com