This confirms my fears that my bug #429616 wouldn't be fixed quickly as this is trailing for 4 years. At least here it was ranked medium while mine was ranked low.
I've investigated a bit and it seems that the culprit is in usplash.c, where the vt is opened, activated on vt8 by ioctl VT_ACTIVATE, duplicated on stdin and then closed (close(vt_fd)). Apparently this is not sufficiendt as it is detached but not deallocated. I've found a poorly documented option VT_DISALLOCATE in ioctl but it didn'work. Also adding VT_RELDISP as recommended somewhere didn help but I don't know the right sequence. The workarounds seem to be: a) set gdm.conf to start on VT9 instead of VT7 b) or hack the source code to start usplash in VT10. Mainly in usplash.c , 2 lines, and also libusplash.c for some checks (like requiring vt < 10). Also needs initramfs script to maknod 10 ttys, as it only creates the bare minimum 8... c) or simply comment out 3 lines in libusplash.c where usplash is attached to vt8. It works the same and actually can't see why the usplash is attached to a vt, there must be a reason i guess. -- splash screen does not free virtual console #8 https://bugs.launchpad.net/bugs/25547 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
