Unlike Fedora, when booting mageia, the screen flickers several time, leaving plymouth for the console, switching to the X11 console. We should do the same as Fedora and starts X11 on the first console.
Assignee: bugsquad => mageia
Blocks: (none) => 2120
OK, I can do this easily enough with a simply patch to systemd spec (to disable tty1 getty) and by changing compile arguments in plymouth package (and regenerating initrd). This then works fine for me (on GDM at least). Am I missing anything else? I get a few flickers and jumps back to text on boot all the same. I think I'll try updating plymouth to git (this is what fedora do) and enable better systemd integration which may help here....
Maybe have we little differences in the initscripts/systemd/plymouth interactions other than the tty1 vs tty7 issue
Yeah I reckon so. I'll try and dig into it.
OK, I've updated systemd and plymouth. Both are starting on tty1 now. There are still a few jumps at the initrd stage, but once plymouth starts it stays there nicely until X11. Not sure how to hide the initial stage and when e.g. intel fb takes over from the vesa fb nicely... I've not tried a fedora boot for ages so don't really know what it looks like these days or if they even hide the text output at this early stage? If they do, I guess it's a kernel option?
what about this bugreport now ?
CC: (none) => dmorganec
what about this bug with systemd 40 ?
what about this bug with systemd 44 ?
It's not so much a systemd specific problem but all the related issues. I've made the necessary changes in drakx to append the "splash" and "quiet" arguments and we now get a pretty smooth boot, so I suspect it's generally solved. Theirry has reviewed my changes in drakx (and fixed a silly bug :s) so this should all filter through soon. I think we can probably close this, but I'll let Theirry decide seeing as he opened it :)
Source RPM: systemd => drakxtools
OK, This is now released in drakxtools and I've just pushed a post script that will migrate the current grub menu.lst. We should really migrate lilo too, but I suspect usage of lilo is quite low and I cannot really test this so I can't (safely) do it. So I think this can now be closed.
Status: NEW => RESOLVEDResolution: (none) => FIXED