Matthew Burgess wrote:
> On 05/08/2011 19:55, Bruce Dubbs wrote:
>
>> The first script to run is mountvirtfs. Perhaps we could have that
>> create a /dev device like /dev/sda? and mount that as /var before udev
>> ever starts.
>
> Yeah, I started thinking along the same lines, and was wondering
Andrew Benton wrote:
> If you configure your kernel with CONFIG_DEVTMPFS_MOUNT=y the kernel
> will mount a tmpfs on /dev itself and populate it with all the devices
> it knows about. Xorg isn't happy to run without udev there to tell it
> about input devices but I can boot to init 3 no problem _wi
On Fri, 05 Aug 2011 13:55:39 -0500
Bruce Dubbs wrote:
> I've thought for a while that there should be a location that is
> accessible across boots that is always available (not a mountpoint).
> It's a catch-22 though. How do you mount / read only (for security) and
> still be able to write this
On 05/08/2011 19:55, Bruce Dubbs wrote:
> I've thought for a while that there should be a location that is
> accessible across boots that is always available (not a mountpoint).
> It's a catch-22 though. How do you mount / read only (for security) and
> still be able to write this persistent data
On 05/08/2011 19:55, Bruce Dubbs wrote:
> I've thought for a while that there should be a location that is
> accessible across boots that is always available (not a mountpoint).
> It's a catch-22 though. How do you mount / read only (for security) and
> still be able to write this persistent data
Nathan Coulson wrote:
Lets trim a little...
> One thought though, all of our problems stem from udev running before
> mountfs. I have not dug into udev's behavior too much, but I imagine it is
> the --trigger command that populates /dev/{sd*,sr*,hd*}
>
> It looks like we can do something like t
On Fri, Aug 5, 2011 at 2:08 AM, Matthew Burgess <
matt...@linuxfromscratch.org> wrote:
> On Fri, 5 Aug 2011 01:06:52 -0700, Nathan Coulson
> wrote:
> > On Fri, Aug 5, 2011 at 12:12 AM, Matthew Burgess <
> > matt...@linuxfromscratch.org> wrote:
> >
> >> On 05/08/2011 03:41, Bryan Kadzban wrote:
>
On Fri, 5 Aug 2011 01:06:52 -0700, Nathan Coulson wrote:
> On Fri, Aug 5, 2011 at 12:12 AM, Matthew Burgess <
> matt...@linuxfromscratch.org> wrote:
>
>> On 05/08/2011 03:41, Bryan Kadzban wrote:
>> > Matthew Burgess wrote:
>> >> But that raises the question of what that bootscript was trying to d
On Fri, Aug 5, 2011 at 12:12 AM, Matthew Burgess <
matt...@linuxfromscratch.org> wrote:
> On 05/08/2011 03:41, Bryan Kadzban wrote:
> > Matthew Burgess wrote:
> >> But that raises the question of what that bootscript was trying to do
> >> in the first place? So, it turns out that the actions speci
On 05/08/2011 03:41, Bryan Kadzban wrote:
> Matthew Burgess wrote:
>> But that raises the question of what that bootscript was trying to do
>> in the first place? So, it turns out that the actions specified by
>> 'RUN+=' udev rules can fail for any of a variety of reasons, and this
>> script was si
Bryan Kadzban wrote:
> This is true (the system time coming from the BIOS) with hwclock.
> That's what "hwclock --hctosys" reads from, after all. I do not believe
> it's true without it; last I knew, without hwclock, the system would
> start at time zero. (But it's been many years since I tried
Matthew Burgess wrote:
> But that raises the question of what that bootscript was trying to do
> in the first place? So, it turns out that the actions specified by
> 'RUN+=' udev rules can fail for any of a variety of reasons, and this
> script was simply there to retry such failed actions in the h
Hi all,
With the upgrade to Udev-173, we now see a warning that the call to
'udevadm trigger --type=failed --action=add' from S10udev is deprecated.
The thread starting at
http://www.spinics.net/lists/hotplug/msg05039.html goes into more detail
about the issues involved, but in effect, Udev'
Hi all,
With the upgrade to Udev-173, we now see a warning that the call to
'udevadm trigger --type=failed --action=add' from S10udev is deprecated.
The thread starting at
http://www.spinics.net/lists/hotplug/msg05039.html goes into more detail
about the issues involved, but in effect, Udev'
14 matches
Mail list logo
