Linux Mint 7 Will Not Boot [56K Warning]

[EchoLynx]

This started about a month and a half ago, but I've not had the chance to troubleshoot it until now.

Description of Boot:
1. Power button pressed.
2. POST
3. GRUB menu (I had shortened the amount of time till autoboot to 3 seconds)
4. Linux mint splash screen with bar bouncing from left to right
5. Following Error:

Code: Select all

init: rc5 main process (863) killed by SEGV signal
init: rc-default main process (864) killed by SEGV signal

I am dual booting Windows and can still access Windows without a hitch.

I've no idea where to start.

[rich_roast]

I think we're going to need a bit more than that.

rc5 refers to the graphical mode bootscripts, which call programs to set up your hardware and your environment. I suppose rc-default would be the same as graphical since that is Mint's default mode. Script no. 863 (seems high to me - am I understanding how bootscripts work ackbassward?) is causing the kernel to kill it because the program it's invoking is trying to write or read outside of the memory allocated to it. This is stopping your boot sequence from completing.

So the question is which bootscript is causing the problem, and can it be replaced or gotten rid of. To find out, I suppose you could try accessing /etc/rc.5/ from Windows, if you can mount the Mint partition there, alternatively try to boot in recovery mode (that particular bootscript might not run in rc, 3, which if memory serves is text mode boot).

What I'm not sure of is whether the number in parenthesis does refer to the number of the script (the scripts have numbers to determine which order they run in). Like I said, 863 seems jolly high, and arbitrary, to me, so perhaps someone can set the record straight. In any event, my worry is that even if we can see inside /etc/rc.5/, we still might not be able to tell which script is causing the problem, or which program might need to be replaced.

All said and done, if there's nothing precious on the partition a fresh install might just be in order... unless this *is* a fresh install in which case Mint must be incompatible with some item of your hardware in ways I've never seen before.

[EchoLynx]

rich_roast:
Thank you for your insight. To further our joint confusion concerning the numbers in parenthesis, they aren't the same every time they boot. I am thinking they have to do with the amount of time between the GRUB bootloader and the error message, but what do I know? Booting in recovery (verbose) mode does lead me to think that a specific script is failing, though. (See below.)
--

IMG_3377.JPG

IMG_3388.JPG

IMG_3390.JPG

--
Looking at the second two images makes me think that whatever follows /scripts/init-bottom causes the failure.

[EchoLynx]

Polite request for attention.

[rich_roast]

OK, I had a quick look into this. I'm afraid at this stage I'm a little out of my depth, so the following is just a flailing noob's thoughts.

We do know that the script in question is udev, but it's the one in /usr/share/initramfs-tools/scripts/init-bottom, judging from the output. I don't know why it's being invoked, because the S10udev in /etc/rcS/ will get rid of anything that initramfs builds anyway:

Code: Select all

if mountpoint -q /dev; then
		# uh-oh, initramfs made some kind of /dev, get rid of it
		umount -l /dev
	    fi

So my initial suggestion would be to head into /usr/share/initramfs-tools/scripts/init-bottom and bin udev, by which I mean carefully move it to a backup folder.

Will it work? Who knows.

[EDIT:] Wait, I just looked at the photos again and spotted "Done." just underneath the init-bottom call. Which suggests that initramfs's udev isn't breaking, but I still stand by my initial suggestion since it might be breaking S10udev for reasons I don't even begin to start understanding.

At least we know roughly where we are in the boot process when it fails. The only other suggestions I've ever heard of in cases like these include passing -noapic and/or -noacpi to the kernel, messing with BIOS settings, up to and including the rather drastic removal of video cards. It's worth noting that the script which runs just before S10udev is S07linux-restricted-modules-common, which might be connected with a buggy BIOS/graphics card interaction.