On Tue, May 16, 2006 at 04:02:01PM -0500, Bruce Dubbs wrote:
My question is how to disable udev? It's not hard to copy the device
entries in /dev to another location, but the S10udev script mounts a
tmpfs on top of /dev (and never puts it in mtab). It would appear to me
that the only
Bruce Dubbs wrote these words on 05/16/06 16:02 CST:
My question is how to disable udev? It's not hard to copy the device
entries in /dev to another location, but the S10udev script mounts a
tmpfs on top of /dev (and never puts it in mtab).
I'm just going on recent memory building LFS, but
On 5/16/06, Bruce Dubbs [EMAIL PROTECTED] wrote:
At that time, the link /etc/rc.d/rcsysinit.d/S10udev should be removed.
Finally, rebooting to the LFS system will get us running without udev.
Seems to me all you would need to do is replace S10udev with
S10MAKEDEV or whatever and remove the
Dan Nicholson wrote these words on 05/16/06 16:35 CST:
Seems to me all you would need to do is replace S10udev with
S10MAKEDEV or whatever and remove the the udev_retry symlink
(whichever number it is) then reboot. When you shutdown, tmpfs on
/dev is gone. When you boot, a new tmpfs is
On 5/16/06, Randy McMurchy [EMAIL PROTECTED] wrote:
Dan Nicholson wrote these words on 05/16/06 16:35 CST:
Seems to me all you would need to do is replace S10udev with
S10MAKEDEV or whatever and remove the the udev_retry symlink
(whichever number it is) then reboot. When you shutdown, tmpfs
Dan Nicholson wrote these words on 05/16/06 16:53 CST:
I would reboot, though, since that's the only time a static device
script would be run. I'd want to make sure it worked.
But couldn't you just run it make sure it worked? (as if a bunch of
mknod commands aren't going to work?) :-)
I'm
On 5/16/06, Randy McMurchy [EMAIL PROTECTED] wrote:
But couldn't you just run it make sure it worked? (as if a bunch of
mknod commands aren't going to work?) :-)
Would you really know it worked, though? Presumably, if udev was
working, all the necessary device nodes already exist. Unless
Dan Nicholson wrote:
On 5/16/06, Randy McMurchy [EMAIL PROTECTED] wrote:
Dan Nicholson wrote these words on 05/16/06 16:35 CST:
Seems to me all you would need to do is replace S10udev with
S10MAKEDEV or whatever and remove the the udev_retry symlink
(whichever number it is) then reboot.
On Tue, May 16, 2006 at 03:13:15PM -0700, Dan Nicholson wrote:
This is a very different situation. Windows asks you to reboot after
any silly change to the registry. This change affects how your
hardware interfaces to the kernel. I'd want to know if my system
could bootstrap correctly since
On 5/16/06, Bruce Dubbs [EMAIL PROTECTED] wrote:
We do not want to run MAKEDEV upon boot. The /dev directory only needs
to be populated once.
What do you plan to populate /dev with?
The problem that causes the need to reboot is the fact that /dev has a
tmpfs mounted. If you unmount it,
On Tue, May 16, 2006 at 11:39:41PM +0100, Alex Merry wrote:
Anyway, if we told people how to do it before they rebooted the first
time (to start using their shiny new kernel), there wouldn't really be
an issue. Run MAKEDEV while in the chroot and rm the symlink to the dev
startup script, and
Dan Nicholson wrote:
On 5/16/06, Bruce Dubbs [EMAIL PROTECTED] wrote:
We do not want to run MAKEDEV upon boot. The /dev directory only needs
to be populated once.
What do you plan to populate /dev with?
We have a good set of devices upon the first boot.
I kinda like Alex Merry's
Bruce Dubbs wrote:
Dan Nicholson wrote:
On 5/16/06, Bruce Dubbs [EMAIL PROTECTED] wrote:
We do not want to run MAKEDEV upon boot. The /dev directory only needs
to be populated once.
What do you plan to populate /dev with?
We have a good set of devices upon the first boot.
I kinda like
13 matches
Mail list logo