Hello all...

Short version:

I installed some stuff, I don't know what, and now I can't mount 5 of my 7 partitions (6 are reiserfs, one is swap). The partitions DO exist, and when I put the drive in another (working) machine, they mount fine. So it's a problem in either the kernel (unlikely: self-compiled 2.6.25.9, amd64, reiserfs support built-in) or... WTH, I don't know.

I can see the partitions on the failed machine using cfdisk and fdisk. They DO exist. They all show up as Linux except for /dev/hda2 (extended) and /dev/hda7 (linux swap / solaris) which is how it's always been.

I'm not finding too much info on the web. What I have found were references to kernel boot parm "hda=remap" (which caused kernel panic on boot) and UUIDs.

I believe (!) that I'm running udev but I'm not sure.

ls /dev/hd* -l brings a list of hda, hda1, hda5 (all mountable) and hda2 (the extended partition which contains 5 through 10), and then hdb (!!! I don't HAVE an hdb!!!) with hdb1, 2, 5, 6, 7, 8, 9, and 10... in essence, it appears that hdB matches what hdA *should* be. Problem is, I can't mount any of hdB partitions either! It tells me they're not valid block devices.


* note: The different DTS here is probably because I opened FDisk, looked at the partition table, and wrote it (I had made no changes and it was after doing this that I tried the disk in another machine successfully, so it did no harm).

I have no /dev/sd*, no /dev/sc*, etc. when I ran MAKEDEV before, it mentioned something about a .udev folder (which I renamed, but now I don't remember where it was) and when I run MAKEDEV now, it just returns to the CL with no output.



"mount" tells me I've currently mounted /dev/hda5, tmpfs, proc, sysfs, procbususb, tmpfs, and devpts if that helps any.

I do not know if I am indeed using udev or devfs, and I do not know how to tell what packages I most recently tried installing unless I can go by the DTS of the packages in /var/cache/apt/archives, which would require I swap the drive back into the other machine (to which I'm not opposed if it saves me from reinstalling from scratch *AGAIN*).


HAAAAAAAAAALLLLP!!!!!!!




I had a lengthy "what led up to this" but let's sum it up as the following:

1) I wanted a program.
2) It didn't exist in Stable.
3) I added an Unstable source.
4) Program still didn't work. Removed program.
5) I thought I also removed Sid from sources.
6) I upgraded a different package.
6b) upgrade required all sorts of dependencies
7) Couldn't figure it out. Agreed to update. Affected no critical programs (I do check).
8) Later on, upgrade something else. Again, all sorts of deps.
9) Discover we still have Sid in sources. Remove Sid. Double check. Yep, it's gone.
10) I install something else
11) Wants to remove some packages, which are replaced by similar-named packages (e.g. xine-ui may become xine-common or similar)
12) Note nothing critical, go ahead and install
13) I reboot later in the evening for unrelated reason, and now cannot mount drives. Specifically, my /usr, /home, /var, and /var/www. So effectively, everything I need. The only ones I can mount are / and /boot.



Any help you can provide is greatly appreciated.

First I'll assume that you have checked your /etc/fstab to verify that it hasn't changed, as in some kind of upgrade that may have replaced it.

Second, drawing on my own experience when I have encountered such a problem (usuassy the result of something I did, not realising the full impact it would have), I'll assume that your system was not in a same state when you rebooted.

As a result, 4 partitions don't mount on boot.

*IF* your fstab has not changed, and *IF* you can boot to command-line mode, try mounting the partitions to their mount points as they appear in fstab: mount -t fstype /dev/hdaX /mount/point.

If you can successfully mount the partitions manually, try doing a normal, complete shutdown (not a reboot). Then power-up the machine. Does the system boot normally?

If not, try running fsck on the partitions from a liveCD.

That's the odd thing: I do have hda1 and hda5, /boot and {root} respectively -- but it just occured to me that these two are both specifically mentioned in my grub menu.lst.

My fstab did not change, I did check that, and a manual attempt to mount the partitions returns something to the effect of "Special device /dev/hda9 does not exist" (I don't have the system running at the moment).

I will try fsck from a bootcd if I can find a bootcd that supports amd64 and 64bit irq addressing (I have noticed that other bootCDs in the past lock up because they can't address all the hardware). Any suggestions on that front?

I'll try with what I've got though -- maybe one of them works...

I'll reply when I have more data but in the meantime I'm wide open to more suggestions...


Thanks,

CJ

Erk - sounds like a problem from mixing the repos, but I don't know Debian hardly at all.
The issue (most likely) isn't the disk itself, but your initscripts and/or initrd - /dev isn't being populated properly. Most of that second disk (*and*) the CD mapping to /dev/hdb2 can't be good.

Maybe check the udev rules (at 2.6.25, you will be using udev).

Wait for a Debian guru to step up - perhaps get this thread moved; hit the "report" button on your first post and ask for it to be moved to Debian.

Okay, I'll do that... I was hoping this wasn't Debian specific but considering the way it updates and the dependencies and all that, and considering most if not all of my sources are Debian official repos, probably would be best...


You mention initscripts... I do vaguely [want to] recall seeing something about that in the synaptic/apt-get outputs... I'll research that as well... Thanks!

For clarification: I only have a single 160 GB hard drive, hda, and a single DVDRW drive, hdc.

I've booted to Knoppix 5 running a 2.6 kernel. Its reiserfsck reports no corruptions on hda6, 8, 9, or 10. I've not checked 1 or 5 yet, but I'm confident they're fine as they mount fine in Debian.

All the partitions mounted fine in Knoppix... (and fwiw I'm finally getting the hang of using FOR loops to make life easier)

cd /mnt; for i in *; do mount /dev/$i -t reiserfs $i; done

Of course, it tried an already mounted /dev/hda1 and /dev/hdc, but oh well. All mounted just fine with no issues. Went through them and randomly picked out files to read/view. They're intact. Life is good but it's been better.


My thoughts at this point:

I'm leaning toward initscripts or udev/dependency-of-udev. Both were touched in my last apt-get, and considering that hda1 and 5 mount just fine for grub (which specifically mentions in its config "root" (where it finds its boot files) being at (hd0,0) and the kernel is given the boot parm "root=/dev/hda5")....

Wait, can I specify on the kernel boot parameters "/usr=/dev/hda6"? I'll look into that too. Regardless, these are the reasons hda1 and hda5 are mounted fine at boot, is that it's done before the kernel is even loaded!


So anyway, I'm thinking it's definitely in that area... problem is, how do I get a system whose /usr is an unmountable partition to apt-get or dpkg a package? I guess I have to manually move files around in a Knoppix session?


Thanks....

CJ

One more thing... earlier, I posted a CODE block with some output in it...

Why would I be showing an hdb when there is only one single drive, as a master, on IDE0?

Do major/minor numbers mean anything there?

http://www.mjmwired.net/kernel/Docum...on/ide/ide.txt
I see hda is supposed to be minor number 0 and hdb minor number 64. That's what I see here. however, I have no hdb! Clearly something is telling dev or udev or whatever that I have a drive that doesn't exist...

Is the minor number a cause of something, or the result of something? Reason I ask, is that if it is the cause of something, it should be able to be changed so that the result (e.g. having hdb in lieu of hda) can change, but if it's the result of something, then what could be changed to cause a minor to be incorrect? Or is that all a function of udev?

[QUOTE=CJ
Clearly something is telling dev or udev or whatever that I have a drive that doesn't exist...

[/QUOTE]

Check your BIOS. Make sure that the BIOS disk configuration corresponds to reality.

------------------
Steve Stites

As requested, moved to Debian

Yep, did that too. All it shows is the HD and the CDROM. I even looked for that setting where it asks if I have a PnP OS, to see if maybe the BIOS could help out the OS, but this bios doesn't have that option.

At this point I'm leaning toward initscripts. I just need to come up with a clever way of doing what I have in mind.

I think the easiest thing to do would be boot the system in Knoppix 5 (it apparently supports amd64 just fine), back up my /home partition (the largest one on the drive, and with about 76 GB or so free), and copy the entire rest of the drive onto that partition. Set that as root, leave /boot where it is, and the system *should* boot because the kernel will automount root whereever I tell it to. Then, live with it for a couple of months until such time as things have changed enough that I can move stuff back around (surely, if it's a bug in inits, it will be fixed in short order when Debian gets a swarm of bug notices). Although, when I submit bug reports, I usually find I do so two years after the last guy... so this is probably old news to them.

I just don't want to do that because it's a heck of a lot of trouble, especially considering how much junk I have in /home. in fact, I have a /home/all which is a kind of shared folder where I keep everything -- music, videos, family pictures... it would be a major hassle to move all that.


Let me ask this, then... Would the initscripts from Knoppix be compatible? Could I just copy them over?

I'm GETTING somewhere!

I read the udev init script. I discovered that there is a /dev/.static/dev that is the "real" /dev, and that what I see as /dev is just a tmpfs over top of the "real" /dev.... so.....


"ls -l /dev/.static/hda*" shows all possible hda partitions... even those I don't have. I can even mount them. Successfully.

It's a workaround, I know, but I'm going to edit my fstab real quick like (after backup of course) to see if that'll work at least well enough to let me make apt-get changes.....

That's one good thing about issues like this: I always come out of it learning something.

Yep! Success! Well, at least I'm booting now... It's not really a success until I have it all working the way it's designed to, but I'll keep an eye on udev and whatsuch and try again later....

But I'm still wide open to suggestions here.


Thanks!

According to synaptic, udev is not installed! It should be, shouldn't it?


Ahh, it was removed when hotplug was installed! Okay, so... which is better? Which do I want? I think I installed hotplug when trying to get my joystick to work.....

SOLVED!


Recompiled the kernel. I don't think I messed with anything /dev related, although I did look carefully in that area. Maybe I did misconfig something, but I don't know what I changed. I was mainly recompiling for the purpose of getting a USB joystick to work -- about which I'll post in another thread.

Oh well. Now that it's happened, I can work around it in the future.