Hi , when i boot my gentoo system , and if splash was set to silent , i'd like to type in my password without pressing "ALT+F1" to switch back to verbose mode , so i make a diff against initrd.scripts , which aimed to support auto switching splash mode. Reproducible: Always --- /usr/share/genkernel/defaults/initrd.scripts-bak 2010-12-21 19:59:22.544162192 +0800 +++ /usr/share/genkernel/defaults/initrd.scripts 2010-12-21 20:37:22.329200463 +0800 @@ -1,6 +1,7 @@ #!/bin/ash . /etc/initrd.defaults +. /etc/initrd.splash backup() { echo -ne "\033[0G\033[0K" @@ -600,6 +601,8 @@ done good_msg "Scanning for Volume Groups" + splash set_msg "Scanning for Volume Groups ... " + /bin/vgscan --ignorelockingfailure --mknodes 2>/dev/null sleep 2 good_msg "Activating Volume Groups" @@ -680,6 +683,9 @@ # It is either the root or a swap, other devices are supported in the scripts provided with sys-fs/cryptsetup-luks # $1 - root/swap openLUKS() { + # Switch back to VERBOSE + grep -q "splash=silent" /proc/cmdline &>/dev/null && splash verbose + # please use 'tr' and this line, or remove it # eval local TYPE=`uppercase $1` @@ -834,6 +840,9 @@ REAL_RESUME="/dev/mapper/swap" fi fi + + # Should we switch back to verbose mode ? + grep -q "splash=silent" /proc/cmdline &>/dev/null && splash set_msg 'Loading BlackTux 4 .. Please wait ;-)' } sdelay() {
Created attachment 257674 [details, diff] Newest patch Please ignore last patch posted as clear text , i'm so sorry for it !
PS: Adding keyword "Inclusion" and "[patch] " prefix to better show this bug's nature in searches...
So here we got two patches in one, which should be two bugreports. The first part is tuning messages for splash. I all for that, but we may want to split that out. The second part is questionable in some ways. The biggest question is if this patch does the correct thing. There are setups where I have LUKS but do not need a password prompt. If I have one of those I can set 'crypt_silent' in my kernelcmd, and the splash should never bee turned off. However if I do not have 'crypt_silent' in my kernelcmd, and the password prompt does no show up, then that is a bug and should really be handled in a better way then disabling splash for all. Or have I misunderstood something?
Yes , you missed something. Did you put "Encrypted Root" into consideration ? I got one. Thus without correct passphrase , one can't enter my system. In that case , this behavior is required. See encrypted_root=XXX parameter , we could get to know if user specified a encrypted root by that , what do you think ;-P
Think about this here's my story , you power on your machine , set splash to silent with grub. When you boot , since you root is encrypted , in RamDisk , "cryptsetup" will ask you for passphrase to decrypt your storage , but your splash is in silent mode , you don't know what happened , just wait and hang. Until you press ALT+F2 to get rid of splash , you suddenly found it's just waiting for user input , what is that ? Absolutely unnecessary , why shouldn't RamDisk switch off splash for a while , and switch it on later when your storage is initialized ? It will surely be cool. That's why i put a bug report here , hope you guys can adopt this ;-P
(In reply to comment #4) > Yes , you missed something. > > Did you put "Encrypted Root" into consideration ? Oh, I *did*. There is a function[1] that does only one thing, and has only one use: cryptfilter(). This function takes a command as an argument, and if crypt_silent is *not* set, it runs "splash 'verbose'", and then runs the command (and thus you should be kicked to console and see the password prompt) and if the command exists with returncode 0 (success) it enables the splash again. As cryptsetup is called[2] as an argument to this function then splash should be *disabled* as long as you do *not* have crypt_silent on your kernelcmd automagically right before the passwordprompt. If the ramdisk does not act in this way, there is a bug somewhere in the init scripts in the ramdisk, which should be fixed, not workaround by disabling splash for everyone using openLUKS(). And, yes. These are the function that are supposed to unlock ROOT in the ramdisk (and I can have a ekayfile on a USB-stick which is used to unluck my ROOT, and in that case I do *not* want splash to be disabled). [1] http://git.overlays.gentoo.org/gitweb/?p=proj/genkernel.git;a=blob;f=defaults/initrd.scripts;h=f7f01dedddddbd5bbc8fa94641b248cc1b95ad5e;hb=HEAD#l366 [2] http://git.overlays.gentoo.org/gitweb/?p=proj/genkernel.git;a=blob;f=defaults/initrd.scripts;h=f7f01dedddddbd5bbc8fa94641b248cc1b95ad5e;hb=HEAD#l893 I guess I have to set up a virtual machine to test this...
(In reply to comment #5) > why shouldn't > RamDisk switch off splash for a while , and switch it on later when your > storage is initialized ? It will surely be cool. To make it even more clear, this should already be the case with at least genkerel-3.4.13 (probably also with earlier versions). If you do not have crypt_silent in grub.conf/menu.lst then slash should be turned off right before the password prompt, and turned on again as soon as cryptsetup exists. Could you please provide your kernelcmd (i.e. the "kernel" line from your grub.conf/menu.lst), tell us what version of genkernel you are using, what version of splashutils and with what USE-flags, what version of cryptsetup and with what USE-flags and any other info you may have that may influesne why the ramdisk does not work like it should do already for you.
I think this bug could be closed now. For my bad , i masked all higher versions of genkernel , and i checked out genkernel-3.4.13 today , recreate RamDisk , and this problem has already been properly cared. Sorry for the noise i created.
