-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/17/2012 12:54 PM, Dmitrijs Ledkovs wrote:
> At this point for boot performance, you do want to run udev/init as soon
> as possible. And pass the state of udev/init as soon as possible to real
> rootfs/real init.
Last I heard, the consensus was t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/17/2012 07:04 PM, Steve Langasek wrote:
> I think this "mostly" is inexact. I would say about *half* the work is
> handled by the udev rules, and the other half is handled by the linear
> initramfs scripts that include various sleeps, polls, wai
On Sat, May 12, 2012 at 09:37:59PM -0400, Phillip Susi wrote:
> On 05/12/2012 08:54 PM, Steve Langasek wrote:
> > There are many ways that it could be done; using an event-based system that
> > matches the way things are done post-initramfs is probably the simplest and
> > most maintainable, howeve
most general case we might/do need: networking, LUKS,
udev event handling, passing the resulting state back to the real
upstart... etc
See:
https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-event-based-initramfs
---8<---
a. The invocation of cryptsetup is procedural and not complete
On Thu, May 17, 2012 at 09:37:03AM +0100, James Hunt wrote:
> The code for mountall is admittedly more complex than simply calling
> 'mount', but it has the following advantages:
>
> - it actually performs error checking (unlike the initramfs mount code).
> - it provides user feedback on the opera
On 5/17/2012 4:37 AM, James Hunt wrote:
Sounds like both systems are performing initialisation to me. And as we
know, there is symmetry between what happens in the initramfs and what
then has to happen again in the main system. By using Upstart, we get
one tool to do that job without duplication
On 16/05/12 19:09, Phillip Susi wrote:
> On 5/16/2012 9:01 AM, James Hunt wrote:
>> The most obvious reason is that the initramfs has it's own init
>> system (a big shell script). So, an Ubuntu system with an initramfs
>> has two different init systems. By reducing this down to just
>> Upstart, we
On 5/16/2012 9:01 AM, James Hunt wrote:
The most obvious reason is that the initramfs has it's own init
system (a big shell script). So, an Ubuntu system with an initramfs
has two different init systems. By reducing this down to just
Upstart, we get a simpler and hence more readily maintainable s
gle user mode and try to do some recovery without /usr. What is it
that we want to be able to do in rescue mode that requires things from
/usr? If there is a good case for having them in a rescue mode, then
maybe they shouldn't be in /usr in the first place?
A number of upstream projects ar
On Fri, 11 May 2012, Phillip Susi wrote:
> On 5/11/2012 2:52 PM, Clint Byrum wrote:
> > …
> …
There is no reason why it should be mutually exclusive:
1. Gimme a terminal straight away.
2. Get on with booting in the background as, and when disks show up.
The common-case is that the user just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/12/2012 08:54 PM, Steve Langasek wrote:
> There are many ways that it could be done; using an event-based system that
> matches the way things are done post-initramfs is probably the simplest and
> most maintainable, however.
Why? It seems to m
On Sat, May 12, 2012 at 03:09:45PM -0400, Phillip Susi wrote:
> On 05/12/2012 02:09 PM, Steve Langasek wrote:
> > Strawman (not something we discussed in the UDS session):
> > - mountall runs as a job that waits indefinitely for the root filesystem
> > - failsafe-recover is a job that sets a tim
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/12/2012 02:09 PM, Steve Langasek wrote:
> Strawman (not something we discussed in the UDS session):
>
> - mountall runs as a job that waits indefinitely for the root filesystem
> - failsafe-recover is a job that sets a timeout; if the timeout
On Fri, May 11, 2012 at 10:25:48AM -0400, Phillip Susi wrote:
> On 5/11/2012 4:04 AM, Robert Collins wrote:
> >So a related issue is dmraid, which is very similar to mdadm. My last
> >two dmraid machines fail - every time - to activate on boot. The
> >reason being that the devices they depend upon
On 5/11/2012 2:52 PM, Clint Byrum wrote:
So the timeout would be the one in 'udevadm settle'. I think it probably
I don't think we're calling udevadm settle unless you're using an nfs
root or fbdev. The timeout is the one given to wait-for-root which
defaults to 30 seconds.
is long enough
Excerpts from Phillip Susi's message of Fri May 11 07:25:48 -0700 2012:
> On 5/11/2012 4:04 AM, Robert Collins wrote:
> > So a related issue is dmraid, which is very similar to mdadm. My last
> > two dmraid machines fail - every time - to activate on boot. The
> > reason being that the devices they
On 5/11/2012 4:04 AM, Robert Collins wrote:
So a related issue is dmraid, which is very similar to mdadm. My last
two dmraid machines fail - every time - to activate on boot. The
reason being that the devices they depend upon don't come up fast
enough, and the configuration process isn't event-dr
On Fri, May 11, 2012 at 3:54 PM, Phillip Susi wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I was a bit confused when I saw this uds event. It is unclear to me why we
> would want to add upstart to the initramfs. I think it is important to
> remember that the the whole purpose o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I was a bit confused when I saw this uds event. It is unclear to me why we
would want to add upstart to the initramfs. I think it is important to
remember that the the whole purpose of the initramfs is to help the kernel find
the root fs, so thing
19 matches
Mail list logo
