From: fbarton@fish.co.uk
To: linux-hotplug@vger.kernel.org
Subject: little udev problem - loop devices instead of hda devices!
Date: Thu, 12 Feb 2004 15:50:40 +0000 [thread overview]
Message-ID: <1076601040.402ba0d05eb01@webmail.fish.co.uk> (raw)
I'm not posting this from the affected machine, so apologies if any vital
information is missing.
I am running Fedora Core 1 and I recently compiled kernel 2.6.2 as an upgrade.
I was intrigued to see that devfs, which I had previously found useful, was
labelled OBSOLETE and so I decided to see what udev was all about.
Reading Greg's FAQ etc I can see that udev is going to be great. I installed
udev 0.16 last night and had a play with the config/rules/permissions files.
When eventually I felt ready to reboot I took a deep breath and did it.
Overall, it seemed to handle most of my devices just fine, and I got a really
slimline /udev directory with all my devices just sitting there and no crud.
Except... no hard drive. The computer didn't actually boot because it couldn't
find a console. Using my rescue disk I went in and mknodded a /dev/console
file. The next time it booted a bit further until it said "Error: canot
find /dev/hda1 - no such file or device" (I paraphrase).
I have seven partitions on my single hard drive: hda1 - hda7. None of these
were there in /dev or /udev. I hadn't changed anything to do with ide or hda in
the config files, AFAIK.
What I had instead was /udev/loop0 ... /udev/loop7 - very suspicious! For some
reason instead of loading hda devices it was loading loop devices - seven of
them (this is no coincidence I'm sure!). (The loop nodes were char-major 7 as
you would expect). And in /dev I had all the redundant hda files from hda8
upwards.
Can anyone help with these questions please:
What should I do to make sure my hda partitions are found at boot time? Why are
the loop devices being created instead? Is it safe yet to empty /dev and just
rely on /udev when things are properly configured (and presumably udev then
somehow symlinks from /dev or intercepts calls to /dev/* and uses /udev/*
instead)? Should I just go in and mknod my hda* devices again or would that not
be a good idea? Anyone have an idea what I might have set up wrong; or does
this look as if a piece of software is missing???
Sorry I can't post my /etc/udev/* files very easily, but I can get at them if
needed.
Many thanks,
Francis Barton
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next reply other threads:[~2004-02-12 15:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-12 15:50 fbarton [this message]
2004-02-12 21:03 ` little udev problem - loop devices instead of hda devices! John L. Fjellstad
2004-02-13 1:32 ` Greg KH
2004-02-15 3:28 ` Francis Barton
2004-02-21 17:43 ` Francis Barton
2004-02-21 17:51 ` Jon Smirl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1076601040.402ba0d05eb01@webmail.fish.co.uk \
--to=fbarton@fish.co.uk \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.