Hi all...
I have just remembered that udev mounts /dev as a tmpfs filesystem, _on top_
of the old /dev directory. I have just booted to single user mode,
and checked that the old /dev is wasting around 13000 files (inodes) in my
box. Space is not an issue, that is around 480 Kb.
A couple questions:
- Is it possible to boot with an empty /dev, until udev builds it ?
- If this is not the case, which are the minimal nodes that should be
present ?
- For any answer to previous question, shouldn't the distro set up minimal
/dev (empty or with a few nodes) and _delete_ the old /dev tree ?
I don't remember exactly, but there are scripts at initscripts run before
udev. As I understand it, udev should be the very first thing to run, as
anything after it will probably need a /dev/something....
Why my simple logic does not work ?
(As I CC both cooker and LKML, this is a cooker specific question: could anybody
who has installed 10.1 from scratch, ie not an update, boot to runlevel 1 and
list his /dev)
TIA
--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandrakelinux release 10.1 (Community) for i586
Linux 2.6.9-rc3-mm3 (gcc 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk)) #2
A couple questions:
- Is it possible to boot with an empty /dev, until udev builds it ?
No, it isn't as far as I know.
- If this is not the case, which are the minimal nodes that should be
present ?
/dev/null and /dev/console is needed to boot into the envoirment
- For any answer to previous question, shouldn't the distro set up minimal
/dev (empty or with a few nodes) and _delete_ the old /dev tree ?
At least I could do so, but at the moment /dev are also elemental for some distros..I have moved with gentoo and have had no problems along x86 32bit
but x86_64 driving me creazy
I you want more to know have a look at decibiles udev primer
Greets Michael
> - Is it possible to boot with an empty /dev, until udev builds it ?
> - If this is not the case, which are the minimal nodes that should be
> present ?
Having just done this experiment myself: With kernel 2.6.8, udev 034,
Debian unstable's init scripts, and no initramfs or initrd, it
suffices to have /dev/console and /dev/null in the root filesystem's
/dev.
The very first thing init does is open /dev/console, and if it doesn't
exist the entire boot hangs. Thus, the only way to avoid having that
node on the root filesystem would be to set up udev from initrd or
initramfs. I'm sure that's possible but I don't know how to do it;
and the boot scripts that exist right now in Debian unstable are not
set up to handle that case.
It may not be necessary to have /dev/null on the root filesystem; I
didn't try that. Libc and the shell frequently open /dev/null behind
one's back, so I suspect it is wanted before udev starts up.
I have no idea what distros are planning in this area.
zw
>The very first thing init does is open /dev/console, and if it doesn't
>exist the entire boot hangs.
This raises a question: Would it be a useful thing to make a modified init
that could run udev before it does anything else?
--
Melior amare chemia
http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD
On 2004.10.11, Hacksaw wrote:
> >The very first thing init does is open /dev/console, and if it doesn't
> >exist the entire boot hangs.
>
> This raises a question: Would it be a useful thing to make a modified init
> that could run udev before it does anything else?
I don't think it is needed. There is no problem (i am thinking on rootles
nodes and PXE and so on...) on building a simple initrd with /dev/console,
/dev/null and half a dozen standard devices if they are needed. Just
to get udev run and have your real devices mounted there and overwrite
them.
I just remember one other oddity. To clean up my system, I copied the
running /dev to /dev-new, moved /dev to /dev-old and /dev-new to /dev.
But on 'reboot', I got a complaint about /dev/initctl not opening.
This could happen also with init. It opens real /dev/initctl on boot,
mounts /dev and tries to use new /dev/inittclt on shutdown...
--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandrakelinux release 10.1 (Community) for i586
Linux 2.6.9-rc3-mm3 (gcc 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk)) #2
>I don't think it is needed. There is no problem (i am thinking on rootles
>nodes and PXE and so on...) on building a simple initrd with /dev/console,
>/dev/null
I'm looking for no initrd. I'm not a fan of them. It seems like having to use
an electric drill to start your car.
I like the idea that someone could accidentally scribble all over /dev, and on
reboot the system would just rebuild it. It makes /dev less of a vulnerability.
--
Sleepy, Dopey, Sneezy, Bashful, Grumpy, Happy, Doc
Just in case you'd forgotten...
http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD
Hacksaw writes:
>Zack Weinberg writes:
>>The very first thing init does is open /dev/console, and if it doesn't
>>exist the entire boot hangs.
>
>This raises a question: Would it be a useful thing to make a modified init
>that could run udev before it does anything else?
It wouldn't help. The opening of /dev/console actually happens inside
the kernel, near the bottom of init/main.c:
if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
printk("Warning: unable to open an initial console.\n");
(void) sys_dup(0);
(void) sys_dup(0);
That's not a fatal error, but the userspace startup process does get
stuck not very long afterward. (I'm not sure precisely where. It
hadn't mounted filesystems read-write yet.)
Control reaches the above code after an initramfs is unpacked, so
including /dev/console in an initramfs will work. I do not think it
will work to invoke udevstart from an initramfs or initrd *without*
also including a static /dev/console -- I'm pretty darn sure that
control reaches /init in an initramfs after the above code executes.
I'm not sure whether control reaches /linuxrc in an initrd before or
after the above code.
Being inside the kernel at this point, it seems to me there ought to
be some way to open device <5,1> without going through the filesystem,
but I could not find one.
[Tangentially, I thought kernel-side syscalls had been stamped out,
but there's still a __KERNEL_SYSCALLS__ #define at the top of the file
and a bare execve() in run_init_process()... which does in fact get
compiled to int $0x80 on my boring old x86...]
zw
On Oct 11, 2004, at 01:15, Hacksaw wrote:
>> The very first thing init does is open /dev/console, and if it doesn't
>> exist the entire boot hangs.
>
> This raises a question: Would it be a useful thing to make a modified
> init
> that could run udev before it does anything else?
FC3t2 boots from an "initrd" image that, among other things, mounts a
tmpfs over "/dev" and creates "console", "null", "pts" and then
proceeds to load "init".
On Monday 11 of October 2004 11:14, Felipe Alfaro Solana wrote:
> On Oct 11, 2004, at 01:15, Hacksaw wrote:
> >> The very first thing init does is open /dev/console, and if it doesn't
> >> exist the entire boot hangs.
> >
> > This raises a question: Would it be a useful thing to make a modified
> > init
> > that could run udev before it does anything else?
>
> FC3t2 boots from an "initrd" image that, among other things, mounts a
> tmpfs over "/dev" and creates "console", "null", "pts" and then
> proceeds to load "init".
... and it ignores root= kernel cmdline option. rootfs is hardcoded in initrd
which is very ugly.
Creating /dev entries on rootfs from initrd without hardcoding rootfs device
is quite problematic.
--
Arkadiusz Mi?kiewicz PLD/Linux Team
http://www.t17.ds.pwr.wroc.pl/~misiek/ http://ftp.pld-linux.org/
>FC3t2 boots from an "initrd" image that, among other things, mounts a
>tmpfs over "/dev" and creates "console", "null", "pts" and then
>proceeds to load "init".
Is that considered good? I like RedHat, but they are well known for doing
things of dubious taste.
But I just dislike the whole "stopped dead because of the state of the disk"
thing. I mean, sure, if there large amounts of stuff just missing, it might be
hard to get anything done, but it sure would be nice if the kernel would try
really hard to get to a shell so I can figure out what the problem is.
If the initrd gets corrupted, are we just hosed?
--
Is qui iacit in hamas marsupiales.
http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD
On Oct 11, 2004, at 12:29, Arkadiusz Miskiewicz wrote:
> On Monday 11 of October 2004 11:14, Felipe Alfaro Solana wrote:
>> On Oct 11, 2004, at 01:15, Hacksaw wrote:
>>>> The very first thing init does is open /dev/console, and if it
>>>> doesn't
>>>> exist the entire boot hangs.
>>>
>>> This raises a question: Would it be a useful thing to make a modified
>>> init
>>> that could run udev before it does anything else?
>>
>> FC3t2 boots from an "initrd" image that, among other things, mounts a
>> tmpfs over "/dev" and creates "console", "null", "pts" and then
>> proceeds to load "init".
> ... and it ignores root= kernel cmdline option. rootfs is hardcoded in
> initrd
> which is very ugly.
I haven't seen any hardcoded root filesystem reference in the INITRD
image. Instead, I see "/dev/root" which is supposed to be exactly the
root filesystem passed to the kernel via "root=".
On Oct 11, 2004, at 13:11, Hacksaw wrote:
>> FC3t2 boots from an "initrd" image that, among other things, mounts a
>> tmpfs over "/dev" and creates "console", "null", "pts" and then
>> proceeds to load "init".
>
> Is that considered good? I like RedHat, but they are well known for
> doing
> things of dubious taste.
>
> But I just dislike the whole "stopped dead because of the state of the
> disk"
> thing. I mean, sure, if there large amounts of stuff just missing, it
> might be
> hard to get anything done, but it sure would be nice if the kernel
> would try
> really hard to get to a shell so I can figure out what the problem is.
>
> If the initrd gets corrupted, are we just hosed?
In some way, the answer is yes... I think the best is having a real,
on-disk, full "/dev" hierarchy in case the INITRD gets lost or
corrupted, which will still allow booting. Now, the INITRD can mount
tmpfs over "/dev" and use udev to create needed device nodes.
On Monday 11 October 2004 02:25, J.A. Magallon wrote:
>
> On 2004.10.11, Hacksaw wrote:
> > >The very first thing init does is open /dev/console, and if it doesn't
> > >exist the entire boot hangs.
> >
> > This raises a question: Would it be a useful thing to make a modified init
> > that could run udev before it does anything else?
>
> I don't think it is needed. There is no problem (i am thinking on rootles
> nodes and PXE and so on...) on building a simple initrd with /dev/console,
> /dev/null and half a dozen standard devices if they are needed. Just
> to get udev run and have your real devices mounted there and overwrite
> them.
>
> I just remember one other oddity. To clean up my system, I copied the
> running /dev to /dev-new, moved /dev to /dev-old and /dev-new to /dev.
> But on 'reboot', I got a complaint about /dev/initctl not opening.
> This could happen also with init. It opens real /dev/initctl on boot,
> mounts /dev and tries to use new /dev/inittclt on shutdown...
What /dev/initctl? Why do you have a pipe in a directory
which supposed to have device nodes only?
Get better init.
--
vda
>> If the initrd gets corrupted, are we just hosed?
>
>In some way, the answer is yes... I think the best is having a real,
>on-disk, full "/dev" hierarchy in case the INITRD gets lost or
>corrupted, which will still allow booting. Now, the INITRD can mount
>tmpfs over "/dev" and use udev to create needed device nodes.
And see, this is where I say, what if /dev is hosed too? If the kernel at this
point gives up, then the user has to dig up a boot CD or something worse and
start trying to fix the system.
If, however, the kernel just made /dev/console and maybe /dev/null, it could
start a shell and say "/dev missing /console device, initrd corrupted. Hit
enter for a shell or ctrl-alt-del to reboot."
As a sys-admin, I'd like that. Get me into single user mode the best you can.
If a shell can be found, that's good enough.
--
The best is the enemy of the good -- Voltaire
The Good Enough is the enemy of the Great -- Me
http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD
On Mon, 11 Oct 2004 16:06:02 -0400, Hacksaw <[email protected]> wrote:
> >> If the initrd gets corrupted, are we just hosed?
> >
> >In some way, the answer is yes... I think the best is having a real,
> >on-disk, full "/dev" hierarchy in case the INITRD gets lost or
> >corrupted, which will still allow booting. Now, the INITRD can mount
> >tmpfs over "/dev" and use udev to create needed device nodes.
>
> And see, this is where I say, what if /dev is hosed too? If the kernel at this
> point gives up, then the user has to dig up a boot CD or something worse and
> start trying to fix the system.
What if kernel image is hosed instead?
Having corrupted initrd is not so diffirent from having corrupted kernel
image and usually they are both located on the same medium...
> If, however, the kernel just made /dev/console and maybe /dev/null, it could
> start a shell and say "/dev missing /console device, initrd corrupted. Hit
> enter for a shell or ctrl-alt-del to reboot."
>
> As a sys-admin, I'd like that. Get me into single user mode the best you can.
> If a shell can be found, that's good enough.
> --
> The best is the enemy of the good -- Voltaire
> The Good Enough is the enemy of the Great -- Me
>
>
> http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD
>What if kernel image is hosed instead?
Well, there's only so far we can go. If the alternator on a car is bad, we can
run on the battery for a little bit to get to the auto parts store. If the
engine is cracked, we're going to need an engine hoist and a good mechanic. :-)
>Having corrupted initrd is not so diffirent from having corrupted kernel
>image and usually they are both located on the same medium...
The hosing I am imagining is one done by the fat fingers of the sys-admin, not
so much because of disk corruption.
--
http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD
On Sun, Oct 10, 2004 at 10:08:49PM +0000, J.A. Magallon wrote:
> Hi all...
>
> I have just remembered that udev mounts /dev as a tmpfs filesystem, _on top_
> of the old /dev directory.
Well, that's the way _your_ distro does it. Mine has an empty /dev on
the root filesystem, and the init scripts create a ramfs on top of /dev
at boot time, which udev fills up.
thanks,
greg k-h
Greg KH wrote:
> On Sun, Oct 10, 2004 at 10:08:49PM +0000, J.A. Magallon wrote:
>
>>Hi all...
>>
>>I have just remembered that udev mounts /dev as a tmpfs filesystem, _on top_
>>of the old /dev directory.
>
>
> Well, that's the way _your_ distro does it. Mine has an empty /dev on
> the root filesystem, and the init scripts create a ramfs on top of /dev
> at boot time, which udev fills up.
>
I don't like this "my distro is better than yours".
Any pointer to some code online?
Thanx very much
Harri
On Tue, Oct 12, 2004 at 10:11:48AM +0200, Harald Dunkel wrote:
> Greg KH wrote:
> >On Sun, Oct 10, 2004 at 10:08:49PM +0000, J.A. Magallon wrote:
> >
> >>Hi all...
> >>
> >>I have just remembered that udev mounts /dev as a tmpfs filesystem, _on
> >>top_
> >>of the old /dev directory.
> >
> >
> >Well, that's the way _your_ distro does it. Mine has an empty /dev on
> >the root filesystem, and the init scripts create a ramfs on top of /dev
> >at boot time, which udev fills up.
>
> I don't like this "my distro is better than yours".
I'm not trying to imply this at all. All I'm saying is this is a distro
specific issue, not a kernel issue, so it isn't a linux-kernel topic.
> Any pointer to some code online?
Look at the gentoo init package, or read the documentation in the udev
tarball for how to do this for Red Hat. I've successfully done this on
both distros.
thanks,
greg k-h
Greg KH wrote:
> On Tue, Oct 12, 2004 at 10:16:54PM +0200, Harald Dunkel wrote:
>
>>Greg KH wrote:
>>
>>>Yeah, the documentation is out there, somewhere...
>>>
>>
>>What I really do not like for initramfs is that the
>>cpio file is compiled into the kernel. Extremely
>>unflexible. Why should I use modules then?
>>
>>Is it possible to load the initramfs like an initrd
>>on the grub command line?
>
>
> Why post this in private?
>
> Care to ask this on the linux-kernel mailing list and CC me? That way I
> can answer it in public to enable everyone else to know the answer, and
> let the search engines pick it up.
>
> thanks,
>
> greg k-h
>
Sorry, somewhere in this thread I had clicked the wrong
reply button.
Talking about initramfs: I am still trying to become
familiar with this stuff. I have found a lot of small
pieces of information (still reading), and the cpio
stuff in the kernel usr directory. But I have 2 questions:
Why is the initramfs built at the beginning of the
kernel build procedure? Wouldn't it be more reasonable
to build it when all kernel modules are available?
And why is it compiled into the kernel at all? The
README in Documentation/early-userspace says
<quote>
"Early userspace" is a set of libraries and programs that provide
various pieces of functionality that are important enough to be
available while a Linux kernel is coming up, but that don't need to be
run inside the kernel itself.
</quote>
So why compile it into the kernel? IMHO it would be more
flexible to load the early-userspace stuff similar to initrd
via the grub command line. Compiling it into the kernel
could be optional.
Regards
Harri
"Harald Dunkel" <[email protected]> disait derni?rement que :
> Greg KH wrote:
>> On Tue, Oct 12, 2004 at 10:16:54PM +0200, Harald Dunkel wrote:
> Sorry, somewhere in this thread I had clicked the wrong
> reply button.
>
> Talking about initramfs: I am still trying to become
> familiar with this stuff. I have found a lot of small
> pieces of information (still reading), and the cpio
> stuff in the kernel usr directory. But I have 2 questions:
>
> Why is the initramfs built at the beginning of the
> kernel build procedure? Wouldn't it be more reasonable
> to build it when all kernel modules are available?
because for now, the initramfs built into the kernel is quasi-empty and
isn't used as-is.
>
> And why is it compiled into the kernel at all? The
> README in Documentation/early-userspace says
>
> <quote>
> "Early userspace" is a set of libraries and programs that provide
> various pieces of functionality that are important enough to be
> available while a Linux kernel is coming up, but that don't need to be
> run inside the kernel itself.
> </quote>
the last statement just says it does not run in _kernelspace_ but in
_userspace_.
it has to be in the kernel.
I use it to mount my dm-crypt'd / and no initrd is needed.
(well as I wasn't able to get a small cryptsetup binary, my kernels
are ~1850kB worth of size)
> So why compile it into the kernel? IMHO it would be more
> flexible to load the early-userspace stuff similar to initrd
> via the grub command line. Compiling it into the kernel
> could be optional.
huh, well initrd is / that is mounted over the so-called _rootfs_
initramfs is here to _be_ that rootfs. So no pivot_root needed and the run-it
program included in klibc tarballs takes care of wiping-out everything that
could waste memory into the initramfs before mounting the real /.
If it was to compiled out of the kernel, it would just be an initrd....
rootfs is _needed_ for mounting the real root, so is initramfs.
have a nice day,
Mathieu
--
"My pan plays down an unprecedented amount of our national debt."
George W. Bush
February 27, 2001
>From a speech concerning the proposed federal budget.
Mathieu Segaud wrote:
>
> huh, well initrd is / that is mounted over the so-called _rootfs_
> initramfs is here to _be_ that rootfs. So no pivot_root needed and the run-it
> program included in klibc tarballs takes care of wiping-out everything that
> could waste memory into the initramfs before mounting the real /.
> If it was to compiled out of the kernel, it would just be an initrd....
>
> rootfs is _needed_ for mounting the real root, so is initramfs.
>
So the kernel boots, activates the initramfs somehow to
become the first /, and then starts /sbin/init (e.g. kinit
from the klibc package).
And then?
The sources of kinit show that its job is parse the kernel
command line arguments, configure the NIC, mount the root
filesystem via NFS, etc. Other configurations might require
a different init to start hotplug and udev, or to handle the
LVM and crypto magic, for example. My point is that if there
is no one-for-all init process to handle _every_ possible
startup procedure, then it might be necessary to rebuild the
initramfs. This would be easier (and easier to test) if
initramfs is not compiled into the kernel, but a separate
image to be loaded at boot time "somehow".
Or did I miss something?
Regards
Harri
"Harald Dunkel" <[email protected]> disait derni?rement que :
>
> And then?
>
> The sources of kinit show that its job is parse the kernel
> command line arguments, configure the NIC, mount the root
> filesystem via NFS, etc. Other configurations might require
> a different init to start hotplug and udev, or to handle the
> LVM and crypto magic, for example. My point is that if there
> is no one-for-all init process to handle _every_ possible
> startup procedure, then it might be necessary to rebuild the
> initramfs. This would be easier (and easier to test) if
> initramfs is not compiled into the kernel, but a separate
> image to be loaded at boot time "somehow".
>
yep to test it would be helpful. To setup mine, it took not long, but sure
such a facility could help. But you know, if you do not run make clean, and you
have edited usr/Makefile to not rebuild initramfs, puting your custom cpio
archive into usr and typing 'make' won't take long to rebuild the new kernel :)
I did that to get it working.
As to know if having an external archive file loaded by grub or so, I don't
know much that part of the kernel code... Hum, I really did not try to under-
stand the code involving initrd's and initramfs in init/do_mounts_initrd.c.
I wonder whether putting an executable /init in an initrd is sufficient to
have it recognized as an initramfs and not an initrd....
The important thing is /init executable script in initramfs, this is what
tells the kernel to override the "standard" way it boots.
Mathieu
--
The policy is not to have policy. It works as well in kernel design as politics.
- Alan Cox on linux-kernel