suddenly no /dev/hda3 after update?

[alastairII]

I did part of an emerge -uD world yesterday after a month, which stopped because it emerged a new kernel and I hadn't configured the new version yet. But I didn't care, because I had a bigger problem, which was that after I connected everything back up (after being in storage) sound didn't work. So I thought I might reboot, because that occasionally fixes things by restarting all the various services I don't know about. However, when I rebooted, there seemed to be no such file or directory /dev/hda3, my / partition. So it said:

Code: Select all

* Checking root filesystem...
fsk.ext3: No such file or directory while trying to open /dev/hda3
/dev/hda3:
The superblock could not be read or does not describe a correct ext2 filesystem. 
[some boilerplate stuff, then dumps me to a root login.]

For some reason, the / partition is already mounted read-only, so I can look around, but I can't do things like etc-update (which I forgot to do after the partial emerge -uD world). Furthermore,

Code: Select all

(none) ~ # ls /dev
cdroms    floppy    innitctl    mem    printers    random    shm   urandom    zero
console    full    input    misc    ptmx    raw1394    sound    usb
discs    ide    kmem    null    pts    root    tts    vc
fb    ieee1394    kmsg    port    pty    scsi    tty    vcc

So there appears to be no /dev/hda3. Any ideas as to how to get it back?

[unclecharlie]

alistair,

I'm assuming that /dev/hda3 is your fs root. If so, any problems with /dev/hda3 will need to be fixed without it mounted. To do so, boot to the gentoo live cd or a rescue cd, i.e.- http://sysresccd.org, then run your filesystem check with nothing mounted.

Charlie

[alastairII]

Booted into knoppix, and:

Code: Select all

root@0[knoppix]# e2fsck /dev/hda3
e2fsck 1.38-WIP (09-May-2005)
/dev/hda3: clean, 1207379/14532608 files, 23109426/29043511 blocks

That appears not to be the problem. I am not entirely sure what to check next; is there some way to look into the configuration of whatever puts stuff in /dev?

[lump]

I'm seeing a similar problem.

I ran my updates this morning, and after an attempt at reboot I see a similar error:

fsck.ext2: No such file or directory while trying to open /dev/hda2

/etc/fstab is fine, it was not changed with the update and still shows /dev/hda2 on /boot, etc.

But, are no hd* under /dev.

The odd thing is that it gets partly booted, and mount shows /dev/hda4 on /, even though there is no /dev/hda.

[BlackEdder]

What does emerge info show?

[alastairII]

This is from chrooted knoppix, so probably some of it is a bit wrong (e.g. the kernel version), but here:

Code: Select all

Portage 2.0.51.22-r3 (default-linux/x86/2005.0, gcc-3.3.6, glibc-2.3.5-r2, 2.6.11 i686)
=================================================================
System uname: 2.6.11 i686
Gentoo Base System version 1.6.14
dev-lang/python:     2.3.5-r2, 2.4.2
sys-apps/sandbox:    1.2.12
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O3 -march=pentium4 -pipe -fomit-frame-pointer -ffast-math -mfpmath=sse,387 -msse2 -mmmx"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O3 -march=pentium4 -pipe -fomit-frame-pointer -ffast-math -mfpmath=sse,387 -msse2 -mmmx"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://gentoo.cites.uiuc.edu/pub/gentoo/  ftp://gentoo.cites.uiuc.edu/pub/gentoo/ ftp://gentoo.ccccom.com  http://gentoo.osuosl.org"
LANG="C"
LC_ALL="C"
LDFLAGS="-Wl,-O1"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 X aac acl aim alsa apm arts audiofile avi bidi bitmap-fonts bonobo bzip2 cdda cdio cdparanoia cdr cpdflib crypt cups curl dvd dvdr dvdread eds emacs emboss encode esd exif expat fam ffmpeg flac flash foomaticdb fortran ftp gdbm gif glut gmp gnome gnutls gpm gstreamer gtk gtk2 gtkhtml guile hal howl httpd idn ieee1394 imagemagick imlib ipv6 jabber java javascript jpeg junit kde kdeenablefinal kdexdeltas lcms leim libg++ libwww live mad mikmod ming mmx mng motif mozilla mp3 mpeg ncurses nls nsplugin nvidia offensive ogg oggvorbis openal opengl pam pcre pdflib perl plotutils png python qt quicktime readline ruby scanner sdl slang spell sse ssl stream svg svga symlink tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts udev unicode usb vcd vlm vorbis win32codecs xine xml xml2 xmms xv xvid zlib userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LINGUAS, PORTDIR_OVERLAY

[landi]

Hi!

Seems that we have a problem in portage, i updated my gentoo a few hours ago and after rebooting it hangs with the error:
failed to open the device '/dev/hdc3': No such file or directory

the funny thing is that the HD is already mounted, so i can look into the /dev directory and there is nearly everything missing (no hd.., sd.. ).
When i boot with knoppix the whole things are there again.

[landi]

Hi again!

Since i can't sleep with the knowledge of having a not working gentoo i searched for the reason of the problem and think i found it. I first started with the Gentoo Live CD and chrooted my gentoo-version (like in the installation tutorial). Afterwards i searched in the emerge.log file for all sys-... packages, that were updated at the last update. After a few ineffective trys of downgrading packages i downgraded the packages:

sys-apps/baselayout
and
sys-process/psmisc

I think psmisc shouldn't be involved in this problem, so it should be enough to downgrade sys-apps/baselayout (in my case from version 1.11.14 to 1.11.13-r1).

And don't forget to run etc-update.

greetings,
Landi

[alastairII]

Thanks! That worked. This is probably a stupid question, but how do I tell Portage not to upgrade that again?

[glober]

Just for the record I would like to say that I also had a problem where the root drive failed a fsck check after doing emerge -uD world and the problem as has been mentioned was baselayout being upgraded. Version 1.11.14 is problematic, so downgrading to 1.11.13-r1 fixed the problem.

BTW, I have gentoo set for stable, so I am suprised that this happened. My question at at this point is, how do I know the problem is fixed without hosing my system again, do I wait for the version after 1.11.14 to become stable, or is 1.11.14 going to be fixed?

[landi]

To avoid updating baselayout again to version 1.11.14 you can create an entry into your package.mask file (which lies in /etc/portage, if not you can create one).
A simple line with
=sys-apps/baselayout-1.11.14
should be enough for ignoring it at the next update.

[hanj]

Hello All

Is this fixed with latest udev update (sys-fs/udev-079)?

Notes from changelog..

*udev-079

23 Dec 2005; Greg Kroah-Hartman <gregkh@gentoo.org>
+files/05-udev-early.rules-079, +udev-079.ebuild:
079 release, fixes some /dev/disk names and naming of network devices bugs.

hanji

[kellwood]

Hi All,

In my case, it is no /dev/sd*. How do I downgrade baselayout when I can't boot properly?

Thanks
Kevin

[glober]

How do I downgrade baselayout when I can't boot properly?

In my case I booted from a Gentoo LiveCD , chroot'ed into my root drive (similar steps as doing an install) , and downgraded baselayout. The root drive file system wasn't actually corrupt, it's just something in baselayout that's reporting it that way.

[kellwood]

Thanks,

I should have thought of that.

Kevin

[glober]

Just a warning to everybody, baselayout version 1.11.14-r1 is also problematic. Upon doing emerge -uD world, this version comes up as the new stable version, doesn't look so stable to me. This is getting tedious. Can somebody look into this please.

[devsk]

I am hitting this problem too. Can someone please post what the status of this thing is? what works?

EDIT: ok, downgrading the baselayout works.

[ianw]

Same problem here with /dev/sda1. I'm also getting a system.map not found warning beforehand - is this likely to be related in some way?

Edit: Yep again downgrading baselayout to 1.11.13-r1 worked wonders. I presume the only way to do this is as I did through the files in /usr/portage? Apologies for the stupid question but I'm still fairly new to this all... and somehow things don't generally go wrong!

[gfaccin]

Hello there, I had the same problem here. In the end I managed to fix it by changing fstab instead of downgrading the ebuild. My thread is here; perhaps it might be useful to you:

http://forums.gentoo.org/viewtopic-t-42 ... art-0.html

[alastairII]

I guess my question is that is baselayout-1.11.14-r2 fixed, or am I going to have to change my fstab like gfaccin did? Perhaps one of the gentoo devs knows if it's going to be fixed?

[gfaccin]

alastairli:

Right now I'm running emerge sync && emerge world here, to test the new ebuild. I'll be using my original pre-crash fstab in the test. I'll be posting results soon.

[gfaccin]

Ok... I'm now running the latest version of baselayout (1.11.14-r2). I tried my original fstab and the error is still happening. The good news is that the fstab fix is still working with this version, so, until an ebuild fix arrives, I'll be using the modified fstab.

[mwojc]

Hi guys!
I think, you should recompile your kernel with the options:

Code: Select all

File systems --->
  Pseudo Filesystems --->
    [*] /dev file system support (OBSOLETE)
      [ ]   Automatically mount at boot

where 'Automatically mount at boot' HAVE TO BE DISABLED. See http://www.gentoo.org/doc/en/udev-guide.xml

This change in my kernel configuration helped, and the usual names of the devices are still in my /etc/fstab...

[alastairII]

Uh... in 2.6.14-r5, there doesn't appear to be any mention of /dev file system support in Pseudo Filesystems...

[chance2105]

I was bitten by this baselayout issue. Unfortunately for me, I couldn't just boot from the LiveCD and chroot into my install - the linux-headers version was greater than the kernel on my LiveCD version, so chroot wouldn't run ("kernel too old"), and on my arch (sparc64) there isn't a LiveCD that has a recent enough kernel for chroot to work.

Not only could I not chroot, but my filesystem is spread out over several partitions -- simply using the LiveCD to mark FSTAB to not check the root partition on boot wasn't going to work to boot the system and downgrade baselayout.

I was beginning to think I was going to have to reinstall, but here's how I fixed it in the end (culling from these posts, you guys are great for ideas):

PREFACE: USE AT YOUR OWN RISK .. although I think it's all relatively harmless ... read to the end of this post before trying my method.

Step 1 - Modify /etc/fstab
Boot the LiveCD and mount the system's root filesystem. Modify FSTAB to read 0 on the "pass" parameter of the root filesystem. Reboot, and let machine boot into your install.

Step 2: Login for "maintenance" during boot
The init scripts are going to bail out when the remainder of the partitions can't be mounted, so enter the root password.

Step 3: Manually create /dev/ nodes for your partitions.
In my case, MAKEDEV wouldn't / couldn't create /dev/sda* nodes for my SCSI disk. (And thank [deity] these commands were available.) So I resorted to using mknod.

This link got me started: http://www.faqs.org/docs/linux_admin/x797.html

Following that link, I downloaded the kernel sources onto another computer (my /usr/ is on a seperate partition on my broken gentoo install.. lucky me) and sourced linux/Documentation/devices.txt for the device major / minor numbers for the SCSI disk (in my case, the major number was 8, the minor was the number of my partition, eg sda1 = 1, sda4 = 4).

So the command finally ended up:

Code: Select all

mknod /dev/sda1 b 8 1

I repeated it until the /dev/ node for each partition was created.

Step 4: Mount paritions as per /etc/fstab
Yeah, baby, we have a working root environment now ..

Step 5: Downgrade baselayout
I emerged baselayout 1.11.13-r1, since this was the last version installed:

Code: Select all

emerge --oneshot =sys-apps/baselayout-1.11.13-r1

Step 6: Run dispatch-conf
I studiously replaced all the /etc/init.d/ scripts, and any config files I hadn't modified / knew were harmless.

Step 7: Unmount filesystems
I wasn't sure if the partitions would be properly unmounted / synced when I rebooted, so I ran "sync", and then unmounted everything except for my root partition.

Step 8: exit
Type "exit".

To my surprise, it went ahead and continued booting -- went through the remaining init-scripts. X didn't come up, I imagine due to missing /dev/ nodes. At this point, I changed my fstab back to its original settings, and rebooted.

Viola.

I'm not sure about a lot of it. By issuing mknod, not sure if it somehow burned those nodes permanently into /dev/. Also, I'm not sure exactly how safe mouting the root filesystem without running fsck is.

At any rate, it's fixed.

And I hope this baselayout issue get fixed soon. I didn't see a bug for it at bugs.gentoo.org .. do we need to file one?

chance