Cassandra boot fails

[jiminid]

Hi everybody,
installed cassandra ok but when I boot it it gives me a terminal screen that says
fsck died with exit status 8

file system check failed
have to manually edit file system?

then says it will try to create a log file and I can cntrl D to continue booting and here I am. Here is the log:

fsck 1.40-WIP (14-Nov-2006)
/dev/sdb15: clean, 550/2692800 files, 129236/5375742 blocks
/dev/sdb10: clean, 11/2048000 files, 107068/4094559 blocks
/dev/sdb11: clean, 228/2692800 files, 131835/5375742 blocks (check after next mount)
/dev/sdb13: clean, 11/3973536 files, 168764/7934094 blocks
/dev/sdb14: clean, 1086/3329280 files, 183659/6654918 blocks
fsck.ext3: Unable to resolve 'UUID=9858d6ad-fba2-4bc1-94eb-7493c4822f2e'

fsck.ext3: Unable to resolve 'UUID=1fb7c9d8-de7f-45b8-93bd-db405d00adba'

/dev/sdb2: clean, 85726/1409024 files, 607872/2815391 blocks
/dev/sdb3: clean, 94944/1409024 files, 611226/2815391 blocks
/dev/sdb5: clean, 2798/2692800 files, 289271/5375742 blocks
/dev/sdb6: clean, 84653/1409024 files, 568736/2815383 blocks
/dev/sdb7: clean, 1940/2692800 files, 142812/5375742 blocks
/dev/sdb8: clean, 105453/1409024 files, 608298/2815383 blocks
/dev/sdb9: clean, 1236/2692800 files, 131627/5375742 blocks
fsck died with exit status 8

Bit of a newbie here. need some help. Am wondering if this has something to do with installing grub into the cassandra root partition and chainloading the boot from my pclinuxos main grub. works fine for feisty and mepis.

btw, what's with the weird error messages? first time I got a quote from james joyce's "Ulysses" and this time got something about nose mittens. Methinks the devs are having more fun than I am.


thanks for your help.

jiminid

[D1Wayne]

check this
https://bugs.launchpad.net/ubuntu/+bug/106209

Snippet:

jerrylamos said on 2007-04-13: (permalink)

Found the cause of the fsck failures:

This is a quad boot system, hda1 Win98, hda2 Dapper, hdb1 Edgy, hdb3 Feisty.

When I re-installed hdb1 Edgy after a failed attempt at installing Xubuntu Feisty ( Feisty ext3 format fails, Edgy's works ), must be the UUID changes? /dev/hdb1 didn't.

[jiminid]

check this
https://bugs.launchpad.net/ubuntu/+bug/106209

Snippet:

jerrylamos said on 2007-04-13: (permalink)

Found the cause of the fsck failures:

This is a quad boot system, hda1 Win98, hda2 Dapper, hdb1 Edgy, hdb3 Feisty.

When I re-installed hdb1 Edgy after a failed attempt at installing Xubuntu Feisty ( Feisty ext3 format fails, Edgy's works ), must be the UUID changes? /dev/hdb1 didn't.

Thanks D1Wayne,
Unfortunately, it doesn't apply, as I am simply adding Cassandra to a multiboot system: Pclinuxos 2007, Mepis 6.5.02, Ubuntu feisty 7.04 and now Cassandra all on hdb, with win xp on hda. I'm sure it's the same bug but I can't fix mine by commenting out the leftovers from previous installation since there wasn't one. any other ideas?

thanks for your help.

[Boo]

I would edit the fstab file and replace those UUID entries with the dev ones listed above them, eg /dev/sdb14.

then you could try a manual fsck on the device that goes bad, if it still does.

BTW was there a limit to the number of partitions you can put on a disk? like 15?
edit: no i was going crazy

[D1Wayne]

ditto that thought Boo

but then there is the
/boot/grub/menu.list
entries that sometimes gets slammed as well
and while your in the area verify yoor
/boot/grub/device.map
and that they look ok,
or the next kernel update might bite you in the behind:)

uuids have changed on me 2 out of 3 installs.

[jiminid]

I would edit the fstab file and replace those UUID entries with the dev ones listed above them, eg /dev/sdb14.
then you could try a manual fsck on the device that goes bad, if it still does.

but then there is the
/boot/grub/menu.list entries that sometimes gets slammed as well
and while your in the area verify yoor /boot/grub/device.map
and that they look ok, or the next kernel update might bite you in the behind:)

Thanks for the ideas, D1Wayne, Boo
will edit fstab when I get home. (what is a device.map supposed to look like?)(How do I do a manual fsck on an individual device?) The menu.lst is unlikely to be the problem, as I install all of my Ops grubs into their own root partition, then I edit my main grub, which is installed onto the mbr, to chainload all of my individual ops. i.e.

title Linux Name version whatever
rootnoverify (hdx,y)
chainloader +1

(I think)

that way, when I upgrade, my main grub is just pointing to the root partition of each of my ops and they boot from there, takes a little bit longer but eliminates the need for an edit every time I upgrade. btw, Cassandra works fine that way, I select cassandra on my main grub boot page and she boots onto her grub page which lists all the ops and options her grub has and/or found. When it boots out of that page is when the bug bytes. (How would I know what her menu.lst is supposed to look like?)

btw Ubuntu Feisty works fine with no bug. Isn't cassandra based on feisty?
isn't that where the bug comes from?
edit-(er, no, it doesn't, feisty is dead, will try to back out of that kernel in that sys as well)


thanks for your help.

[Lolo Uila]

This is due to the 2.6.20-16 kernel update which is really messed up. There are a number of problems with the new kernel and it's wreaking havoc with people running Feisty on Intel ICH4/5 & 6 controllers.

http://www.linuxmint.com/forum/viewtopic.php?t=2894

https://bugs.launchpad.net/ubuntu/+sour ... bug/116996

are just the tip of the iceberg. If you google around you can find loads of other threads about problems with the new 2.6.20-16 kernel. There are a number of work-arounds people are trying, but your best bet is to select the previous 2.6.20-15 kernel from the Grub boot menu. That worked for me.

Oh, and DO NOT edit out the UUIDs in fstab. That will make things worse!

[jiminid]

This is due to the 2.6.20-16 kernel update which is really messed up. There are a number of problems with the new kernel and it's wreaking havoc with people running Feisty on Intel ICH4/5 & 6 controllers.

http://www.linuxmint.com/forum/viewtopic.php?t=2894

https://bugs.launchpad.net/ubuntu/+sour ... bug/116996

are just the tip of the iceberg. If you google around you can find loads of other threads about problems with the new 2.6.20-16 kernel. There are a number of work-arounds people are trying, but your best bet is to select the previous 2.6.20-15 kernel from the Grub boot menu. That worked for me.

Oh, and DO NOT edit out the UUIDs in fstab. That will make things worse!

Oh, Now you tell me...
no prob, got to practice my cli skills such as they are...think I'll install cassandra on the amd 64 box I'm building, no intel there at all! mmmh, now I've got 2 more partitions to stick another OS in...what fun! I've got pclos, ubuntu, mepis and poor dead cassandra with an intel dagger through her heart.
What linux os should I test on her quivering corpse?

All suggestions welcome.

Thanks again, everyone!

[Lolo Uila]

Try and select the previous 2.6.20-15 kernel from the Grub boot menu (hit esc when Grub is launching). That should allow you to successfully boot. Once in Cassandra use Synaptic to locate the 2.6.20-16 kernel components that were installed (search for 2.6.20-16) and tag them for complete removal (there were 4 items on my system). Once you apply and restart you should fine.

Aloha, Tim

[screamin_jesus]

Try and select the previous 2.6.20-15 kernel from the Grub boot menu (hit esc when Grub is launching). That should allow you to successfully boot. Once in Cassandra use Synaptic to locate the 2.6.20-16 kernel components that were installed (search for 2.6.20-16) and tag them for complete removal (there were 4 items on my system). Once you apply and restart you should fine.

Aloha, Tim

I had to do this yesterday, but I tagged them for removal, not complete removal, could this cause problems? (ub3r noob)

[Lolo Uila]

Just "removal" should be fine. In this case it seems to do the same thing (comparing the "To be removed" dialog for both).

[jiminid]

Try and select the previous 2.6.20-15 kernel from the Grub boot menu (hit esc when Grub is launching). That should allow you to successfully boot. Once in Cassandra use Synaptic to locate the 2.6.20-16 kernel components that were installed (search for 2.6.20-16) and tag them for complete removal (there were 4 items on my system). Once you apply and restart you should fine.

Aloha, Tim

Thanks Tim! er, Lolo Uila, er Whateveryournameis!
Just what I was looking for, some way to save the life of my beautiful dead cassandra-I don't understand why she never warned me this would happen? tho I probably wouldn't have believed her.
Will check out this procedure tonight and let you know how it works.

thanks for your help!

[jiminid]

Hi everybody,
choosing the 2.6.20-15 didn't work, in fact it gave me the same "unable to find /home directory and user doesn't have the 644 permissions" error on the login page that I'm now getting from ubuntu 7.04. so, I reinstalled mint but got the same fsck error from before-hit enter, then ctlshiftD and it does finish booting. so I go into synaptic and after the update completely remove all of the references to 2.6.20-16-then reboot-now there is only 2.6.20-15 on the menu but I get the same fsck error and boot in in the same way-so it's not the kernel, at least on my machine...celeron 352 3.2 ghz, ecs 661GX-M7 motherboard-has a SIS 661 GX North Bridge and SIS 964L South Bridge chipset. maybe have to back up to -14?

Any ideas on how to fix this?

Thanks for your help.

[Husse]

This is a long thread.....
I think it still can be that UUID thing. I got the error you got jiminid on my secondary computer.
It was solved by commenting out all the UUID and replacing it with the appropriate number in /dev/hda
There wasn't even an error after that...

[GStorm]

It's the UUID thing, definitely. What I do on my multi-boot is:

sudo vol_id /dev/hdx -u (where x is the location of the offending partition)--this will display the UUID you need to...

sudo gedit /etc/fstab

...and replace the UUID for the offending partition with the new one you got from vol_id.

[jiminid]

This is a long thread.....
I think it still can be that UUID thing. I got the error you got jiminid on my secondary computer.
It was solved by commenting out all the UUID and replacing it with the appropriate number in /dev/hda
There wasn't even an error after that...

thanks husse-will try this out-
so I go into fstab and put a # in front of all of the lines that have uuids in them. then create a new line for each partition so commented out and replace the uuids with /dev/hdx?

[Husse]

Yes
I have commented out (#) the UUID line then on the next line put the appropriate /dev/hdx
Then split the line with the UUID right after it and copy/pasted it after /dev/hdx
As this could ruin your system, back up fstab (sudo cp /etc/fstab /etc/fstab.bak) In reovery mode you could bring back the original fstab.
This thread is so long so I have not read it again, so I don't know how hard you were hit in the first place - backing up might not be needed