On Wed, Jan 22, 2014 at 02:53:51AM +0100, Andreas Cadhalpun wrote: > On 22.01.2014 01:30, j...@joshtriplett.org wrote: > >On Wed, Jan 22, 2014 at 12:53:05AM +0100, Andreas Cadhalpun wrote: > >>So you agree that it is easy enough to manually remove the 'splash' > >>boot option if you don't like it (assuming it was enabled by > >>default)? > > > >I don't see where you got that from what I said. No, I'm still arguing > >against having a splash screen by default. I was saying that two > >options potentially make sense: installing it and leaving it disabled, > >or leaving it uninstalled but having it active on install. The latter > >seems potentially easier for a novice user than the former: just install > >plymouth and you have a splash. > > Sorry that I misunderstood you. > Why do you think it would be bad to enable 'splash' by default?
Because then the splash screen would show up. :) See my previous mails in this thread; I would like to avoid having a splash screen enabled by default, in favor of keeping boot silent on success, and making it as quick as possible. > And yes, the latter option would be easier for the user, but > probably more difficult for the package maintainer. Seems rather straightforward for both, really; why would it be more difficult for the maintainer? > >>So the kernel would have to draw on the screen, before X takes over. > > > >For the text variation, yes; or, long-term, you'd use something like > >kmscon. > > > >>By the way, how can I make sure, that the kernel doesn't change the > >>video mode? > > > >Take a look at the work on i915 and "fastboot". > > Thanks for the info. I tried to use 'i915.fastboot=1', but > unfortunately this just produced: > [drm:hsw_unclaimed_reg_check] *ERROR* Unclaimed write to 68080 > [drm:hsw_unclaimed_reg_check] *ERROR* Unclaimed write to 68070 > [drm:intel_uncore_check_errors] *ERROR* Unclaimed register before interrupt > [drm:hsw_unclaimed_reg_check] *ERROR* Unclaimed write to 68074 > [drm:hsw_unclaimed_reg_check] *ERROR* Unclaimed write to 68080 > [drm:hsw_unclaimed_reg_check] *ERROR* Unclaimed write to 68070 > [drm:hsw_unclaimed_reg_check] *ERROR* Unclaimed write to 68074 > > I guess this is still in development. You probably need newer kernel bits than you have, if you're seeing those messages. > >>How can one create such a bootchart? > > > >Boot with init=/usr/lib/systemd/systemd-bootchart . > > This seems not to work for me, as I can't find any .svg's in /run/log. > I also tried 'init=/lib/systemd/systemd-bootchart' (the actual > location, this seems to be documented wrong) and this also didn't > work. That may have been fixed in more recent versions of systemd; discrepancies like that, which only matter on systems that still keep / and /usr separate, will be an ongoing issue. I don't know why you aren't seeing the files in /run/log. Do you see them in the journal? > >Happy to chat by IRC, Jabber, or email; the #systemd IRC channel and the > >upstream mailing list are also extremely helpful. > > Thanks, I'm going to send you a mail. > > >>I actually thought about the time that is called 'kernel' (in > >>contrast to 'userspace') by systemd-analyze plot. > > > >That's what I'm talking about; that should take almost no time. > > OK, the 10 seconds it takes for me include the time I need to type > the password for the encrypted partition, but subtracting that, I > think it still takes something like 5 seconds. Encryption will really throw off your numbers. If you want to do boot-time testing, you should use a test system or test partition without encryption. (Also, if you're using encryption, you're probably also using LVM, which causes major boot-time slowdowns on all distributions, and is outright broken on Debian systems. If udevadm settle is running at all in your boot path, that needs fixing.) > >>>> * ...boot in less than 5 seconds, if a particular service takes > >>>>longer than 10 seconds (e.g. clamav-daemon)? > >>> > >>>Sure, as long as gdm and X don't need clamav-daemon. > >> > >>How can I achieve that? > >>Currently it seems as if multi-user.target waits for exim4.service, > >>which starts only after clamav-daemon.service is ready. > > > >Ieally, by uninstalling exim4 and clamav-daemon; getting the MTA removed > >from standard is another big goal of mine. :) > > You're funny. ;) Thanks. I never seem to run out of windmills. :) > >But more seriously, as far as I know you just need to make sure that gdm > >doesn't depend indirectly on exim4 or clamav-daemon. > > Unfortunately, exim4 has still no unit file and I haven't (yet) been > able to create one. So analyzing/changing the (implicit) > dependencies > is not that easy. That would be a problem, yeah. - Josh Triplett -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140122020519.GB2659@leaf
