Announcement

Collapse
No announcement yet.

Enabling Intel Fastboot Support By Default Brought Up, Again

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Djhg2000
    replied
    Originally posted by Sloth View Post

    I didn't care (still don't, really), but I do care about boot speed and shutting down all the messages and fastbooting made a very noticeable difference in that. So I guess it's worth it? I didn't even mess with plymouth - no time for that to be of any value. It's just BIOS, then black for a fraction of a second, then SDDM.
    Sure, but disabling messages has worked for speeding up the boot process for ages. It even worked on the HDD based laptop I used in 2006, although obviously the net gain was smaller.

    Leave a comment:


  • Sloth
    replied
    Originally posted by Djhg2000 View Post
    Am I the only one who don't care about the screen chainging modes during boot?
    I didn't care (still don't, really), but I do care about boot speed and shutting down all the messages and fastbooting made a very noticeable difference in that. So I guess it's worth it? I didn't even mess with plymouth - no time for that to be of any value. It's just BIOS, then black for a fraction of a second, then SDDM.

    Leave a comment:


  • caligula
    replied
    Originally posted by dwagner View Post
    I'm still baffled so much effort is being invested in beautifying boot screen output. Which is output rarely seen on stable systems, and seriously, why should I bother if some boot status output looks nicely? It's not like its more than a few seconds to be seen, anyway.
    Maybe a vendor wants to show a splash screen without flicker?

    Leave a comment:


  • Djhg2000
    replied
    Originally posted by Britoid View Post

    It's more that it's stupid that the mode is set multiple times during a boot process, when it shouldn't.

    Wasted time and wasted power.
    Wasted time? My Debian machines keep booting while my monitor does the flickering. I know because my tiny Chinese secondary monitor is dumb as a rock and shows everything, even the corrupted half-synced frames. I can see the kernel messages whizzing by while my main monitor blanks out for a full second.

    Wasted power? I don't know. Maybe. But the rest of the computer will probably dwarf any reasonably sized monitor during the boot process.

    In either case at least one mode switch is unavoidable in my case. My monitor EDID defaults to 60 Hz, which means somewhere between the UEFI logo and the desktop it needs to perform the switch to 144 Hz. There is literally no way to get to the mode I want without a mode switch. If you cut out that critical mode switch you can be sure I'll file a bug report.

    Leave a comment:


  • Britoid
    replied
    Originally posted by Djhg2000 View Post
    Am I the only one who don't care about the screen chainging modes during boot?
    It's more that it's stupid that the mode is set multiple times during a boot process, when it shouldn't.

    Wasted time and wasted power.

    Leave a comment:


  • Djhg2000
    replied
    Am I the only one who don't care about the screen chainging modes during boot?

    Leave a comment:


  • dwagner
    replied
    I'm still baffled so much effort is being invested in beautifying boot screen output. Which is output rarely seen on stable systems, and seriously, why should I bother if some boot status output looks nicely? It's not like its more than a few seconds to be seen, anyway.

    Leave a comment:


  • Sloth
    replied
    Originally posted by debianxfce View Post

    You need some entropy filler (see arch wiki), otherwise you must move the mouse or type with the keyboard to get boot going forward faster. The stupid kernel random number generator with systemd waiting causes this. I have zero messages in console, just one display mode change distortion line and one brightness change before the Xfce desktop is visible. Booting from the bios message to the desktop takes 10 seconds and it is the same time that I had several years earlier with much slower hardware. Systemd has bloated internally, the systemd-analyze dot command shows millions of services.
    Not seeing that here. Same boot time with and without haveged, not touching the mouse or keyboard.

    Leave a comment:


  • Sloth
    replied
    Originally posted by debianxfce View Post

    Lightdm is started at end of the process, so it is systemd required haveged.service that cause flashing at early boot.
    I uninstalled haveged, FWIW.

    You should also be able to suppress console output by adding this:

    Code:
    StandardOutput=null
    StandardError=journal+console
    in the [Service] section of the haveged service file.
    Last edited by Sloth; 17 December 2018, 02:47 PM. Reason: Formatting

    Leave a comment:


  • AsuMagic
    replied
    Originally posted by debianxfce View Post

    It is systemd that causes flashing with its randomness entropy filling shit. No wonder fedora is so interested to hide it.
    Code:
    graphical.target @798ms
    └─lightdm.service @698ms +100ms
    └─systemd-user-sessions.service @694ms +2ms
    └─network.target @693ms
    └─wicd.service @572ms +120ms
    └─basic.target @568ms
    └─sockets.target @568ms
    └─dbus.socket @568ms
    └─sysinit.target @568ms
    └─systemd-timesyncd.service @266ms +301ms
    └─systemd-tmpfiles-setup.service @251ms +13ms
    └─local-fs.target @250ms
    └─media-ssd.mount @242ms +6ms
    └─dev-disk-by\x2duuid-9e9d5167\x2d3dc9\x2d4e9d\x2db39e\x
    Code:
    [email protected]:~$ systemd-analyze time
    Startup finished in 1.993s (kernel) + 803ms (userspace) = 2.797s
    graphical.target reached after 798ms in userspace
    Are you using lightdm? If so, it's not systemd's fault but lightdm's, because it requires entropy.

    Leave a comment:

Working...
X