You are not logged in.
Pages: 1
I dual boot Arch Linux on my laptop. The partitions are set up as follows:
/dev/hda is the internal hard disk drive
/dev/hda MBR contains NTLDR
/dev/hda1 - NTFS - Windows
/dev/hdb is a 500GB USB drive
/dev/hdb MBR contains GRUB
/dev/hdb1 - ext2/3 - /boot/
/dev/hdb2 - JFS - /
/dev/hdb3 - NTFS (just so that Windows doesn't prompt me to format the drive)
This configuration has worked for over a year. The USB drive has made loud clacking noises in the past, often followed by pauses and stutters in video playback and general desktop responsiveness, but I have never had any real stability problems. Regardless of whatever horrible noises it made, it continued running -- no data loss, no kernel panics, etc.. This afternoon, I went to update Pacman and the Nvidia drivers (testing out OpenCL), but it stopped midway (the system wasn't really affected, I was playing QuakeLive when it happened and didn't notice a thing). However, when I went to delete (#rm -f) the Pacman database lock file in /var/ in order to resume the update, it said that the filesystem was read-only and I could not remove it. I rebooted, and as it was shutting down, I noticed that all the init scripts were failing to stop. When it started up again I selected Arch from the GRUB menu and the kernel loaded, but it said that it could not create /dev/disk/by-uuid/<uuid goes here>, my root disk, and dumped me in a klibc prompt. I also tried editing my menu.lst to point to /dev/hdb2, but it didn't make a difference.
Diagnosing the issue is made more difficult because I don't have any Linux disks, secondary machines, or blank CD-Rs at the moment.
I don't think that the drive itself is dead (not the entire thing, anyway), as GRUB still loads (indicating that the MBR and /boot/ are fine) and I can still access the NTFS partition from Windows.
Could this be a problem with my filesystem, or a result of this failed update (I'm not sure what kind of dependencies the Nvidia driver pulled in, kernel update, maybe)?
Thanks in advance for any help.
Last edited by robodonut (2009-11-16 21:14:59)
Offline
I installed Ubuntu via Wubi. The JFS partition wouldn't mount until I ran fsck, but now it mounts fine. No corruption is immediately obvious to me. However, it still does not boot.
I wanted to chroot in to see what broke, but I stupidly installed the i686 version of Ubuntu and my Arch install is x86_64. I'm installing the x86_64 version now.
Edit:
UNR doesn't seem to have a 64-bit version, and Wubi doesn't prompt the user to select architecture. It seems to choose one arbitrarily. It's unbelieveably irritating, and not the first time Ubuntu's "we know better than the user, who is clearly an oaf" policy has broken something (Ubuntu's installer skips the part where you tell it where to install GRUB. Add in fake RAID, and you can imagine the mess it caused).
I think I've got Wubi figured out now, though.
Last edited by robodonut (2009-11-17 18:24:48)
Offline
Installed Ubuntu 64-bit, mounted and chrooted into my Arch partition. I reinstalled the kernel and grub, then I ran grub-install /dev/sdb. It generated a device.map (shouldn't that have already been there?), which looked correct ((hd0) is /dev/sda, (hd1) is /dev/sdb, etc).
I rebooted, and it's still broken.
I've run out of ideas.
Offline
I converted the entire partition to ext3 by formatting the NTFS partition as ext3, deleting everything that wouldn't fit in this smaller partition, copying it all with rsync -vaHcx, formatting the JFS partition as ext3, and copying it all back.
It didn't change anything.
One thing I did notice, however, was that when I entered "echo /dev/*" after being dumped in the recovery prompt, no drives were listed. Not even the internal HDD (/dev/sda). I think this is how it was before I messed with the partitions, but I didn't really think much of it at the time.
If there's any relevant information I can post, tell me.
Last edited by robodonut (2009-11-19 05:40:53)
Offline
Pages: 1