On Wed, 09 Jan 2013 17:45:10 -0500, Tom H wrote: > On Wed, Jan 9, 2013 at 2:31 PM, Hendrik Boom <hend...@topoi.pooq.com> wrote: >> On Tue, 08 Jan 2013 01:42:24 -0500, Tom H wrote: >>> On Mon, Jan 7, 2013 at 1:44 PM, Hendrik Boom <hend...@topoi.pooq.com> wrote: >>>> On Mon, 07 Jan 2013 11:20:45 -0700, Bob Proulx wrote: >>>>> Hendrik Boom wrote: >>>>>> >>>>>> Won't boot. Gets stick at the initramfs prompt after complaining >>>>>> that it can't run /sbin/init >>>>>> >>>>>> I look with ls, and discover that /sbin exists, bit is totally >>>>>> empty. that seems a good reason to be unable to run /sbin/init. >>>>> >>>>> Does seem to be a good reason. I can't remember what is in the bin >>>>> directories of an initrd bootstrapping image. Pretty sure there is at >>>>> least something in /sbin though. And noting that for the most part I >>>>> think you will be working out of a busybox shell which is used to >>>>> reduce the amount of file system storage space needed in that early >>>>> boot time environment. >>>> >>>> Would it really be complaining about missing /sbin/init on the initrd >>>> ramdisk, or about /sbin/init being missing on the real root partition, >>>> which could be caused by not having mounted it yet? >>> >>> There isn't a "/sbin/init" in the initramfs. There's "/init", a shell >>> script. >>> >>> You've reached the point where the initramfs expects the root fs to >>> have been moved. It seems to have failed but I don't understand why >>> there's an empty "/sbin" rather than no "/sbin". >> >> I've taken the initrds apart for the kernel that boots and the kernel >> that doesn't boot. They both seem to have everything they ought to and >> not the empty directories I'm seeing. >> >> That isn't the problem. > > Of course it isn't the problem but it's weird. > > Have you tried to boot with "break=bottom" and assembling > disks/partitions manually?
The first problem was that I hadn't fixed up mdadm.conf and hadn't rebuilt initrd. That fixed, I could find the gpt partitions. But reconfiguring the kernel package also had the effect of overwriting my boot disk, and the version of the system I was running happened not to have a proper lilo configuration, so I ended up with an unusable boot floppy. The lilo.conf was out of date, and referred to a nonexistent root partitino. Somehow, the boot process failed to notice this and instead of the kernel complaining about not having a root partition, it complained about the absence of /sbin/init. Or maybe it found a stray partition and happened to mount it on /root, uselessly. Hard to say. When I use the mount command in the initramfs shell all it'll rell me is that /dev/root is mounted on /. Not very informative. But I managed to boot using an old lilo floppy left over from another Linux I had on the machine a while ago. It still had the ability to boot into squeeze but with an very old kernel. I immediately write-protected the floppy, just in case. Using that, I could edit the lilo.conf file. I inserted a variety of stanzas, requesting different kernels and specifying the (same) root partition in a variety of ways. root=/dev/mapper/VG1-squeezeroot worked. root=/dev/VG1/squeezeroot did not. Both the old and new kernels would boot and find the gpt partitiions, but only the new kernel could access the ext4 file systems on them. But what still doesn't work is booting with grub2. I thing the BIOS is having a hard time figuring out which of my four hard drives to boot. I suppose it's time to look into the BIOS parameters and/or switch cables connecting the disks to the disk controller cards. -- hendrik -- 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/kcn46r$kf0$1...@ger.gmane.org
