Camilo Mesias mesias.co.uk> writes:
>
> Hi,
>
> I tried some of these changes and they seemed to work reasonably well
> apart from the grub2 infrastructure is still a bit immature at running
> without initrd... specifically
> ...
> I'm not sure where to report this? Bugs against grub2 or somet
Hi,
I tried some of these changes and they seemed to work reasonably well
apart from the grub2 infrastructure is still a bit immature at running
without initrd... specifically
* I couldn't find a way to tell the grub2 scripts in /etc/grub.d
(10_linux) that I didn't want initrd; I can edit out the
On Wed, Oct 5, 2011 at 5:56 AM, Kay Sievers wrote:
> There is no general rule, but anything that calls 'udevadm settle' is
> suspicious and should be carefully checked if it does not rely on
> assumptions which just bet on luck and can't reliably work in hotplug
> setups.
Kay,
Is there a general
Kay Sievers (kay.siev...@vrfy.org) said:
> Any system service that today relies in its core on 'udevadm settle'
> or scsi-wait-scan module, or any of the other bad hacks in that
> category, anything that uses these barriers as a checkpoint to block
> on, to do its synchronous actions, should be co
On Wed, 2011-10-05 at 15:28 +0200, Lennart Poettering wrote:
> Please, don't claim that "udev settle" was a sensible prerequisite. It
> isn't. It has no place in today's dynamic hardware.
Thanks for the correction.
(you might want to talk to the anaconda team, then, because liveinst
runs 'udevad
On Wed, Oct 5, 2011 at 9:22 AM, JB wrote:
> Here it is.
No..that's not it.. that is the starting point necessary to understand
the udev differences between the two systems. It is not a dissection.
To understand what is happening with udev across those systems you
have to look really close at the
Jef Spaleta gmail.com> writes:
>
> On Tue, Oct 4, 2011 at 6:40 PM, Adam Williamson redhat.com>
> wrote:
> > So essentially all that's going on here is 'wait for udev to be done',
> > which is a fairly sensible prerequisite for all manner of other bits of
> > boot.
> >
> > The reasons why udev
On Tue, Oct 4, 2011 at 6:40 PM, Adam Williamson wrote:
> So essentially all that's going on here is 'wait for udev to be done',
> which is a fairly sensible prerequisite for all manner of other bits of
> boot.
>
> The reasons why udev takes a while to be 'done' are more interesting and
> Lennart w
JB gmail.com> writes:
> ...
The only difference to previous run is that ethernet cable (with good ISP
service) was plugged in during boot time.
You can see userspace time, and thus total time reduced by more than 300%.
# less -i /var/log/messages
...
Oct 5 05:33:51 localhost systemd[1]: Startu
On Wed, 05.10.11 11:40, Horst H. von Brand (vonbr...@inf.utfsm.cl) wrote:
>
> Lennart Poettering wrote:
>
> [Optimize boot on CD]
>
> > Optimizations like this are always thinkable, but then again spending
> > the time on optimizing CD boots sounds like a lot of time wasted on
> > yesterday's
Lennart Poettering wrote:
[Optimize boot on CD]
> Optimizations like this are always thinkable, but then again spending
> the time on optimizing CD boots sounds like a lot of time wasted on
> yesterday's technology.
Humm... for a LiveCD for forensic work (at least) it should be worthwhile,
and
On Wed, Oct 5, 2011 at 15:28, Lennart Poettering wrote:
> On Tue, 04.10.11 19:40, Adam Williamson (awill...@redhat.com) wrote:
>> On Tue, 2011-10-04 at 16:55 -0800, Jef Spaleta wrote:
>> > On Tue, Oct 4, 2011 at 3:32 PM, JB wrote:
>> > > 13837ms udev-settle.service
>> > > 11392ms plymouth-start
On Wed, 05.10.11 10:17, Horst H. von Brand (vonbr...@inf.utfsm.cl) wrote:
>
> Lennart Poettering wrote:
> > On Tue, 04.10.11 21:01, JB (jb.1234a...@gmail.com) wrote:
> > > Results interpretation.
> > > ---
> > > Knoppix won by a wide margin, while:
> > > - Knoppix having micr
On Tue, 04.10.11 19:40, Adam Williamson (awill...@redhat.com) wrote:
>
> On Tue, 2011-10-04 at 16:55 -0800, Jef Spaleta wrote:
> > On Tue, Oct 4, 2011 at 3:32 PM, JB wrote:
> > > 13837ms udev-settle.service
> > > 11392ms plymouth-start.service
> >
> >
> > if you use the plot option instead o
Lennart Poettering wrote:
> On Tue, 04.10.11 21:01, JB (jb.1234a...@gmail.com) wrote:
> > Results interpretation.
> > ---
> > Knoppix won by a wide margin, while:
> > - Knoppix having microknoppix fast-parallel boot (based on SysV/LSB scripts)
> > and DE with low resources us
On Wed, Oct 5, 2011 at 15:09, Lennart Poettering wrote:
> On Tue, 04.10.11 19:38, Adam Williamson (awill...@redhat.com) wrote:
>>
>> On Tue, 2011-10-04 at 15:53 -0800, Jef Spaleta wrote:
>> > On Tue, Oct 4, 2011 at 3:32 PM, JB wrote:
>> > > Let me append "The Blame Game".
>> > > # systemd-analyze
On Tue, 04.10.11 19:38, Adam Williamson (awill...@redhat.com) wrote:
>
> On Tue, 2011-10-04 at 15:53 -0800, Jef Spaleta wrote:
> > On Tue, Oct 4, 2011 at 3:32 PM, JB wrote:
> > > Let me append "The Blame Game".
> > > # systemd-analyze blame
> > > 32983ms livesys.service
> > > 22828ms NetworkMa
On Wed, 2011-10-05 at 07:16 +, "Jóhann B. Guðmundsson" wrote:
> On 10/05/2011 02:41 AM, Adam Williamson wrote:
> > You can try rebuilding your live image with this patch to
> > spin-kickstarts:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=739446
> >
> > to see if it makes any difference.
On 10/05/2011 02:41 AM, Adam Williamson wrote:
> You can try rebuilding your live image with this patch to
> spin-kickstarts:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=739446
>
> to see if it makes any difference. it migrates the livesys stuff to
> systemd, at least to an extent.
> --
Migra
On Tue, 2011-10-04 at 23:32 +, JB wrote:
> JB gmail.com> writes:
>
> > ...
> > Notebook 1:
> > ---
> > Lenovo TP R61i, Intel Pentium Core 2 Duo 1.86 GHZ, Intel Mobile 965GM,
> > 2 GB RAM, HD, CD-RW, sound, internal ethernet and wireless.
> >
> > F16 beta
> > average t1=3m8s
> > aver
On Tue, 2011-10-04 at 16:55 -0800, Jef Spaleta wrote:
> On Tue, Oct 4, 2011 at 3:32 PM, JB wrote:
> > 13837ms udev-settle.service
> > 11392ms plymouth-start.service
>
>
> if you use the plot option instead of blame option and produce the svg
> of the service timing you get a better feel for wh
On Tue, 2011-10-04 at 15:53 -0800, Jef Spaleta wrote:
> On Tue, Oct 4, 2011 at 3:32 PM, JB wrote:
> > Let me append "The Blame Game".
> > # systemd-analyze blame
> > 32983ms livesys.service
> > 22828ms NetworkManager.service
>
> That timing for NM is so vastly different than what I'm seeing on
Jef Spaleta gmail.com> writes:
>
> On Tue, Oct 4, 2011 at 3:32 PM, JB gmail.com> wrote:
> > Let me append "The Blame Game".
> > # systemd-analyze blame
> > 32983ms livesys.service
> > 22828ms NetworkManager.service
>
> That timing for NM is so vastly different than what I'm seeing on my
> in
On Tue, Oct 4, 2011 at 3:32 PM, JB wrote:
> 13837ms udev-settle.service
> 11392ms plymouth-start.service
if you use the plot option instead of blame option and produce the svg
of the service timing you get a better feel for what Lennart was
talking about with regard to the udev settle being pr
On Tue, Oct 4, 2011 at 3:32 PM, JB wrote:
> Let me append "The Blame Game".
> # systemd-analyze blame
> 32983ms livesys.service
> 22828ms NetworkManager.service
That timing for NM is so vastly different than what I'm seeing on my
installed F15 system. I am intrigued.
-jef
--
devel mailing lis
JB gmail.com> writes:
> ...
> Notebook 1:
> ---
> Lenovo TP R61i, Intel Pentium Core 2 Duo 1.86 GHZ, Intel Mobile 965GM,
> 2 GB RAM, HD, CD-RW, sound, internal ethernet and wireless.
>
> F16 beta
> average t1=3m8s
> average t2=10s
> ...
Let me append "The Blame Game".
# less -i /var/l
On Tue, 04.10.11 17:54, Adam Jackson (a...@redhat.com) wrote:
> On Tue, 2011-10-04 at 23:45 +0200, Lennart Poettering wrote:
>
> > Another bigger source of slowness at boot is currently Plymouth which
> > also requires synchronous settling of devices (tough it's not as bad as
> > LVM in that rega
On 10/04/2011 11:01 PM, JB wrote:
> I performed a simple home test, a comparison of startup and shutdown times of:
> - Live-CD Fedora 16 beta - systemd parallel boot, GNOME 3
> - Live-CD Knoppix 6.7.1 - microknoppix-fast-parallel-boot (based on SysV/LSB
> scripts), LXDE;
On Tue, Oct 04, 2011 at 11:59:09PM +0200, drago01 wrote:
> And *sendmail* (in my vms it takes up to 60s to start even though I
> never use it; and I it does not really make much sense on desktops).
https://fedoraproject.org/wiki/Features/NoMTA
Yeah ... I was technically the owner on that one, sup
On Tue, Oct 4, 2011 at 11:45 PM, Lennart Poettering
wrote:
> On Tue, 04.10.11 21:01, JB (jb.1234a...@gmail.com) wrote:
>
>> Results interpretation.
>> ---
>> Knoppix won by a wide margin, while:
>> - Knoppix having microknoppix fast-parallel boot (based on SysV/LSB scripts)
>>
On Tue, 2011-10-04 at 23:45 +0200, Lennart Poettering wrote:
> Another bigger source of slowness at boot is currently Plymouth which
> also requires synchronous settling of devices (tough it's not as bad as
> LVM in that regard though, but costs too since EDID probing is
> apparently quite slow, a
On Tue, 04.10.11 21:01, JB (jb.1234a...@gmail.com) wrote:
> Results interpretation.
> ---
> Knoppix won by a wide margin, while:
> - Knoppix having microknoppix fast-parallel boot (based on SysV/LSB scripts)
> and DE with low resources usage and tailored for desktops
> - Fed
Hi,
I performed a simple home test, a comparison of startup and shutdown times of:
- Live-CD Fedora 16 beta - systemd parallel boot, GNOME 3
- Live-CD Knoppix 6.7.1 - microknoppix-fast-parallel-boot (based on SysV/LSB
scripts), LXDE;
note that Kn
33 matches
Mail list logo
