Description of problem: confusing messages from dracut Version-Release number of selected component (if applicable): dracut-002-13.4.git8f397a9b.fc12.noarch How reproducible: Upgrade to F12 from F11 on system with ext3/4 on lvm2 on crypto on raid5 and encrypted swaps. Steps to Reproduce: 1. reboot 2. pay attention to the startup messages. 3. Actual results: In the messages before I can enter the password to decrypt the lvm2 set: dracut: mdadm: /dev/md0 has been started with 4 drives. md0: unknown partition table dracut: mdadm: /dev/md0 has been started with 4 drives. dracut: luksOpen /dev/md1luks-1212223343etc dracut: luksOpen /dev/md1luks-1212223343etc Please notice the duplicate mdadm and luksOpen lines Then, later on: Enabling /etc/fstab swaps: swapon: /dev/sda4: read swap header failed: Invalid argument swapon: /dev/sdb4: read swap header failed: Invalid argument swapon: /dev/sdc4: read swap header failed: Invalid argument swapon: /dev/sdd4: read swap header failed: Invalid argument After finishing the boots we _*DO*_ have our encrypted swaps, though... Expected results: No noise. Additional info:
The message "Enabling /etc/fstab swaps:" is from rc.sysinit
I did not capure all. It went too fast. There's a few more from dracut. Basically it should stop duplicating those lines.
Also the errors from rc.sysinit are weird: it complains yet the setup of the encrypted swap succeeds. I do not recall those swap errors from F11. It just worked, silently.
Do you have AUTOSWAP set in /etc/sysconfig/init?
No. I do not think I ever touched that file: $ cat /etc/sysconfig/init # color => new RH6.0 bootup # verbose => old-style bootup # anything else => new style bootup without ANSI colors or positioning BOOTUP=color # column to start "[ OK ]" label in RES_COL=60 # terminal sequence to move to that column. You could change this # to something like "tput hpa ${RES_COL}" if your terminal supports it MOVE_TO_COL="echo -en \\033[${RES_COL}G" # terminal sequence to set color to a 'success' color (currently: green) SETCOLOR_SUCCESS="echo -en \\033[0;32m" # terminal sequence to set color to a 'failure' color (currently: red) SETCOLOR_FAILURE="echo -en \\033[0;31m" # terminal sequence to set color to a 'warning' color (currently: yellow) SETCOLOR_WARNING="echo -en \\033[0;33m" # terminal sequence to reset to the default color. SETCOLOR_NORMAL="echo -en \\033[0;39m" # default kernel loglevel on boot (syslog will reset this) LOGLEVEL=3 # Set to anything other than 'no' to allow hotkey interactive startup... PROMPT=yes # Set to 'yes' to allow probing for devices with swap signatures AUTOSWAP=no
Then that message about the swap header comes from simply 'swapon -a -e'.
It is not that simple. If we know we have a cryppttab and want to use that. Why run swapon -a -e before the processing is complete? Why bother the user with these not so functional messages? Why didn't I notice them while running F11? Why is the crypptab used, I end up with swap being encrypted, but is the rest of the startup processing not adjusted? (or has gotten maladjusted) mkinitrd et al didn't do this if F11 really didn't show this sort of messages.
swapon -a -e is well after any crypto.
(In reply to comment #6) > Then that message about the swap header comes from simply 'swapon -a -e'. And? swapon man page: -e, --ifexists Silently skip devices that do not exist. It does not mean "ignore all errors". It seems that the device exists and according to fstab there should be a swap area. We can hide all error messages, but is it good idea?
What does your fstab look like?
Then they ARE confusing: $ cat /proc/swaps Filename Type Size Used Priority /dev/mapper/swapa partition 1036184 12300 -1 /dev/mapper/swapb partition 1036184 0 -2 /dev/mapper/swapc partition 1036184 0 -3 /dev/mapper/swapd partition 1036184 0 -4 fstab: /dev/mapper/swapa swap swap defaults 0 0 /dev/mapper/swapb swap swap defaults 0 0 /dev/mapper/swapc swap swap defaults 0 0 /dev/mapper/swapd swap swap defaults 0 0 And this does not address the dracut echo issue. It is not about hiding errors but avoiding confusing messages.
(In reply to comment #11) > fstab: > /dev/mapper/swapa swap swap defaults 0 0 > /dev/mapper/swapb swap swap defaults 0 0 > /dev/mapper/swapc swap swap defaults 0 0 > /dev/mapper/swapd swap swap defaults 0 0 (In reply to comment #0) > Enabling /etc/fstab swaps: > swapon: /dev/sda4: read swap header failed: Invalid argument > swapon: /dev/sdb4: read swap header failed: Invalid argument > swapon: /dev/sdc4: read swap header failed: Invalid argument > swapon: /dev/sdd4: read swap header failed: Invalid argument Why swapon reports problems on /dev/sd?? when you have /dev/mapper/??? in your fstab? Strange. I guess your /dev/mapper/* are not symlinks. Is it really F-12? :-)
It is F12, please do not start a discussion about that. I assume the dracut double line issue is under control now that we focus on the fstab thing? (i.e.: you have enough info to fix the bug) I will try to do a reboot tomorrow and to have my camera ready with repeat mode on. (multiple pics after each other taken)
swapon sd* messages were not reproducible after some corrections. The dracut messages still appear double.
Hello, I also noticed this "double print" from "dracut", and I must say it is a bit annoying, since it is polluting the screen, potentially hiding more interesting messages. @udo, maybe you should consider to change the bug description to something more consistent, like "dracut messages are printed twice" or similar. Thanks, bye, pg
(In reply to comment #15) > @udo, maybe you should consider to change the bug description to something more > consistent, like "dracut messages are printed twice" or similar. Can do. Will try. But I still would invite people to take action sooner, quicker, etc. How can we help fix this?
Hi, one thing I noticed. The bug status is "needinfo", some some information is needed. I suspect that, until the flag is cleared, there will be no answer. Problem is, I'm not sure which information is required. bye, pg
The question is/was: How can we help fix this? I.e.: Do you need any info from me or us? Or is stuff plenty clear and can you fix the issue on your own?
I am aware of the dracut double print. Either remove "rdinfo" or add "quiet" to prevent those for now.
dracut-004-4.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/dracut-004-4.fc12
dracut-004-4.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update dracut'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-1088
dracut-004-4.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.