splash=off doesn’t work with certain order of boot options

Forum Forums Official Releases antiX-19 “Marielle Franco, Hannie Schaft, Manolis Glezos” splash=off doesn’t work with certain order of boot options

  • This topic has 4 replies, 3 voices, and was last updated Jan 9-8:41 pm by skidoo.
Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #49282
    Member
    AvatarQwerty

    I created a custom entry in syslinux.cfg and for some reason with “disable=lxF splash=off” there’s no splash or console decoration, while with “splash=off disable=lxF” there’s still no splash, but console decoration gets enabled in the end, just before switching to X. I haven’t found any reports of this. Is it a bug?
    I’m interested in technical details too. Where is the code that parses the splash option? I tried to search, but all I found was test -d /live/config/tsplash && DO_TSPLASH=true.

    #49285
    Forum Admin
    anticapitalistaanticapitalista

    I’m not sure what you want to do.
    Do you want/or not the fbcondecor splash?
    Do you want/or not the live splasht screen to cover the boot messages?

    Philosophers have interpreted the world in many ways; the point is to change it.

    antiX with runit - leaner and meaner.

    #49338
    Member
    skidooskidoo

    Where is the code that parses the splash option? I tried to search, but

    During liveboot, the bootline parameters are ingested by the ‘init’ script during early boot.
    Unless you set a breakpoint (via antiX bootline parameter)…

    http://download.tuxfamily.org/antix/docs-antiX-19/FAQ/boot-params.html

    breakpoint 1 before welcome
    breakpoint 2 before coldplug
    breakpoint 3 before looking for linuxfs file
    breakpoint 4 after mounting boot device
    breakpoint 5 after mounting persistence device
    breakpoint 6 after mounting aufs
    breakpoint 7 before prepare switch_root
    breakpoint 8 before running init.d scripts
    breakpoint 9 right before starting init

    breakpoint F After fsck
    breakpoint F Before fsck
    breakpoint e On possibly fatal error
    breakpoint f in frugal install
    breakpoint i after init= chroot
    breakpoint m before makefs
    breakpoint r After resize homefs rsync
    breakpoint r Before resize homefs rsync
    breakpoint tr After copy to ram
    breakpoint u final umount
    breakpoint v before check VID
    breakpoint x before select device

    …you would not be able to easily find (locate) this ‘init’ file after the boot process is completed.

    On the liveboot media, early boot unpacks the contents of initrd.gz
    (see: https://gitlab.com/antiX-Linux/live-initrd.gz )
    and here init#L820 you can see (and follow the bouncing ball) where the “splasht” boot parameter is handled.
    The “splash” program also resides within the initrd.gz
    and (but) the temporary mountpoint with all the extracted stuffs is discarded (unmounted) at the tailend of the early boot stage.

    On antiX19, 2 utilities are present to assist with {unpack,view,edit,repack} managing the initrd.gz
    (which prepetually resides on the boot media as <boot-dev>/antiX/initrd.gz )

    unpack-initrd -help
    ps_initrd.sh -help

    You might be interested in using the “locate” command to lookup the full path to these utilities
    and view them in a text editor ~~ both of them are bash scripts.

    Within the initrd.gz is a cpio archive https://en.wikipedia.org/wiki/Cpio
    Such archives cannot be “updated” or appended subsequent to their initial creation.
    The aforementioned 2 utilities handle both unzipping the initrd and extracting the cpio content.

    The “live-initrd.gz” project repository at gitlab may not be the correct location to find code for the “splash” program ~~ that code might reside in a separate project repo.

    but console decoration gets enabled in the end, just before switching to X

    Prior discussion of this exists here in the forum, probably in the context of antiX19 betatesting.
    Yes, I notice same as you have described
    but
    on all the systems I manage locally, it just amounts to a momentary “blip” (1/2sec?)
    and
    during those prior discussions, developer BitJam mentioned that “for reasons” the as-seen behavior is unavoidable.

    ___________________________________________
    When requesting help, pasting the output from inxi -Fzr command will provide important relevant details:
    antiX version//edition ~~ stable vs testing repos ~~ live vs installed vs virtualbox ~~ hardware specs

    #49355
    Member
    AvatarQwerty

    Thanks. I wanted predictable behavior so that I could choose either option. The problem was that decoration turned on in the end and stayed on, but I didn’t realize that it was done by “disable=F”, so it’s OK now.
    Other than that, I have one PC where decoration messes up the console. I haven’t found anything about this issue. Where should report it?

    Attachments:
    #49486
    Member
    skidooskidoo

    Where is the code that parses the splash option?

    you would not be able to easily find (locate) this ‘init’ file after the boot process is completed.

    > but console decoration gets enabled in the end, just before switching to X.

    The details in my long post were probably moot. I neglected to consider this detail within the OP.

    /etc/rc.local
    and
    sudo grep -inr splash /etc

    These “just before switching to X” parsers (handlers) are not discarded post-post, and are not specific to liveboot ~~ they are present even in an installed-to-disk antiX system.

    That “hiccup” you described seems to match the one which was ultimately left unresolved in the old betatesting topic. If you discover a fix or workaround, please post back and share your discovery.

    ___________________________________________
    When requesting help, pasting the output from inxi -Fzr command will provide important relevant details:
    antiX version//edition ~~ stable vs testing repos ~~ live vs installed vs virtualbox ~~ hardware specs

Viewing 5 posts - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.