Discussion:
Modifying init to create /dev/console ?
Terry Barnaby
2007-02-27 09:22:25 UTC
Permalink
Hi,

I am trying to create a basic Linux system based on Busybox and would
like the ability to create the root file system as a normal user and
without any /dev entries. The startup script would create the /dev
entries as needed.
However, init and other programs obviously require /dev/console (and
other /dev entries).

I was wondering about adding an option to init where it would create a
tmpfs file system, mount it on /dev and create a /dev/console node if no
/dev/console was found. I guess it could do a bit more and function as
udev as well.

Do people with Busybox experience think that this a reasonable thing to
do ??

Cheers


Terry
Denis Vlasenko
2007-02-27 17:59:38 UTC
Permalink
Post by Terry Barnaby
I am trying to create a basic Linux system based on Busybox and would
like the ability to create the root file system as a normal user and
without any /dev entries. The startup script would create the /dev
entries as needed.
However, init and other programs obviously require /dev/console (and
other /dev entries).
I was wondering about adding an option to init where it would create a
tmpfs file system, mount it on /dev and create a /dev/console node if no
/dev/console was found. I guess it could do a bit more and function as
udev as well.
I think you are on the right track, but move in the wrong direction
along that track. Code shouldn't be added to init, it should be removed.

http://busybox.net/~vda/example_fs/README
--
vda
Terry Barnaby
2007-02-27 21:53:22 UTC
Permalink
Post by Denis Vlasenko
Post by Terry Barnaby
I am trying to create a basic Linux system based on Busybox and would
like the ability to create the root file system as a normal user and
without any /dev entries. The startup script would create the /dev
entries as needed.
However, init and other programs obviously require /dev/console (and
other /dev entries).
I was wondering about adding an option to init where it would create a
tmpfs file system, mount it on /dev and create a /dev/console node if no
/dev/console was found. I guess it could do a bit more and function as
udev as well.
I think you are on the right track, but move in the wrong direction
along that track. Code shouldn't be added to init, it should be removed.
http://busybox.net/~vda/example_fs/README
--
vda
Hi Denis,

But then you end up with init implemented in several shell scripts.
I guess it depends if you prefer 'C' or shell programs :)

Terry
Denis Vlasenko
2007-02-27 22:35:02 UTC
Permalink
Post by Terry Barnaby
Post by Denis Vlasenko
Post by Terry Barnaby
I am trying to create a basic Linux system based on Busybox and would
like the ability to create the root file system as a normal user and
without any /dev entries. The startup script would create the /dev
entries as needed.
However, init and other programs obviously require /dev/console (and
other /dev entries).
I was wondering about adding an option to init where it would create a
tmpfs file system, mount it on /dev and create a /dev/console node if no
/dev/console was found. I guess it could do a bit more and function as
udev as well.
I think you are on the right track, but move in the wrong direction
along that track. Code shouldn't be added to init, it should be removed.
http://busybox.net/~vda/example_fs/README
--
vda
Hi Denis,
But then you end up with init implemented in several shell scripts.
I guess it depends if you prefer 'C' or shell programs :)
Shell programs are easier to tailor for particular system without
messing up with compiler and toolchain - exactly what you need
for "I want to create /dev/console".
--
vda
Terry Barnaby
2007-02-28 09:46:22 UTC
Permalink
Post by Denis Vlasenko
Post by Terry Barnaby
Post by Denis Vlasenko
Post by Terry Barnaby
I am trying to create a basic Linux system based on Busybox and would
like the ability to create the root file system as a normal user and
without any /dev entries. The startup script would create the /dev
entries as needed.
However, init and other programs obviously require /dev/console (and
other /dev entries).
I was wondering about adding an option to init where it would create a
tmpfs file system, mount it on /dev and create a /dev/console node if no
/dev/console was found. I guess it could do a bit more and function as
udev as well.
I think you are on the right track, but move in the wrong direction
along that track. Code shouldn't be added to init, it should be removed.
http://busybox.net/~vda/example_fs/README
--
vda
Hi Denis,
But then you end up with init implemented in several shell scripts.
I guess it depends if you prefer 'C' or shell programs :)
Shell programs are easier to tailor for particular system without
messing up with compiler and toolchain - exactly what you need
for "I want to create /dev/console".
--
vda
Hi Denis,

I notice your http://busybox.net/~vda/example_fs has /dev/console and
/dev/null nodes. Have you managed to get a busybox system to boot and
run using shell scripts without these nodes ?

In my system the final rootfs will be a read-only NFS mount and I don't
want to have a /dev/console in the NFS mounted file system. So I need to
create this at boot time. My shell scripts do not appear to run from
init if I do not have a /dev/console though ...

Terry
Denis Vlasenko
2007-02-28 22:38:47 UTC
Permalink
Post by Terry Barnaby
Post by Denis Vlasenko
Post by Terry Barnaby
Post by Denis Vlasenko
Post by Terry Barnaby
I am trying to create a basic Linux system based on Busybox and would
like the ability to create the root file system as a normal user and
without any /dev entries. The startup script would create the /dev
entries as needed.
However, init and other programs obviously require /dev/console (and
other /dev entries).
I was wondering about adding an option to init where it would create a
tmpfs file system, mount it on /dev and create a /dev/console node if no
/dev/console was found. I guess it could do a bit more and function as
udev as well.
I think you are on the right track, but move in the wrong direction
along that track. Code shouldn't be added to init, it should be removed.
http://busybox.net/~vda/example_fs/README
--
vda
Hi Denis,
But then you end up with init implemented in several shell scripts.
I guess it depends if you prefer 'C' or shell programs :)
Shell programs are easier to tailor for particular system without
messing up with compiler and toolchain - exactly what you need
for "I want to create /dev/console".
--
vda
Hi Denis,
I notice your http://busybox.net/~vda/example_fs has /dev/console and
/dev/null nodes. Have you managed to get a busybox system to boot and
run using shell scripts without these nodes ?
Yes, see below
Post by Terry Barnaby
In my system the final rootfs will be a read-only NFS mount and I don't
want to have a /dev/console in the NFS mounted file system. So I need to
create this at boot time. My shell scripts do not appear to run from
init if I do not have a /dev/console though ...
This is the script which runs as /linuxrc (PID=1) in my initrd.
Notice that it mounts ramfs on /dev and creates console
and null there before chrooting into new ("real") root.
--
vda

#!/bin/sh

export PATH=/bin:/usr/bin

if ! test "$INIT"; then
INIT=/sbin/init
fi

cd /
# devfs allows me to use /dev/ide/.../.../.. root= param
#mount -n -t devfs none /dev
mount -n -t proc none /proc
#mount -n -t sysfs none /sys

echo "# Mounting root fs"
/script/mount_root

# Clean up
#umount /sys
umount /proc

echo "# Chrooting into root fs"
test -d /new_root/dev -a -d /new_root/proc || {
echo "Root fs (ls -l):"
cd /new_root; ls -l
echo "Root fs has no /dev and/or /proc!"
echo "Fatal, cannot continue booting"
while true; do sleep 32000; done
}
mount -n -t ramfs none /new_root/dev || {
echo "! mount -n -t ramfs none /new_root/dev failed, continuing in 10 sec"
sleep 10
}
cp -dp /dev/console /dev/null /new_root/dev
cd /new_root
# making sure we dont keep /dev busy
exec <dev/console >dev/console 2>&1
# proc/ in new root is used here as a temp mountpoint for old root
pivot_root . proc || {
echo "pivot_root failed. Fatal, cannot continue booting"
while true; do sleep 32000; done
}

exec \
chroot . \
sh -c '\
umount -n /proc || { echo "! error unmounting initrd fs, continuing"; sleep 10; }
exec /bin/env - $INIT
'

echo "chroot . sh failed. Fatal, cannot continue booting"
while true; do sleep 32000; done
Denis Vlasenko
2007-02-28 22:38:47 UTC
Permalink
Post by Terry Barnaby
Post by Denis Vlasenko
Post by Terry Barnaby
Post by Denis Vlasenko
Post by Terry Barnaby
I am trying to create a basic Linux system based on Busybox and would
like the ability to create the root file system as a normal user and
without any /dev entries. The startup script would create the /dev
entries as needed.
However, init and other programs obviously require /dev/console (and
other /dev entries).
I was wondering about adding an option to init where it would create a
tmpfs file system, mount it on /dev and create a /dev/console node if no
/dev/console was found. I guess it could do a bit more and function as
udev as well.
I think you are on the right track, but move in the wrong direction
along that track. Code shouldn't be added to init, it should be removed.
http://busybox.net/~vda/example_fs/README
--
vda
Hi Denis,
But then you end up with init implemented in several shell scripts.
I guess it depends if you prefer 'C' or shell programs :)
Shell programs are easier to tailor for particular system without
messing up with compiler and toolchain - exactly what you need
for "I want to create /dev/console".
--
vda
Hi Denis,
I notice your http://busybox.net/~vda/example_fs has /dev/console and
/dev/null nodes. Have you managed to get a busybox system to boot and
run using shell scripts without these nodes ?
Yes, see below
Post by Terry Barnaby
In my system the final rootfs will be a read-only NFS mount and I don't
want to have a /dev/console in the NFS mounted file system. So I need to
create this at boot time. My shell scripts do not appear to run from
init if I do not have a /dev/console though ...
This is the script which runs as /linuxrc (PID=1) in my initrd.
Notice that it mounts ramfs on /dev and creates console
and null there before chrooting into new ("real") root.
--
vda

#!/bin/sh

export PATH=/bin:/usr/bin

if ! test "$INIT"; then
INIT=/sbin/init
fi

cd /
# devfs allows me to use /dev/ide/.../.../.. root= param
#mount -n -t devfs none /dev
mount -n -t proc none /proc
#mount -n -t sysfs none /sys

echo "# Mounting root fs"
/script/mount_root

# Clean up
#umount /sys
umount /proc

echo "# Chrooting into root fs"
test -d /new_root/dev -a -d /new_root/proc || {
echo "Root fs (ls -l):"
cd /new_root; ls -l
echo "Root fs has no /dev and/or /proc!"
echo "Fatal, cannot continue booting"
while true; do sleep 32000; done
}
mount -n -t ramfs none /new_root/dev || {
echo "! mount -n -t ramfs none /new_root/dev failed, continuing in 10 sec"
sleep 10
}
cp -dp /dev/console /dev/null /new_root/dev
cd /new_root
# making sure we dont keep /dev busy
exec <dev/console >dev/console 2>&1
# proc/ in new root is used here as a temp mountpoint for old root
pivot_root . proc || {
echo "pivot_root failed. Fatal, cannot continue booting"
while true; do sleep 32000; done
}

exec \
chroot . \
sh -c '\
umount -n /proc || { echo "! error unmounting initrd fs, continuing"; sleep 10; }
exec /bin/env - $INIT
'

echo "chroot . sh failed. Fatal, cannot continue booting"
while true; do sleep 32000; done
Terry Barnaby
2007-02-28 09:46:22 UTC
Permalink
Post by Denis Vlasenko
Post by Terry Barnaby
Post by Denis Vlasenko
Post by Terry Barnaby
I am trying to create a basic Linux system based on Busybox and would
like the ability to create the root file system as a normal user and
without any /dev entries. The startup script would create the /dev
entries as needed.
However, init and other programs obviously require /dev/console (and
other /dev entries).
I was wondering about adding an option to init where it would create a
tmpfs file system, mount it on /dev and create a /dev/console node if no
/dev/console was found. I guess it could do a bit more and function as
udev as well.
I think you are on the right track, but move in the wrong direction
along that track. Code shouldn't be added to init, it should be removed.
http://busybox.net/~vda/example_fs/README
--
vda
Hi Denis,
But then you end up with init implemented in several shell scripts.
I guess it depends if you prefer 'C' or shell programs :)
Shell programs are easier to tailor for particular system without
messing up with compiler and toolchain - exactly what you need
for "I want to create /dev/console".
--
vda
Hi Denis,

I notice your http://busybox.net/~vda/example_fs has /dev/console and
/dev/null nodes. Have you managed to get a busybox system to boot and
run using shell scripts without these nodes ?

In my system the final rootfs will be a read-only NFS mount and I don't
want to have a /dev/console in the NFS mounted file system. So I need to
create this at boot time. My shell scripts do not appear to run from
init if I do not have a /dev/console though ...

Terry
Denis Vlasenko
2007-02-27 22:35:02 UTC
Permalink
Post by Terry Barnaby
Post by Denis Vlasenko
Post by Terry Barnaby
I am trying to create a basic Linux system based on Busybox and would
like the ability to create the root file system as a normal user and
without any /dev entries. The startup script would create the /dev
entries as needed.
However, init and other programs obviously require /dev/console (and
other /dev entries).
I was wondering about adding an option to init where it would create a
tmpfs file system, mount it on /dev and create a /dev/console node if no
/dev/console was found. I guess it could do a bit more and function as
udev as well.
I think you are on the right track, but move in the wrong direction
along that track. Code shouldn't be added to init, it should be removed.
http://busybox.net/~vda/example_fs/README
--
vda
Hi Denis,
But then you end up with init implemented in several shell scripts.
I guess it depends if you prefer 'C' or shell programs :)
Shell programs are easier to tailor for particular system without
messing up with compiler and toolchain - exactly what you need
for "I want to create /dev/console".
--
vda
Terry Barnaby
2007-02-27 21:53:22 UTC
Permalink
Post by Denis Vlasenko
Post by Terry Barnaby
I am trying to create a basic Linux system based on Busybox and would
like the ability to create the root file system as a normal user and
without any /dev entries. The startup script would create the /dev
entries as needed.
However, init and other programs obviously require /dev/console (and
other /dev entries).
I was wondering about adding an option to init where it would create a
tmpfs file system, mount it on /dev and create a /dev/console node if no
/dev/console was found. I guess it could do a bit more and function as
udev as well.
I think you are on the right track, but move in the wrong direction
along that track. Code shouldn't be added to init, it should be removed.
http://busybox.net/~vda/example_fs/README
--
vda
Hi Denis,

But then you end up with init implemented in several shell scripts.
I guess it depends if you prefer 'C' or shell programs :)

Terry
Mike Frysinger
2007-02-27 18:28:05 UTC
Permalink
Post by Terry Barnaby
However, init and other programs obviously require /dev/console (and
other /dev entries).
they dont require /dev/console
Post by Terry Barnaby
I was wondering about adding an option to init where it would create a
tmpfs file system, mount it on /dev and create a /dev/console node if no
/dev/console was found. I guess it could do a bit more and function as
udev as well.
it wouldnt work ... the kernel opens up /dev/console before executing init, so
even if /sbin/init created the device node, it wouldnt matter

also, this is what init scripts are for ... such / policy handling does not
belong hardcoded in the C code
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070227/d22d4891/attachment.pgp
Terry Barnaby
2007-02-27 21:45:49 UTC
Permalink
Post by Mike Frysinger
Post by Terry Barnaby
However, init and other programs obviously require /dev/console (and
other /dev entries).
they dont require /dev/console
Post by Terry Barnaby
I was wondering about adding an option to init where it would create a
tmpfs file system, mount it on /dev and create a /dev/console node if no
/dev/console was found. I guess it could do a bit more and function as
udev as well.
it wouldnt work ... the kernel opens up /dev/console before executing init, so
even if /sbin/init created the device node, it wouldnt matter
also, this is what init scripts are for ... such / policy handling does not
belong hardcoded in the C code
-mike
No, they don't require /dev/console just to operate, but if you want
debug printout they do :)

Init could easily reopen its controlling terminal to the created
/dev/console and continue ...

The reason I was looking at getting init to create /dev/console was so
that I could debug my init scripts that are not working when
/dev/console does not exist ...

Terry
David Daney
2007-02-28 17:33:54 UTC
Permalink
Post by Terry Barnaby
Post by Mike Frysinger
Post by Terry Barnaby
However, init and other programs obviously require /dev/console (and
other /dev entries).
they dont require /dev/console
Post by Terry Barnaby
I was wondering about adding an option to init where it would create a
tmpfs file system, mount it on /dev and create a /dev/console node if no
/dev/console was found. I guess it could do a bit more and function as
udev as well.
it wouldnt work ... the kernel opens up /dev/console before executing init, so
even if /sbin/init created the device node, it wouldnt matter
also, this is what init scripts are for ... such / policy handling does not
belong hardcoded in the C code
-mike
No, they don't require /dev/console just to operate, but if you want
debug printout they do :)
Init could easily reopen its controlling terminal to the created
/dev/console and continue ...
The reason I was looking at getting init to create /dev/console was so
that I could debug my init scripts that are not working when
/dev/console does not exist ...
Why do you think what Make says is false? All your posts on this
subject are premised on that false belief.

I think it is time that you change your assumption that you can boot a
system that does not contain /dev/console in its root file system. You
cannot do it with a standard Linux kernel.

As I see it you have two choices:

1) Put /dev/console in your root filesystem.
2) Hack up your kernel so that /dev/console is not needed.

David Daney
Terry Barnaby
2007-02-28 21:29:45 UTC
Permalink
Post by David Daney
Post by Terry Barnaby
Post by Mike Frysinger
Post by Terry Barnaby
However, init and other programs obviously require /dev/console (and
other /dev entries).
they dont require /dev/console
Post by Terry Barnaby
I was wondering about adding an option to init where it would create a
tmpfs file system, mount it on /dev and create a /dev/console node if no
/dev/console was found. I guess it could do a bit more and function as
udev as well.
it wouldnt work ... the kernel opens up /dev/console before executing
init, so even if /sbin/init created the device node, it wouldnt matter
also, this is what init scripts are for ... such / policy handling
does not belong hardcoded in the C code
-mike
No, they don't require /dev/console just to operate, but if you want
debug printout they do :)
Init could easily reopen its controlling terminal to the created
/dev/console and continue ...
The reason I was looking at getting init to create /dev/console was so
that I could debug my init scripts that are not working when
/dev/console does not exist ...
Why do you think what Make says is false? All your posts on this
subject are premised on that false belief.
I think it is time that you change your assumption that you can boot a
system that does not contain /dev/console in its root file system. You
cannot do it with a standard Linux kernel.
1) Put /dev/console in your root filesystem.
2) Hack up your kernel so that /dev/console is not needed.
David Daney
Hi,

Because, you can !
You can boot a system without /dev/console and get init to create the
basic /dev/console and continue. At least with the 2.6.19 kernel. My
patch to the Busybox init later in this thread does this and with an
un-modified kernel (in fact a standard Fedora 6 binary kernel).

I can now boot my system without any /dev nodes in sight. Init mounts a
tmpfs file system on /dev and creates the two necessary nodes
/dev/console and /dev/null and the rcS init script creates the rest.
However, being new to Busybox I'm not sure that this is the best
approach ...

Cheers

Terry
Mike Frysinger
2007-03-01 01:24:48 UTC
Permalink
Post by David Daney
I think it is time that you change your assumption that you can boot a
system that does not contain /dev/console in its root file system. You
cannot do it with a standard Linux kernel.
perhaps you need to change your assumption ? you can boot Linux without
a /dev/console just fine ... you dont get status output, but in an embedded
system, big whoop
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070228/5e091f32/attachment.pgp
David Daney
2007-03-01 02:15:21 UTC
Permalink
Post by Mike Frysinger
Post by David Daney
I think it is time that you change your assumption that you can boot a
system that does not contain /dev/console in its root file system. You
cannot do it with a standard Linux kernel.
perhaps you need to change your assumption ? you can boot Linux without
a /dev/console just fine ... you dont get status output, but in an embedded
system, big whoop
-mike
I am obviously wrong for newer kernels. Sorry for that.

But in my past hacking with 2.4 kernels I seem to remember that the
kernel would panic if the rootfs was missing /dev/console. However I
suppose I could be wrong about that as well.

David Daney
David Daney
2007-03-01 02:15:21 UTC
Permalink
Post by Mike Frysinger
Post by David Daney
I think it is time that you change your assumption that you can boot a
system that does not contain /dev/console in its root file system. You
cannot do it with a standard Linux kernel.
perhaps you need to change your assumption ? you can boot Linux without
a /dev/console just fine ... you dont get status output, but in an embedded
system, big whoop
-mike
I am obviously wrong for newer kernels. Sorry for that.

But in my past hacking with 2.4 kernels I seem to remember that the
kernel would panic if the rootfs was missing /dev/console. However I
suppose I could be wrong about that as well.

David Daney
Terry Barnaby
2007-02-28 21:29:45 UTC
Permalink
Post by David Daney
Post by Terry Barnaby
Post by Mike Frysinger
Post by Terry Barnaby
However, init and other programs obviously require /dev/console (and
other /dev entries).
they dont require /dev/console
Post by Terry Barnaby
I was wondering about adding an option to init where it would create a
tmpfs file system, mount it on /dev and create a /dev/console node if no
/dev/console was found. I guess it could do a bit more and function as
udev as well.
it wouldnt work ... the kernel opens up /dev/console before executing
init, so even if /sbin/init created the device node, it wouldnt matter
also, this is what init scripts are for ... such / policy handling
does not belong hardcoded in the C code
-mike
No, they don't require /dev/console just to operate, but if you want
debug printout they do :)
Init could easily reopen its controlling terminal to the created
/dev/console and continue ...
The reason I was looking at getting init to create /dev/console was so
that I could debug my init scripts that are not working when
/dev/console does not exist ...
Why do you think what Make says is false? All your posts on this
subject are premised on that false belief.
I think it is time that you change your assumption that you can boot a
system that does not contain /dev/console in its root file system. You
cannot do it with a standard Linux kernel.
1) Put /dev/console in your root filesystem.
2) Hack up your kernel so that /dev/console is not needed.
David Daney
Hi,

Because, you can !
You can boot a system without /dev/console and get init to create the
basic /dev/console and continue. At least with the 2.6.19 kernel. My
patch to the Busybox init later in this thread does this and with an
un-modified kernel (in fact a standard Fedora 6 binary kernel).

I can now boot my system without any /dev nodes in sight. Init mounts a
tmpfs file system on /dev and creates the two necessary nodes
/dev/console and /dev/null and the rcS init script creates the rest.
However, being new to Busybox I'm not sure that this is the best
approach ...

Cheers

Terry
Mike Frysinger
2007-03-01 01:24:48 UTC
Permalink
Post by David Daney
I think it is time that you change your assumption that you can boot a
system that does not contain /dev/console in its root file system. You
cannot do it with a standard Linux kernel.
perhaps you need to change your assumption ? you can boot Linux without
a /dev/console just fine ... you dont get status output, but in an embedded
system, big whoop
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070228/5e091f32/attachment-0002.pgp
David Daney
2007-02-28 17:33:54 UTC
Permalink
Post by Terry Barnaby
Post by Mike Frysinger
Post by Terry Barnaby
However, init and other programs obviously require /dev/console (and
other /dev entries).
they dont require /dev/console
Post by Terry Barnaby
I was wondering about adding an option to init where it would create a
tmpfs file system, mount it on /dev and create a /dev/console node if no
/dev/console was found. I guess it could do a bit more and function as
udev as well.
it wouldnt work ... the kernel opens up /dev/console before executing init, so
even if /sbin/init created the device node, it wouldnt matter
also, this is what init scripts are for ... such / policy handling does not
belong hardcoded in the C code
-mike
No, they don't require /dev/console just to operate, but if you want
debug printout they do :)
Init could easily reopen its controlling terminal to the created
/dev/console and continue ...
The reason I was looking at getting init to create /dev/console was so
that I could debug my init scripts that are not working when
/dev/console does not exist ...
Why do you think what Make says is false? All your posts on this
subject are premised on that false belief.

I think it is time that you change your assumption that you can boot a
system that does not contain /dev/console in its root file system. You
cannot do it with a standard Linux kernel.

As I see it you have two choices:

1) Put /dev/console in your root filesystem.
2) Hack up your kernel so that /dev/console is not needed.

David Daney
Terry Barnaby
2007-02-27 21:45:49 UTC
Permalink
Post by Mike Frysinger
Post by Terry Barnaby
However, init and other programs obviously require /dev/console (and
other /dev entries).
they dont require /dev/console
Post by Terry Barnaby
I was wondering about adding an option to init where it would create a
tmpfs file system, mount it on /dev and create a /dev/console node if no
/dev/console was found. I guess it could do a bit more and function as
udev as well.
it wouldnt work ... the kernel opens up /dev/console before executing init, so
even if /sbin/init created the device node, it wouldnt matter
also, this is what init scripts are for ... such / policy handling does not
belong hardcoded in the C code
-mike
No, they don't require /dev/console just to operate, but if you want
debug printout they do :)

Init could easily reopen its controlling terminal to the created
/dev/console and continue ...

The reason I was looking at getting init to create /dev/console was so
that I could debug my init scripts that are not working when
/dev/console does not exist ...

Terry
Luciano Miguel Ferreira Rocha
2007-02-27 23:49:38 UTC
Permalink
Post by Terry Barnaby
Hi,
I am trying to create a basic Linux system based on Busybox and would
like the ability to create the root file system as a normal user and
without any /dev entries. The startup script would create the /dev
entries as needed.
However, init and other programs obviously require /dev/console (and
other /dev entries).
Are you using initramfs? You can create cpios with special files,
different owners and suid/sgid as normal user, using usr/gen_init_cpio.c
in the Linux source tree.
--
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070227/6e2577fe/attachment.pgp
Terry Barnaby
2007-02-28 09:23:22 UTC
Permalink
Post by Luciano Miguel Ferreira Rocha
Post by Terry Barnaby
Hi,
I am trying to create a basic Linux system based on Busybox and would
like the ability to create the root file system as a normal user and
without any /dev entries. The startup script would create the /dev
entries as needed.
However, init and other programs obviously require /dev/console (and
other /dev entries).
Are you using initramfs? You can create cpios with special files,
different owners and suid/sgid as normal user, using usr/gen_init_cpio.c
in the Linux source tree.
Hi Luciano,

Yes, I am using initramfs and thanks for the info. I could use this for
the boot initrd, but the system then mounts its real root fs using a
read only NFS mount. I would prefer not to have a /dev/console in my NFS
mounted file system either ...

Cheers

Terry
Luciano Miguel Ferreira Rocha
2007-02-28 10:16:45 UTC
Permalink
Post by Terry Barnaby
Yes, I am using initramfs and thanks for the info. I could use this for
the boot initrd, but the system then mounts its real root fs using a
read only NFS mount. I would prefer not to have a /dev/console in my NFS
mounted file system either ...
Well, you'll still need some RW paths in your system. You can accomplish
that for /dev and get a working one too by keeping the one in initramfs:

mount --bind /dev /nfsroot/dev
...
switch_root
--
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070228/7eb11e7d/attachment.pgp
Terry Barnaby
2007-02-28 10:37:48 UTC
Permalink
Post by Luciano Miguel Ferreira Rocha
Post by Terry Barnaby
Yes, I am using initramfs and thanks for the info. I could use this for
the boot initrd, but the system then mounts its real root fs using a
read only NFS mount. I would prefer not to have a /dev/console in my NFS
mounted file system either ...
Well, you'll still need some RW paths in your system. You can accomplish
mount --bind /dev /nfsroot/dev
...
switch_root
I guess I could do that, but I would like the initial boot tmpfs to have
gone once the system is booted so that the NFS mounted file system is
the only one in operation. I have created tmpfs file systems for
/dev,/tmp etc in my /etc/init.d/rcS script and this works fine if there
is a /dev/console ...

I have had a quick look at the busybox init, and it appears that if
there is not a /dev/console or /dev/null then it will not run any of the
scripts .... So /dev/console or /dev/null is required for init to run.

I am still thinking it would be best to add the ability for init to
create a basic /dev with /dev/console etc if these do not exist. This
still appears a cleaner way of doing things to me at the moment ...
This could be done internally or by calling an external script from
init although it would be nice if /dev/console existed as early on as
possible to at-least get debug info from programs running.


Terry
Terry Barnaby
2007-02-28 11:55:40 UTC
Permalink
Hi,

I have decided to have a go and add support to init to create
a tmpfs file system on /dev and the two main device nodes /dev/console
and /dev/null if no /dev/console exists on the rootfs.

This feature is enabled with the FEATURE_INIT_UDEV option.

If this option is enabled and the file /dev/console does not exist then
init will mount a tmpfs file system on /dev and create the basic device
nodes /dev/console and /dev/null. This allows a system to boot and run
without any device nodes in the root file system. The system startup
scripts can create additional device nodes as needed or a full udev
implementation can then take over.

I am using this for my own system at the moment and thought I would
release the patch for interest. This is probably not the best way to
achieve the task in hand, but it does work well.

Cheers


Terry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: beam-init-udev-1.patch
Type: text/x-patch
Size: 1963 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070228/f73e4e37/attachment.bin
Wim Vinckier
2007-02-28 16:13:13 UTC
Permalink
Nice, looks like the patch I just needed. :-)
Post by Terry Barnaby
Hi,
I have decided to have a go and add support to init to create
a tmpfs file system on /dev and the two main device nodes /dev/console
and /dev/null if no /dev/console exists on the rootfs.
This feature is enabled with the FEATURE_INIT_UDEV option.
If this option is enabled and the file /dev/console does not exist then
init will mount a tmpfs file system on /dev and create the basic device
nodes /dev/console and /dev/null. This allows a system to boot and run
without any device nodes in the root file system. The system startup
scripts can create additional device nodes as needed or a full udev
implementation can then take over.
I am using this for my own system at the moment and thought I would
release the patch for interest. This is probably not the best way to
achieve the task in hand, but it does work well.
Cheers
Terry
_______________________________________________
busybox mailing list
busybox at busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
--
You have been on the computer to long when you start tilting your head
sideways to smile :-)
Wim Vinckier
2007-02-28 16:13:13 UTC
Permalink
Nice, looks like the patch I just needed. :-)
Post by Terry Barnaby
Hi,
I have decided to have a go and add support to init to create
a tmpfs file system on /dev and the two main device nodes /dev/console
and /dev/null if no /dev/console exists on the rootfs.
This feature is enabled with the FEATURE_INIT_UDEV option.
If this option is enabled and the file /dev/console does not exist then
init will mount a tmpfs file system on /dev and create the basic device
nodes /dev/console and /dev/null. This allows a system to boot and run
without any device nodes in the root file system. The system startup
scripts can create additional device nodes as needed or a full udev
implementation can then take over.
I am using this for my own system at the moment and thought I would
release the patch for interest. This is probably not the best way to
achieve the task in hand, but it does work well.
Cheers
Terry
_______________________________________________
busybox mailing list
busybox at busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
--
You have been on the computer to long when you start tilting your head
sideways to smile :-)
Denis Vlasenko
2007-02-28 22:43:40 UTC
Permalink
Post by Terry Barnaby
I have had a quick look at the busybox init, and it appears that if
there is not a /dev/console or /dev/null then it will not run any of the
scripts .... So /dev/console or /dev/null is required for init to run.
I am still thinking it would be best to add the ability for init to
create a basic /dev with /dev/console etc if these do not exist. This
still appears a cleaner way of doing things to me at the moment ...
This could be done internally or by calling an external script from
init although it would be nice if /dev/console existed as early on as
possible to at-least get debug info from programs running.
kernel boored with: init=/somewhere/fix_dev.sh

fix_dev.sh:

#!/bin/sh
mknod ... /dev/....
exec /sbin/init "$@"

No hacking in init! :)

Do you see any problems with this approach?
--
vda
Mike Frysinger
2007-03-01 01:26:05 UTC
Permalink
Post by Denis Vlasenko
#!/bin/sh
mknod ... /dev/....
No hacking in init! :)
Do you see any problems with this approach?
you should add redirects so that /sbin/init opens /dev/console for its stdin
and stdout ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070228/9669d51e/attachment.pgp
Robert Schwebel
2007-03-11 22:06:14 UTC
Permalink
Post by Mike Frysinger
you should add redirects so that /sbin/init opens /dev/console for its
stdin and stdout ...
I tried it like this:

----------8<----------
#!/bin/sh

mount -t tmpfs none /dev -o mode=755

mknod /dev/console c 5 1
chmod 600 /dev/console
mknod /dev/null c 1 3
chmod 666 /dev/null

exec /bin/busybox init $@ 1> /dev/console 2> /dev/console < /dev/console
----------8<----------

but still get:

VFS: Mounted root (nfs filesystem).
Freeing init memory: 88K
Warning: unable to open an initial console.
init started: BusyBox v1.1.3 (2007.03.11-10:31+0000) multi-call binary

Does anybody have an idea how to get rid of the warning?

Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
Luciano Miguel Ferreira Rocha
2007-03-11 22:53:20 UTC
Permalink
Post by Robert Schwebel
VFS: Mounted root (nfs filesystem).
Freeing init memory: 88K
Warning: unable to open an initial console.
init started: BusyBox v1.1.3 (2007.03.11-10:31+0000) multi-call binary
Does anybody have an idea how to get rid of the warning?
It's printed by the kernel, in init/main.c, init_post(). It's printed
as KERN_WARNING, so I don't think you can quiet it short of changing the
source.
--
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070311/376f92c0/attachment.pgp
Denis Vlasenko
2007-03-11 21:55:26 UTC
Permalink
Post by Robert Schwebel
Post by Mike Frysinger
you should add redirects so that /sbin/init opens /dev/console for its
stdin and stdout ...
----------8<----------
#!/bin/sh
mount -t tmpfs none /dev -o mode=755
mknod /dev/console c 5 1
chmod 600 /dev/console
mknod /dev/null c 1 3
chmod 666 /dev/null
----------8<----------
VFS: Mounted root (nfs filesystem).
Freeing init memory: 88K
Warning: unable to open an initial console.
init started: BusyBox v1.1.3 (2007.03.11-10:31+0000) multi-call binary
Does anybody have an idea how to get rid of the warning?
So it works! The warning is a cosmetic issue.

You can delete relevant printk from kernel source, I guess...
--
vda
Robin Farine
2007-03-11 22:46:49 UTC
Permalink
Post by Robert Schwebel
----------8<----------
#!/bin/sh
mount -t tmpfs none /dev -o mode=755
mknod /dev/console c 5 1
chmod 600 /dev/console
mknod /dev/null c 1 3
chmod 666 /dev/null
/dev/console ----------8<----------
VFS: Mounted root (nfs filesystem).
Freeing init memory: 88K
Warning: unable to open an initial console.
The kernel displays this message just before it tries to exec an
init executable.
Post by Robert Schwebel
init started: BusyBox v1.1.3 (2007.03.11-10:31+0000) multi-call binary
Does anybody have an idea how to get rid of the warning?
By creating a /dev/console device node in the NFS exported
filesystem ?

Robin
Denis Vlasenko
2007-03-12 15:22:56 UTC
Permalink
Post by Robin Farine
Post by Robert Schwebel
VFS: Mounted root (nfs filesystem).
Freeing init memory: 88K
Warning: unable to open an initial console.
The kernel displays this message just before it tries to exec an
init executable.
Yup.
Post by Robin Farine
Post by Robert Schwebel
init started: BusyBox v1.1.3 (2007.03.11-10:31+0000) multi-call binary
Does anybody have an idea how to get rid of the warning?
By creating a /dev/console device node in the NFS exported
filesystem ?
The whole point of his quest was to be able to _not_ have
/dev populated on rootfs. Imagine that root filesystem
doesn't support device nodes (for example, it's NTFS).
[Yes I agree it's perverted].
--
vda
Mike Frysinger
2007-03-12 17:13:28 UTC
Permalink
Post by Denis Vlasenko
Post by Robin Farine
Post by Robert Schwebel
Does anybody have an idea how to get rid of the warning?
By creating a /dev/console device node in the NFS exported
filesystem ?
The whole point of his quest was to be able to _not_ have
/dev populated on rootfs. Imagine that root filesystem
doesn't support device nodes (for example, it's NTFS).
[Yes I agree it's perverted].
not too perverted actually ... imagine a compact flash card formated as FAT32

of course, another option would be to use initramfs ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070312/7e4eed9e/attachment.pgp
Robin Farine
2007-03-12 17:20:01 UTC
Permalink
Post by Mike Frysinger
Post by Denis Vlasenko
Post by Robin Farine
Post by Robert Schwebel
Does anybody have an idea how to get rid of the warning?
By creating a /dev/console device node in the NFS exported
filesystem ?
The whole point of his quest was to be able to _not_ have
/dev populated on rootfs. Imagine that root filesystem
doesn't support device nodes (for example, it's NTFS).
[Yes I agree it's perverted].
not too perverted actually ... imagine a compact flash card
formated as FAT32
With other problems: no links, 8.3 names, case insensitivity, no
permissions, and maybe more.
Post by Mike Frysinger
of course, another option would be to use initramfs ...
It seems to me that it would be easier to just format the flash card
using a more friendly filesystem...

Robin
Mike Frysinger
2007-03-12 19:49:45 UTC
Permalink
Post by Robin Farine
Post by Mike Frysinger
not too perverted actually ... imagine a compact flash card
formated as FAT32
With other problems: no links, 8.3 names, case insensitivity, no
permissions, and maybe more.
Post by Mike Frysinger
of course, another option would be to use initramfs ...
It seems to me that it would be easier to just format the flash card
using a more friendly filesystem...
that wasnt really the point ... sure i could format the CF card, but keeping
it FAT32 makes for some fun product integration with Windows

i'm not thinking of some an embedded system that is purely Linux
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070312/194836a0/attachment.pgp
Mike Frysinger
2007-03-12 19:49:45 UTC
Permalink
Post by Robin Farine
Post by Mike Frysinger
not too perverted actually ... imagine a compact flash card
formated as FAT32
With other problems: no links, 8.3 names, case insensitivity, no
permissions, and maybe more.
Post by Mike Frysinger
of course, another option would be to use initramfs ...
It seems to me that it would be easier to just format the flash card
using a more friendly filesystem...
that wasnt really the point ... sure i could format the CF card, but keeping
it FAT32 makes for some fun product integration with Windows

i'm not thinking of some an embedded system that is purely Linux
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070312/194836a0/attachment-0002.pgp
Robin Farine
2007-03-12 17:20:01 UTC
Permalink
Post by Mike Frysinger
Post by Denis Vlasenko
Post by Robin Farine
Post by Robert Schwebel
Does anybody have an idea how to get rid of the warning?
By creating a /dev/console device node in the NFS exported
filesystem ?
The whole point of his quest was to be able to _not_ have
/dev populated on rootfs. Imagine that root filesystem
doesn't support device nodes (for example, it's NTFS).
[Yes I agree it's perverted].
not too perverted actually ... imagine a compact flash card
formated as FAT32
With other problems: no links, 8.3 names, case insensitivity, no
permissions, and maybe more.
Post by Mike Frysinger
of course, another option would be to use initramfs ...
It seems to me that it would be easier to just format the flash card
using a more friendly filesystem...

Robin
Robin Farine
2007-03-12 17:01:32 UTC
Permalink
Post by Denis Vlasenko
Post by Robin Farine
By creating a /dev/console device node in the NFS exported
filesystem ?
The whole point of his quest was to be able to _not_ have
/dev populated on rootfs. Imagine that root filesystem
doesn't support device nodes (for example, it's NTFS).
[Yes I agree it's perverted].
OK, although only /dev/console is required in the rootfs, the other
device nodes can be created later in the tmpfs filesystem. So if I
understand correctly, the goal was to avoid the warning message
when booting with a non-unix friendly filesystem exported with NFS,
used as root filesystem for Linux based systems... Never thought
about that possibility :-).

Robin
Mike Frysinger
2007-03-12 17:13:28 UTC
Permalink
Post by Denis Vlasenko
Post by Robin Farine
Post by Robert Schwebel
Does anybody have an idea how to get rid of the warning?
By creating a /dev/console device node in the NFS exported
filesystem ?
The whole point of his quest was to be able to _not_ have
/dev populated on rootfs. Imagine that root filesystem
doesn't support device nodes (for example, it's NTFS).
[Yes I agree it's perverted].
not too perverted actually ... imagine a compact flash card formated as FAT32

of course, another option would be to use initramfs ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070312/7e4eed9e/attachment-0002.pgp
Robin Farine
2007-03-12 17:01:32 UTC
Permalink
Post by Denis Vlasenko
Post by Robin Farine
By creating a /dev/console device node in the NFS exported
filesystem ?
The whole point of his quest was to be able to _not_ have
/dev populated on rootfs. Imagine that root filesystem
doesn't support device nodes (for example, it's NTFS).
[Yes I agree it's perverted].
OK, although only /dev/console is required in the rootfs, the other
device nodes can be created later in the tmpfs filesystem. So if I
understand correctly, the goal was to avoid the warning message
when booting with a non-unix friendly filesystem exported with NFS,
used as root filesystem for Linux based systems... Never thought
about that possibility :-).

Robin
Robert Schwebel
2007-03-13 07:59:13 UTC
Permalink
Post by Robin Farine
By creating a /dev/console device node in the NFS exported
filesystem ?
Well, for example in PTXdist, we let a user build a root filesystem for
an embedded system. And having to create root/dev/{console,null} is one
of the rare cases which can only be done with root permissions at the
moment, so being able to get rid of that step would be a good thing.

Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
Robin Farine
2007-03-13 08:43:45 UTC
Permalink
Post by Robert Schwebel
Post by Robin Farine
By creating a /dev/console device node in the NFS exported
filesystem ?
Well, for example in PTXdist, we let a user build a root
filesystem for an embedded system. And having to create
root/dev/{console,null} is one of the rare cases which can only
be done with root permissions at the moment, so being able to get
rid of that step would be a good thing.
OK, I see. The NFS case is not easy. But setting up a system to
export a given filesystem also requires root privilege, so creating
the 2 device nodes can be done at this moment, it is a one time
operation. Does PTXdist allow you to setup an NFS root filesystem ?
Otherwise, fakeroot is sufficient to create complete filesystem
images.

Robin
Robert Schwebel
2007-03-13 16:32:34 UTC
Permalink
Post by Robin Farine
Post by Robert Schwebel
Well, for example in PTXdist, we let a user build a root
filesystem for an embedded system. And having to create
root/dev/{console,null} is one of the rare cases which can only
be done with root permissions at the moment, so being able to get
rid of that step would be a good thing.
OK, I see. The NFS case is not easy. But setting up a system to
export a given filesystem also requires root privilege, so creating
the 2 device nodes can be done at this moment, it is a one time
operation. Does PTXdist allow you to setup an NFS root filesystem?
Otherwise, fakeroot is sufficient to create complete filesystem
images.
PTXdist builds a root filesystem which can be either flashed to the
device (via a fakeroot using script which recreates the permissions) or
mounted to the devics by NFS. The flash case is handled by fakeroot very
well, but for NFS you need to create a _real_ device node.

Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
Robert Schwebel
2007-03-13 16:32:34 UTC
Permalink
Post by Robin Farine
Post by Robert Schwebel
Well, for example in PTXdist, we let a user build a root
filesystem for an embedded system. And having to create
root/dev/{console,null} is one of the rare cases which can only
be done with root permissions at the moment, so being able to get
rid of that step would be a good thing.
OK, I see. The NFS case is not easy. But setting up a system to
export a given filesystem also requires root privilege, so creating
the 2 device nodes can be done at this moment, it is a one time
operation. Does PTXdist allow you to setup an NFS root filesystem?
Otherwise, fakeroot is sufficient to create complete filesystem
images.
PTXdist builds a root filesystem which can be either flashed to the
device (via a fakeroot using script which recreates the permissions) or
mounted to the devics by NFS. The flash case is handled by fakeroot very
well, but for NFS you need to create a _real_ device node.

Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
Robin Farine
2007-03-13 08:43:45 UTC
Permalink
Post by Robert Schwebel
Post by Robin Farine
By creating a /dev/console device node in the NFS exported
filesystem ?
Well, for example in PTXdist, we let a user build a root
filesystem for an embedded system. And having to create
root/dev/{console,null} is one of the rare cases which can only
be done with root permissions at the moment, so being able to get
rid of that step would be a good thing.
OK, I see. The NFS case is not easy. But setting up a system to
export a given filesystem also requires root privilege, so creating
the 2 device nodes can be done at this moment, it is a one time
operation. Does PTXdist allow you to setup an NFS root filesystem ?
Otherwise, fakeroot is sufficient to create complete filesystem
images.

Robin
Denis Vlasenko
2007-03-12 15:22:56 UTC
Permalink
Post by Robin Farine
Post by Robert Schwebel
VFS: Mounted root (nfs filesystem).
Freeing init memory: 88K
Warning: unable to open an initial console.
The kernel displays this message just before it tries to exec an
init executable.
Yup.
Post by Robin Farine
Post by Robert Schwebel
init started: BusyBox v1.1.3 (2007.03.11-10:31+0000) multi-call binary
Does anybody have an idea how to get rid of the warning?
By creating a /dev/console device node in the NFS exported
filesystem ?
The whole point of his quest was to be able to _not_ have
/dev populated on rootfs. Imagine that root filesystem
doesn't support device nodes (for example, it's NTFS).
[Yes I agree it's perverted].
--
vda
Robert Schwebel
2007-03-13 07:59:13 UTC
Permalink
Post by Robin Farine
By creating a /dev/console device node in the NFS exported
filesystem ?
Well, for example in PTXdist, we let a user build a root filesystem for
an embedded system. And having to create root/dev/{console,null} is one
of the rare cases which can only be done with root permissions at the
moment, so being able to get rid of that step would be a good thing.

Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
Robert Schwebel
2007-03-13 08:00:27 UTC
Permalink
Post by Robert Schwebel
----------8<----------
#!/bin/sh
mount -t tmpfs none /dev -o mode=755
mknod /dev/console c 5 1
chmod 600 /dev/console
mknod /dev/null c 1 3
chmod 666 /dev/null
----------8<----------
VFS: Mounted root (nfs filesystem).
Freeing init memory: 88K
Warning: unable to open an initial console.
init started: BusyBox v1.1.3 (2007.03.11-10:31+0000) multi-call binary
Does anybody have an idea how to get rid of the warning?
Ah, and a regression: you don't get kernel messages any more on that
console, because although init has a console now, the kernel does not.

Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
Denis Vlasenko
2007-03-13 21:15:33 UTC
Permalink
Hi.
Post by Robert Schwebel
Post by Robert Schwebel
VFS: Mounted root (nfs filesystem).
Freeing init memory: 88K
Warning: unable to open an initial console.
init started: BusyBox v1.1.3 (2007.03.11-10:31+0000) multi-call binary
Does anybody have an idea how to get rid of the warning?
Delete relevant kernel messages in the source:

init/main.c

if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
printk(KERN_WARNING "Warning: unable to open an initial console.\n");

(void) sys_dup(0);
(void) sys_dup(0);
Post by Robert Schwebel
Ah, and a regression: you don't get kernel messages any more on that
console, because although init has a console now, the kernel does not.
What does it mean - "kernel does not have a console"?
Console is still there, and kernel can print to it,
regardless whether /dev/console exist or not, opened or not.
--
vda
Robert Schwebel
2007-03-21 07:41:13 UTC
Permalink
Post by Luciano Miguel Ferreira Rocha
init/main.c
if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
printk(KERN_WARNING "Warning: unable to open an initial console.\n");
(void) sys_dup(0);
(void) sys_dup(0);
Uuuh, crude. I'm wondering if it would be possible to implement the hack
currently done in userspace in kernel; in the end all the kernel does
her is to get a file descriptor for character device 5,1 and it only
needs the filesystem entry because it uses sys_open(), which is path
based.
Post by Luciano Miguel Ferreira Rocha
Post by Robert Schwebel
Ah, and a regression: you don't get kernel messages any more on that
console, because although init has a console now, the kernel does not.
What does it mean - "kernel does not have a console"? Console is
still there, and kernel can print to it, regardless whether
/dev/console exist or not, opened or not.
When booting with a serial console and not running a syslogd, I'm
usually seeing kernel messages in the serial terminal. With the hack, I
don't.

Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
Robert Schwebel
2007-03-21 07:41:13 UTC
Permalink
Post by Luciano Miguel Ferreira Rocha
init/main.c
if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
printk(KERN_WARNING "Warning: unable to open an initial console.\n");
(void) sys_dup(0);
(void) sys_dup(0);
Uuuh, crude. I'm wondering if it would be possible to implement the hack
currently done in userspace in kernel; in the end all the kernel does
her is to get a file descriptor for character device 5,1 and it only
needs the filesystem entry because it uses sys_open(), which is path
based.
Post by Luciano Miguel Ferreira Rocha
Post by Robert Schwebel
Ah, and a regression: you don't get kernel messages any more on that
console, because although init has a console now, the kernel does not.
What does it mean - "kernel does not have a console"? Console is
still there, and kernel can print to it, regardless whether
/dev/console exist or not, opened or not.
When booting with a serial console and not running a syslogd, I'm
usually seeing kernel messages in the serial terminal. With the hack, I
don't.

Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
Denis Vlasenko
2007-03-13 21:15:33 UTC
Permalink
Hi.
Post by Robert Schwebel
Post by Robert Schwebel
VFS: Mounted root (nfs filesystem).
Freeing init memory: 88K
Warning: unable to open an initial console.
init started: BusyBox v1.1.3 (2007.03.11-10:31+0000) multi-call binary
Does anybody have an idea how to get rid of the warning?
Delete relevant kernel messages in the source:

init/main.c

if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
printk(KERN_WARNING "Warning: unable to open an initial console.\n");

(void) sys_dup(0);
(void) sys_dup(0);
Post by Robert Schwebel
Ah, and a regression: you don't get kernel messages any more on that
console, because although init has a console now, the kernel does not.
What does it mean - "kernel does not have a console"?
Console is still there, and kernel can print to it,
regardless whether /dev/console exist or not, opened or not.
--
vda
Luciano Miguel Ferreira Rocha
2007-03-11 22:53:20 UTC
Permalink
Post by Robert Schwebel
VFS: Mounted root (nfs filesystem).
Freeing init memory: 88K
Warning: unable to open an initial console.
init started: BusyBox v1.1.3 (2007.03.11-10:31+0000) multi-call binary
Does anybody have an idea how to get rid of the warning?
It's printed by the kernel, in init/main.c, init_post(). It's printed
as KERN_WARNING, so I don't think you can quiet it short of changing the
source.
--
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070311/376f92c0/attachment-0002.pgp
Denis Vlasenko
2007-03-11 21:55:26 UTC
Permalink
Post by Robert Schwebel
Post by Mike Frysinger
you should add redirects so that /sbin/init opens /dev/console for its
stdin and stdout ...
----------8<----------
#!/bin/sh
mount -t tmpfs none /dev -o mode=755
mknod /dev/console c 5 1
chmod 600 /dev/console
mknod /dev/null c 1 3
chmod 666 /dev/null
----------8<----------
VFS: Mounted root (nfs filesystem).
Freeing init memory: 88K
Warning: unable to open an initial console.
init started: BusyBox v1.1.3 (2007.03.11-10:31+0000) multi-call binary
Does anybody have an idea how to get rid of the warning?
So it works! The warning is a cosmetic issue.

You can delete relevant printk from kernel source, I guess...
--
vda
Robin Farine
2007-03-11 22:46:49 UTC
Permalink
Post by Robert Schwebel
----------8<----------
#!/bin/sh
mount -t tmpfs none /dev -o mode=755
mknod /dev/console c 5 1
chmod 600 /dev/console
mknod /dev/null c 1 3
chmod 666 /dev/null
/dev/console ----------8<----------
VFS: Mounted root (nfs filesystem).
Freeing init memory: 88K
Warning: unable to open an initial console.
The kernel displays this message just before it tries to exec an
init executable.
Post by Robert Schwebel
init started: BusyBox v1.1.3 (2007.03.11-10:31+0000) multi-call binary
Does anybody have an idea how to get rid of the warning?
By creating a /dev/console device node in the NFS exported
filesystem ?

Robin
Robert Schwebel
2007-03-13 08:00:27 UTC
Permalink
Post by Robert Schwebel
----------8<----------
#!/bin/sh
mount -t tmpfs none /dev -o mode=755
mknod /dev/console c 5 1
chmod 600 /dev/console
mknod /dev/null c 1 3
chmod 666 /dev/null
----------8<----------
VFS: Mounted root (nfs filesystem).
Freeing init memory: 88K
Warning: unable to open an initial console.
init started: BusyBox v1.1.3 (2007.03.11-10:31+0000) multi-call binary
Does anybody have an idea how to get rid of the warning?
Ah, and a regression: you don't get kernel messages any more on that
console, because although init has a console now, the kernel does not.

Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
Robert Schwebel
2007-03-11 22:06:14 UTC
Permalink
Post by Mike Frysinger
you should add redirects so that /sbin/init opens /dev/console for its
stdin and stdout ...
I tried it like this:

----------8<----------
#!/bin/sh

mount -t tmpfs none /dev -o mode=755

mknod /dev/console c 5 1
chmod 600 /dev/console
mknod /dev/null c 1 3
chmod 666 /dev/null

exec /bin/busybox init $@ 1> /dev/console 2> /dev/console < /dev/console
----------8<----------

but still get:

VFS: Mounted root (nfs filesystem).
Freeing init memory: 88K
Warning: unable to open an initial console.
init started: BusyBox v1.1.3 (2007.03.11-10:31+0000) multi-call binary

Does anybody have an idea how to get rid of the warning?

Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
Terry Barnaby
2007-03-01 06:49:18 UTC
Permalink
Post by Denis Vlasenko
Post by Terry Barnaby
I have had a quick look at the busybox init, and it appears that if
there is not a /dev/console or /dev/null then it will not run any of the
scripts .... So /dev/console or /dev/null is required for init to run.
I am still thinking it would be best to add the ability for init to
create a basic /dev with /dev/console etc if these do not exist. This
still appears a cleaner way of doing things to me at the moment ...
This could be done internally or by calling an external script from
init although it would be nice if /dev/console existed as early on as
possible to at-least get debug info from programs running.
kernel boored with: init=/somewhere/fix_dev.sh
#!/bin/sh
mknod ... /dev/....
No hacking in init! :)
Do you see any problems with this approach?
--
vda
Hi,

No problems I can see with this approach apart from the kernel boot line
needing changing in all places and I'm not sure if it will work across a
switch_root. But, I do prefer getting init to do the work. Using init, I
believe, is cleaner, simpler and more in keeping with what init is
supposed to do, assuming you want to use the init boot approach of
course (and no hacking in sh! :) )

Cheers


Terry
Denis Vlasenko
2007-03-03 00:54:32 UTC
Permalink
Post by Terry Barnaby
kernel booted with: init=/somewhere/fix_dev.sh
#!/bin/sh
mknod ... /dev/....
No hacking in init! :)
Do you see any problems with this approach?
No problems I can see with this approach apart from the kernel boot line
needing changing in all places
Nope. Just rename /sbin/init to /sbin/init.binary,
Post by Terry Barnaby
and I'm not sure if it will work across a
switch_root. But, I do prefer getting init to do the work. Using init, I
believe, is cleaner, simpler
I think that programming in C is not simpler than four-line shell script.
It's not easier and not faster to debug or to tailor for special cases
like yours.
Post by Terry Barnaby
and more in keeping with what init is supposed to do
I still don't know what init is supposed to do. For some reason which
I still fail to understand, init has to handle this:

::shutdown:/how/to/shutdown...

but not this:

::network_config:/how/to/set/up/network...
::send_mail:/how/to/send/mail...
::pizza:/how/to/order/food...

Why? Why TERM/pause/KILL/pause/umount/shutdown sequence gets this
special treatment in init?
--
vda
Denis Vlasenko
2007-03-03 00:54:32 UTC
Permalink
Post by Terry Barnaby
kernel booted with: init=/somewhere/fix_dev.sh
#!/bin/sh
mknod ... /dev/....
No hacking in init! :)
Do you see any problems with this approach?
No problems I can see with this approach apart from the kernel boot line
needing changing in all places
Nope. Just rename /sbin/init to /sbin/init.binary,
Post by Terry Barnaby
and I'm not sure if it will work across a
switch_root. But, I do prefer getting init to do the work. Using init, I
believe, is cleaner, simpler
I think that programming in C is not simpler than four-line shell script.
It's not easier and not faster to debug or to tailor for special cases
like yours.
Post by Terry Barnaby
and more in keeping with what init is supposed to do
I still don't know what init is supposed to do. For some reason which
I still fail to understand, init has to handle this:

::shutdown:/how/to/shutdown...

but not this:

::network_config:/how/to/set/up/network...
::send_mail:/how/to/send/mail...
::pizza:/how/to/order/food...

Why? Why TERM/pause/KILL/pause/umount/shutdown sequence gets this
special treatment in init?
--
vda
Mike Frysinger
2007-03-01 01:26:05 UTC
Permalink
Post by Denis Vlasenko
#!/bin/sh
mknod ... /dev/....
No hacking in init! :)
Do you see any problems with this approach?
you should add redirects so that /sbin/init opens /dev/console for its stdin
and stdout ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070228/9669d51e/attachment-0002.pgp
Terry Barnaby
2007-03-01 06:49:18 UTC
Permalink
Post by Denis Vlasenko
Post by Terry Barnaby
I have had a quick look at the busybox init, and it appears that if
there is not a /dev/console or /dev/null then it will not run any of the
scripts .... So /dev/console or /dev/null is required for init to run.
I am still thinking it would be best to add the ability for init to
create a basic /dev with /dev/console etc if these do not exist. This
still appears a cleaner way of doing things to me at the moment ...
This could be done internally or by calling an external script from
init although it would be nice if /dev/console existed as early on as
possible to at-least get debug info from programs running.
kernel boored with: init=/somewhere/fix_dev.sh
#!/bin/sh
mknod ... /dev/....
No hacking in init! :)
Do you see any problems with this approach?
--
vda
Hi,

No problems I can see with this approach apart from the kernel boot line
needing changing in all places and I'm not sure if it will work across a
switch_root. But, I do prefer getting init to do the work. Using init, I
believe, is cleaner, simpler and more in keeping with what init is
supposed to do, assuming you want to use the init boot approach of
course (and no hacking in sh! :) )

Cheers


Terry
Terry Barnaby
2007-02-28 11:55:40 UTC
Permalink
Hi,

I have decided to have a go and add support to init to create
a tmpfs file system on /dev and the two main device nodes /dev/console
and /dev/null if no /dev/console exists on the rootfs.

This feature is enabled with the FEATURE_INIT_UDEV option.

If this option is enabled and the file /dev/console does not exist then
init will mount a tmpfs file system on /dev and create the basic device
nodes /dev/console and /dev/null. This allows a system to boot and run
without any device nodes in the root file system. The system startup
scripts can create additional device nodes as needed or a full udev
implementation can then take over.

I am using this for my own system at the moment and thought I would
release the patch for interest. This is probably not the best way to
achieve the task in hand, but it does work well.

Cheers


Terry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: beam-init-udev-1.patch
Type: text/x-patch
Size: 1963 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070228/f73e4e37/attachment-0002.bin
Denis Vlasenko
2007-02-28 22:43:40 UTC
Permalink
Post by Terry Barnaby
I have had a quick look at the busybox init, and it appears that if
there is not a /dev/console or /dev/null then it will not run any of the
scripts .... So /dev/console or /dev/null is required for init to run.
I am still thinking it would be best to add the ability for init to
create a basic /dev with /dev/console etc if these do not exist. This
still appears a cleaner way of doing things to me at the moment ...
This could be done internally or by calling an external script from
init although it would be nice if /dev/console existed as early on as
possible to at-least get debug info from programs running.
kernel boored with: init=/somewhere/fix_dev.sh

fix_dev.sh:

#!/bin/sh
mknod ... /dev/....
exec /sbin/init "$@"

No hacking in init! :)

Do you see any problems with this approach?
--
vda
Terry Barnaby
2007-02-28 10:37:48 UTC
Permalink
Post by Luciano Miguel Ferreira Rocha
Post by Terry Barnaby
Yes, I am using initramfs and thanks for the info. I could use this for
the boot initrd, but the system then mounts its real root fs using a
read only NFS mount. I would prefer not to have a /dev/console in my NFS
mounted file system either ...
Well, you'll still need some RW paths in your system. You can accomplish
mount --bind /dev /nfsroot/dev
...
switch_root
I guess I could do that, but I would like the initial boot tmpfs to have
gone once the system is booted so that the NFS mounted file system is
the only one in operation. I have created tmpfs file systems for
/dev,/tmp etc in my /etc/init.d/rcS script and this works fine if there
is a /dev/console ...

I have had a quick look at the busybox init, and it appears that if
there is not a /dev/console or /dev/null then it will not run any of the
scripts .... So /dev/console or /dev/null is required for init to run.

I am still thinking it would be best to add the ability for init to
create a basic /dev with /dev/console etc if these do not exist. This
still appears a cleaner way of doing things to me at the moment ...
This could be done internally or by calling an external script from
init although it would be nice if /dev/console existed as early on as
possible to at-least get debug info from programs running.


Terry
Luciano Miguel Ferreira Rocha
2007-02-28 10:16:45 UTC
Permalink
Post by Terry Barnaby
Yes, I am using initramfs and thanks for the info. I could use this for
the boot initrd, but the system then mounts its real root fs using a
read only NFS mount. I would prefer not to have a /dev/console in my NFS
mounted file system either ...
Well, you'll still need some RW paths in your system. You can accomplish
that for /dev and get a working one too by keeping the one in initramfs:

mount --bind /dev /nfsroot/dev
...
switch_root
--
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070228/7eb11e7d/attachment-0002.pgp
Terry Barnaby
2007-02-28 09:23:22 UTC
Permalink
Post by Luciano Miguel Ferreira Rocha
Post by Terry Barnaby
Hi,
I am trying to create a basic Linux system based on Busybox and would
like the ability to create the root file system as a normal user and
without any /dev entries. The startup script would create the /dev
entries as needed.
However, init and other programs obviously require /dev/console (and
other /dev entries).
Are you using initramfs? You can create cpios with special files,
different owners and suid/sgid as normal user, using usr/gen_init_cpio.c
in the Linux source tree.
Hi Luciano,

Yes, I am using initramfs and thanks for the info. I could use this for
the boot initrd, but the system then mounts its real root fs using a
read only NFS mount. I would prefer not to have a /dev/console in my NFS
mounted file system either ...

Cheers

Terry
Terry Barnaby
2007-02-27 09:22:25 UTC
Permalink
Hi,

I am trying to create a basic Linux system based on Busybox and would
like the ability to create the root file system as a normal user and
without any /dev entries. The startup script would create the /dev
entries as needed.
However, init and other programs obviously require /dev/console (and
other /dev entries).

I was wondering about adding an option to init where it would create a
tmpfs file system, mount it on /dev and create a /dev/console node if no
/dev/console was found. I guess it could do a bit more and function as
udev as well.

Do people with Busybox experience think that this a reasonable thing to
do ??

Cheers


Terry
Denis Vlasenko
2007-02-27 17:59:38 UTC
Permalink
Post by Terry Barnaby
I am trying to create a basic Linux system based on Busybox and would
like the ability to create the root file system as a normal user and
without any /dev entries. The startup script would create the /dev
entries as needed.
However, init and other programs obviously require /dev/console (and
other /dev entries).
I was wondering about adding an option to init where it would create a
tmpfs file system, mount it on /dev and create a /dev/console node if no
/dev/console was found. I guess it could do a bit more and function as
udev as well.
I think you are on the right track, but move in the wrong direction
along that track. Code shouldn't be added to init, it should be removed.

http://busybox.net/~vda/example_fs/README
--
vda
Mike Frysinger
2007-02-27 18:28:05 UTC
Permalink
Post by Terry Barnaby
However, init and other programs obviously require /dev/console (and
other /dev entries).
they dont require /dev/console
Post by Terry Barnaby
I was wondering about adding an option to init where it would create a
tmpfs file system, mount it on /dev and create a /dev/console node if no
/dev/console was found. I guess it could do a bit more and function as
udev as well.
it wouldnt work ... the kernel opens up /dev/console before executing init, so
even if /sbin/init created the device node, it wouldnt matter

also, this is what init scripts are for ... such / policy handling does not
belong hardcoded in the C code
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070227/d22d4891/attachment-0002.pgp
Luciano Miguel Ferreira Rocha
2007-02-27 23:49:38 UTC
Permalink
Post by Terry Barnaby
Hi,
I am trying to create a basic Linux system based on Busybox and would
like the ability to create the root file system as a normal user and
without any /dev entries. The startup script would create the /dev
entries as needed.
However, init and other programs obviously require /dev/console (and
other /dev entries).
Are you using initramfs? You can create cpios with special files,
different owners and suid/sgid as normal user, using usr/gen_init_cpio.c
in the Linux source tree.
--
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070227/6e2577fe/attachment-0002.pgp
Loading...