May 2015 - test - Fedora Mailing-Lists

by David St.Clair

This may be a dumb question, but why can't Redhat distribute NVIDIA binary drivers? In NVIDIA's licence (http://www.nvidia.com/object/nv_swlicense.html) it says: "2.1.2 Linux Exception. Notwithstanding the foregoing terms of Section 2.1.1, SOFTWARE designed exclusively for use on the Linux operating system may be copied and redistributed, provided that the binary files thereof are not modified in any way (except for unzipping of compressed files)." So, what's keeping RedHat from putting the drivers in the distribution? If it's a GPL thing, would it be easy to just download it during installation or at least give the option to the user? Thanks, -- David St.Clair dstclair(a)cs.wcu.edu

1 year, 8 months

10
20
0 / 0

Mouse goes crazy

by Jonathan Villa

Ok, I have had Yarrow working well for a while now, but yesterday I started experiencing some odd issues with my mouse. All of a sudden it stops working correctly. The only thing that seems to fix is to kill X and run mouse-test, then restart. Any ideas? Also, I have FC 1 running on a desktop which is hooked up to a KVM switch. Whenever I go to another PC, and return, the same thing happens, the mouse goes crazy. ???

1 year, 8 months

8
7
0 / 0

[Fedora QA] #472: create testcase for resizing in custom partitioning

by fedora-badges

#472: create testcase for resizing in custom partitioning ------------------------+------------------------ Reporter: kparal | Owner: Type: task | Status: new Priority: major | Milestone: Fedora 22 Component: Test cases | Version: Keywords: | Blocked By: Blocking: | ------------------------+------------------------ After discovering https://bugzilla.redhat.com/show_bug.cgi?id=1221247 it seems reasonable we should test this more properly in the future. Currently we seem to have no test case about resizing partitions in manual part dialog. We probably should, and test it against at least a standard partition and a logical volume. Optionally, we can split standard partitions into ext4 and ntfs, to cover similar use cases as in our QA:Testcase_partitioning_guided_shrink . -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/472> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

7 years, 1 month

1
3
0 / 0

Re: digikam and kipi-plugins?

by Rex Dieter

Per Bothner wrote: > The Rawhide version of digikam is the very latest (0.10.0-rc1), > but it fails to find any of the "Kipi plugins", even though I've > installed the kipi-plugins package. This might be an upstream > issue, since 0.10.0 is pretty bleeding edge and the kipi-plugins > may even more bleeding-edge. Gwenview does seem to be see the > plugins, so I'm wondering if there is there might be a > Fedora-specific problem before I complain upstream ... The f10 builds seem to work fine for me (finding the plugins), so perhaps this is rawhide-specific? To be clear, digikam's Settings -> configure digikam -> Kipi Plugins is empty? -- Rex

7 years, 10 months

2
1
0 / 0

Re: rawhide report: 20050419 changes

by Ray Strode

Hi, > Will yelp in FC4 be able to search and display man/info pages Yea, man and info pages work for me. --Ray

7 years, 10 months

2
2
0 / 0

Mouse Wheel gone

by Christian Menzel

Since the latest xorg-X11 upgrade I receive the already mentioned XKB error and the mouse wheel is not working anymore. Has anybody seen this behavior? Regards Chris

7 years, 10 months

3
3
0 / 0

Re: NFS failure

by Fulko.Hew＠sita.aero

Damian Menscher <menscher(a)uiuc.edu>@redhat.com on 04/07/2004 04:57:13 PM wrote: > On Wed, 7 Apr 2004, Jeff Elkins wrote: > > > I'm getting failure messages on my nfs mounts i.e. : > > > > mount to NFS server 'music.elkins' failed: server is down. > > > > nsfd appears to be running and I didn't see anything suspicious in the logs. > > The servers are up and running and have other clients connected. > > You didn't mention what steps you took to debug it: > > Can you ping the server? > What is the output of rpcinfo -p servername? > Does the server have access restrictions (firewall, TCP Wrappers, etc)? I have the same symptoms... rpcinfo says that nfs et.al. are running. Something has changed in test 2, since the same PC running RH9 accesses that host just fine.

7 years, 10 months

7
9
0 / 0

NAT isn't working in qemu-kvm VM

by Chris Murphy

This has been working this whole test cycle until today and now I'm stumped that it's not working. Host = Fedora 22 up to date, x86_64 Guest = managed by virt-manager, also Fedora 22 1. Install Fedora 22 on the host 2. dnf group install virtualization 3. reboot [1] to get the NAT option for the VM 4. Create a VM and use the default network settings which uses NAT Actual results: - Guest has no Internet access. - host (192.168.1.128) can't ssh to guest (192.168.122.103) # ssh root(a)192.168.122.103 ssh: connect to host 192.168.122.103 port 22: No route to host - Guest can ssh into the host, i.e. # ssh root(a)192.168.1.128 On the host: [root@f22m]# ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp2s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether c8:2a:14:02:88:99 brd ff:ff:ff:ff:ff:ff 3: wlp3s0b1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether e0:f8:47:39:5d:de brd ff:ff:ff:ff:ff:ff inet 192.168.1.128/24 brd 192.168.1.255 scope global dynamic wlp3s0b1 valid_lft 84895sec preferred_lft 84895sec inet6 fe80::e2f8:47ff:fe39:5dde/64 scope link valid_lft forever preferred_lft forever 4: virbr0@NONE: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 52:54:00:dd:30:37 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever 5: virbr0-nic@NONE: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 500 link/ether 52:54:00:dd:30:37 brd ff:ff:ff:ff:ff:ff 7: vnet0@NONE: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master virbr0 state UNKNOWN group default qlen 500 link/ether fe:54:00:6d:40:9e brd ff:ff:ff:ff:ff:ff inet6 fe80::fc54:ff:fe6d:409e/64 scope link valid_lft forever preferred_lft forever On the guest: [root@f22v]# ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:6d:40:9e brd ff:ff:ff:ff:ff:ff inet 192.168.122.103/24 brd 192.168.122.255 scope global dynamic ens8 valid_lft 3198sec preferred_lft 3198sec inet6 fe80::5054:ff:fe6d:409e/64 scope link valid_lft forever preferred_lft forever 3: virbr0@NONE: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN group default link/ether 52:54:00:25:45:a5 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever 4: virbr0-nic@NONE: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 500 link/ether 52:54:00:25:45:a5 brd ff:ff:ff:ff:ff:ff Previously, Virtual Network Interface Device model was set to virtio and that was working but isn't now, so I flipped it to hypervisor default and when I click apply the setting snaps to rtl8139. But this doesn't change things. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1224398 -- Chris Murphy

8 years, 3 months

2
1
0 / 0

[Test-Announce] Fedora 22 Final Release Candidate 2 (RC2) Available Now!

by Mike Ruckman

As per the Fedora 22 schedule [1], Fedora 22 Final Release Candidate 2 (RC2) is now available for testing. Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/6166#comment:12. Please see the following pages for download links and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download-ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace "dl" with "download-ib01" in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Workstation and Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Server: https://fedoraproject.org/wiki/Test_Results:Current_Server_Test Cloud: https://fedoraproject.org/wiki/Test_Results:Current_Cloud_Test Summary: https://fedoraproject.org/wiki/Test_Results:Current_Summary All Final priority test cases for each of these test pages [2] must pass in order to meet the Final Release Criteria [3]. Help is available on #fedora-qa on irc.freenode.net [4], or on the test list [5]. Create Fedora 22 Final test compose (TC) and release candidate (RC) https://fedorahosted.org/rel-eng/ticket/6166 Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-22/f-22-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan [3] https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria [4] irc://irc.freenode.net/fedora-qa [5] https://admin.fedoraproject.org/mailman/listinfo/test -- // Mike -- Fedora QA freenode: roshi http://roshi.fedorapeople.org _______________________________________________ test-announce mailing list test-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce

8 years, 3 months

5
4
0 / 0

Re: Update FC22 - doesn't find root fs and doesn't boot

by poma

On 28.05.2015 14:19, Gerhard Wiesinger wrote: > On 27.05.2015 15:27, Harald Hoyer wrote: >> Am 27.05.2015 um 15:21 schrieb Gerhard Wiesinger: >>> On 27.05.2015 15:07, Harald Hoyer wrote: >>>> Am 27.05.2015 um 15:03 schrieb Gerhard Wiesinger: >>>>> On 27.05.2015 14:43, Harald Hoyer wrote: >>>>>> Am 27.05.2015 um 14:39 schrieb Gerhard Wiesinger: >>>>>>> On 27.05.2015 14:25, Harald Hoyer wrote: >>>>>>>> Am 27.05.2015 um 14:13 schrieb Andrei Borzenkov: >>>>>>>>> On Wed, May 27, 2015 at 3:09 PM, Gerhard Wiesinger <lists(a)wiesinger.com> >>>>>>>>> wrote: >>>>>>>>>> On 27.05.2015 13:56, Harald Hoyer wrote: >>>>>>>>>>> Am 27.05.2015 um 13:28 schrieb Gerhard Wiesinger: >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> After upgrading one machine it does't boot anymore. Booting the old >>>>>>>>>>>> kernel >>>>>>>>>>>> works well. >>>>>>>>>>>> >>>>>>>>>>>> It is a RAID, LUKS, LVM setup. Find relevant details below. >>>>>>>>>>>> >>>>>>>>>>>> So it looks RAID assembling doesn't work any more. >>>>>>>>>>>> >>>>>>>>>>>> Any ideas? >>>>>>>>>>>> >>>>>>>>>>>> Thank you. >>>>>>>>>>>> >>>>>>>>>>>> Ciao, >>>>>>>>>>>> Gerhard >>>>>>>>>>>> >>>>>>>>>>>> blkid >>>>>>>>>>>> /dev/sda1: UUID="56e9bde4-5cd1-630d-188c-22a54c1c8c37" >>>>>>>>>>>> TYPE="linux_raid_member" >>>>>>>>>>>> PARTUUID="5ec6792c-01" >>>>>>>>>>>> /dev/sdb1: UUID="56e9bde4-5cd1-630d-188c-22a54c1c8c37" >>>>>>>>>>>> TYPE="linux_raid_member" >>>>>>>>>>>> PARTUUID="1c7cffaf-01" >>>>>>>>>>>> /dev/sdc1: UUID="56e9bde4-5cd1-630d-188c-22a54c1c8c37" >>>>>>>>>>>> TYPE="linux_raid_member" >>>>>>>>>>>> PARTUUID="0079dfc3-01" >>>>>>>>>>>> /dev/sdd1: UUID="eb295015-e20b-e133-15db-5c9130487300" >>>>>>>>>>>> TYPE="linux_raid_member" >>>>>>>>>>>> PARTUUID="fadeaffe-01" >>>>>>>>>>>> /dev/sde1: UUID="eb295015-e20b-e133-15db-5c9130487300" >>>>>>>>>>>> TYPE="linux_raid_member" >>>>>>>>>>>> PARTUUID="539b5814-01" >>>>>>>>>>>> /dev/sdf1: UUID="eb295015-e20b-e133-15db-5c9130487300" >>>>>>>>>>>> TYPE="linux_raid_member" >>>>>>>>>>>> PARTUUID="badeaffe-01" >>>>>>>>>>>> /dev/sdh1: UUID="51e8e983-8786-b868-dbc3-87357e1a9534" >>>>>>>>>>>> TYPE="linux_raid_member" >>>>>>>>>>>> PARTUUID="15631562-01" >>>>>>>>>>>> /dev/sdg1: UUID="51e8e983-8786-b868-dbc3-87357e1a9534" >>>>>>>>>>>> TYPE="linux_raid_member" >>>>>>>>>>>> PARTUUID="162f0d0b-01" >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> blkid -o udev >>>>>>>>>>>> ID_FS_UUID=56e9bde4-5cd1-630d-188c-22a54c1c8c37 >>>>>>>>>>>> ID_FS_UUID_ENC=56e9bde4-5cd1-630d-188c-22a54c1c8c37 >>>>>>>>>>>> ID_FS_TYPE=linux_raid_member >>>>>>>>>>>> ID_FS_PARTUUID=5ec6792c-01 >>>>>>>>>>>> >>>>>>>>>>>> ID_FS_UUID=56e9bde4-5cd1-630d-188c-22a54c1c8c37 >>>>>>>>>>>> ID_FS_UUID_ENC=56e9bde4-5cd1-630d-188c-22a54c1c8c37 >>>>>>>>>>>> ID_FS_TYPE=linux_raid_member >>>>>>>>>>>> ID_FS_PARTUUID=1c7cffaf-01 >>>>>>>>>>>> >>>>>>>>>>>> ID_FS_UUID=56e9bde4-5cd1-630d-188c-22a54c1c8c37 >>>>>>>>>>>> ID_FS_UUID_ENC=56e9bde4-5cd1-630d-188c-22a54c1c8c37 >>>>>>>>>>>> ID_FS_TYPE=linux_raid_member >>>>>>>>>>>> ID_FS_PARTUUID=0079dfc3-01 >>>>>>>>>>>> >>>>>>>>>>>> ID_FS_UUID=eb295015-e20b-e133-15db-5c9130487300 >>>>>>>>>>>> ID_FS_UUID_ENC=eb295015-e20b-e133-15db-5c9130487300 >>>>>>>>>>>> ID_FS_TYPE=linux_raid_member >>>>>>>>>>>> ID_FS_PARTUUID=fadeaffe-01 >>>>>>>>>>>> >>>>>>>>>>>> ID_FS_UUID=eb295015-e20b-e133-15db-5c9130487300 >>>>>>>>>>>> ID_FS_UUID_ENC=eb295015-e20b-e133-15db-5c9130487300 >>>>>>>>>>>> ID_FS_TYPE=linux_raid_member >>>>>>>>>>>> ID_FS_PARTUUID=539b5814-01 >>>>>>>>>>>> >>>>>>>>>>>> ID_FS_UUID=eb295015-e20b-e133-15db-5c9130487300 >>>>>>>>>>>> ID_FS_UUID_ENC=eb295015-e20b-e133-15db-5c9130487300 >>>>>>>>>>>> ID_FS_TYPE=linux_raid_member >>>>>>>>>>>> ID_FS_PARTUUID=badeaffe-01 >>>>>>>>>>>> >>>>>>>>>>>> ID_FS_UUID=51e8e983-8786-b868-dbc3-87357e1a9534 >>>>>>>>>>>> ID_FS_UUID_ENC=51e8e983-8786-b868-dbc3-87357e1a9534 >>>>>>>>>>>> ID_FS_TYPE=linux_raid_member >>>>>>>>>>>> ID_FS_PARTUUID=15631562-01 >>>>>>>>>>>> >>>>>>>>>>>> ID_FS_UUID=51e8e983-8786-b868-dbc3-87357e1a9534 >>>>>>>>>>>> ID_FS_UUID_ENC=51e8e983-8786-b868-dbc3-87357e1a9534 >>>>>>>>>>>> ID_FS_TYPE=linux_raid_member >>>>>>>>>>>> ID_FS_PARTUUID=162f0d0b-01 >>>>>>>>>>>> >>>>>>>>>>>> [ 2.479836] myhost systemd[1]: Device >>>>>>>>>>>> dev-disk-by\x2did-usb\x2dUSBDisk_RunDisk_ABCDEFGH\x2d0:0.device appeared >>>>>>>>>>>> twice >>>>>>>>>>>> with different sysfs paths /sys >>>>>>>>>>>> >>>>>>>>>>>> /devices/pci0000:00/0000:00:04.1/usb2/2-5/2-5:1.0/host9/target9:0:0/9:0:0:0/block/sdh >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> and /sys/devices/pci0000:00/0000:00:02.1/usb1/1-5/1-5:1.0/host8/target >>>>>>>>>>>> 8:0:0/8:0:0:0/block/sdg >>>>>>>>>>>> [ 2.500826] myhost systemd[1]: Device >>>>>>>>>>>> dev-disk-by\x2did-usb\x2dUSBDisk_RunDisk_ABCDEFGH\x2d0:0\x2dpart1.device >>>>>>>>>>>> appeared twice with different sysfs p >>>>>>>>>>>> aths >>>>>>>>>>>> >>>>>>>>>>>> /sys/devices/pci0000:00/0000:00:04.1/usb2/2-5/2-5:1.0/host9/target9:0:0/9:0:0:0/block/sdh/sdh1 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> and /sys/devices/pci0000:00/0000:00:02.1/usb1/1-5/1-5:1. >>>>>>>>>>>> 0/host8/target8:0:0/8:0:0:0/block/sdg/sdg1 >>>>>>>>>>>> [ 2.632754] myhost kernel: Switched to clocksource tsc >>>>>>>>>>>> [ 91.162986] myhost systemd[1]: Job dev-md0.device/start timed out. >>>>>>>>>>>> [ 91.163138] myhost systemd[1]: Timed out waiting for device >>>>>>>>>>>> dev-md0.device. >>>>>>>>>>>> [ 91.163251] myhost systemd[1]: Dependency failed for Cryptography >>>>>>>>>>>> Setup for >>>>>>>>>>>> luks-md0. >>>>>>>>>>>> [ 91.163360] myhost systemd[1]: Dependency failed for >>>>>>>>>>>> dev-mapper-luks\x2dmd0.device. >>>>>>>>>>>> [ 91.163474] myhost systemd[1]: Job >>>>>>>>>>>> dev-mapper-luks\x2dmd0.device/start >>>>>>>>>>>> failed with result 'dependency'. >>>>>>>>>>>> [ 91.163586] myhost systemd[1]: Dependency failed for Encrypted >>>>>>>>>>>> Volumes. >>>>>>>>>>>> [ 91.163694] myhost systemd[1]: Job cryptsetup.target/start failed >>>>>>>>>>>> with >>>>>>>>>>>> result 'dependency'. >>>>>>>>>>>> [ 91.163801] myhost systemd[1]: Job >>>>>>>>>>>> systemd-cryptsetup(a)luks\x2dmd0.service/start failed with result >>>>>>>>>>>> 'dependency'. >>>>>>>>>>>> [ 91.163910] myhost systemd[1]: Job dev-md0.device/start failed with >>>>>>>>>>>> result >>>>>>>>>>>> 'timeout'. >>>>>>>>>>>> [ 91.164021] myhost systemd[1]: Reached target System Initialization. >>>>>>>>>>>> [ 91.164129] myhost systemd[1]: Starting System Initialization. >>>>>>>>>>>> [ 91.164236] myhost systemd[1]: Reached target Basic System. >>>>>>>>>>>> [ 91.164346] myhost systemd[1]: Starting Basic System. >>>>>>>>>>>> [ 185.740238] myhost dracut-initqueue[340]: Warning: Could not boot. >>>>>>>>>>>> [ 185.741266] myhost systemd[1]: Received SIGRTMIN+20 from PID 341 >>>>>>>>>>>> (plymouthd). >>>>>>>>>>>> [ 185.841257] myhost dracut-initqueue[340]: Warning: >>>>>>>>>>>> /dev/VolGroup00/root does >>>>>>>>>>>> not exist >>>>>>>>>>>> [ 185.841403] myhost systemd[1]: Starting Dracut Emergency Shell... >>>>>>>>>>>> [ 185.859366] myhost systemd[1]: Received SIGRTMIN+21 from PID 341 >>>>>>>>>>>> (plymouthd). >>>>>>>>>>>> >>>>>>>>>>>> dracut:/# cat "/run/initramfs/rdsosreport.txt" >>>>>>>>>>>> + cat /lib/dracut/dracut-041-10.fc22.1 >>>>>>>>>>>> dracut-041-10.fc22.1 >>>>>>>>>>>> + cat /proc/cmdline >>>>>>>>>>>> BOOT_IMAGE=/vmlinuz-4.0.4-301.fc22.x86_64 root=/dev/VolGroup00/root ro >>>>>>>>>>>> quiet >>>>>>>>>>>> console=ttyS0,115200n8 rd_NO_PLYMOUTH SYSFONT=latarcyrheb-sun16 >>>>>>>>>>>> LANG=en_US.UTF- >>>>>>>>>>>> 8 KEYTABLE=de-latin1 >>>>>>>>>>> your kernel cmdline seems to be missing the raid configuration >>>>>>>>>>> >>>>>>>>>>> rd.md.uuid=56e9bde4-5cd1-630d-188c-22a54c1c8c37 >>>>>>>>>>> rd.md.uuid=eb295015-e20b-e133-15db-5c9130487300 >>>>>>>>>>> rd.md.uuid=51e8e983-8786-b868-dbc3-87357e1a9534 >>>>>>>>>>> >>>>>>>>>>> ... whatever is needed to boot your system. >>>>>>>>>>> >>>>>>>>>>> # dracut --print-cmdline >>>>>>>>>>> >>>>>>>>>>> should tell you what kernel cmdline parameters are needed >>>>>>>>>> Thank you for the fast reply. >>>>>>>>>> >>>>>>>>>> # comment: 3 separate lines!!!!! (maybe a problem) >>>>>>>>>> dracut --print-cmdline >>>>>>>>>> rd.luks.uuid=luks-0c66fc77-a8a0-49e6-b96c-55e886a91f09 >>>>>>>>>> rd.lvm.lv=VolGroup00/root >>>>>>>>>> rd.lvm.lv=VolGroup00/swap >>>>>>>>>> rd.md.uuid=51e8e983:8786b868:dbc38735:7e1a9534 >>>>>>>>>> rd.md.uuid=56e9bde4:5cd1630d:188c22a5:4c1c8c37 >>>>>>>>>> resume=/dev/mapper/VolGroup00-swap root=/dev/mapper/VolGroup00-root >>>>>>>>>> rootflags=rw,relatime,data=ordered rootfstype=ext4 >>>>>>>>>> >>>>>>>>>> dracut --force 4.0.4-301.fc22.x86_64 >>>>>>>>>> >>>>>>>>>> Still no correct entry in /etc/grub2.cfg >>>>>>>>> I would be very surprised if dracut made any changes to grub.cfg. As I >>>>>>>>> understand it, you either build host-specific dracut that will include >>>>>>>>> this emulated command line or you have to add lines manually to your >>>>>>>>> boot loader configuration. >>>>>>>>> >>>>>>>>>> linux16 /vmlinuz-4.0.4-301.fc22.x86_64 root=/dev/VolGroup00/root ro quiet >>>>>>>>>> console=ttyS0,115200n8 rd_NO_PLYMOUTH SYSFONT=latarcyrheb-sun16 >>>>>>>>>> LANG=en_US.UTF-8 KEYTABLE=de-latin1 >>>>>>>>>> >>>>>>>>>> Looks like a bug to me. >>>>>>>> You have to add the options manually to the grub conf and all in the same >>>>>>>> line. >>>>>>>> >>>>>>>> dracut does not modify your grub configuration. >>>>>>> OK, I thought it was modifying it, at least in the past. >>>>>>> >>>>>>> Added it manually and it worked well. >>>>>>> >>>>>>> What's still strange: >>>>>>> >>>>>>> Last lines after startup, luks-md0 has already been started as the root fs is >>>>>>> there .... >>>>>>> Starting Cryptography Setup for luks-md0... >>>>>>> Starting Authorization Manager... >>>>>>> >>>>>>> Fedora release 22 (Twenty Two) >>>>>>> Kernel 4.0.4-301.fc22.x86_64 on an x86_64 (ttyS0) >>>>>>> >>>>>>> # Rebooting, why is a passphrase necessary here? >>>>>>> reboot >>>>>>> Please enter passphrase for disk luks-md0! >>>>>>> >>>>>>> Possible bug here? >>>>>>> >>>>>>> Ciao, >>>>>>> Gerhard >>>>>>> >>>>>> Did you add " rd.luks.uuid=luks-0c66fc77-a8a0-49e6-b96c-55e886a91f09 " also? >>>>> Yes, of course. :-) >>>>> >>>>>> What is your /etc/crypttab ? >>>>> cat /etc/crypttab >>>>> luks-md0 /dev/md0 none >>>>> luks-md1 /dev/md1 /etc/crypto-key-md1 >>>>> >>>>> BTW: Why did it work in previous versions without the long command line and >>>>> predefined "hint" parameters? >>>>> >>>>> Ciao, >>>>> Gerhard >>>>> >>>> Oh... please, please do not use kernel names like "md0" ... better use UUID= >>> >>> changed it, but didn't help. This machine was updated since around FC5. :-) >>> >>> Booting: >>> [FAILED] Failed to start Cryptography Setup for luks-md0. >>> See "systemctl status 'systemd-cryptsetup(a)luks\x2dmd0.service'" for details. >>> [DEPEND] Dependency failed for Encrypted Volumes. >>> ... >>> [FAILED] Failed to start Cryptography Setup for luks-md0. >>> See "systemctl status 'systemd-cryptsetup(a)luks\x2dmd0.service'" for details. >>> [DEPEND] Dependency failed for Encrypted Volumes. >>> ... >>> Starting Cryptography Setup for luks-md0... >>> Starting Authorization Manager... >>> >>> Fedora release 22 (Twenty Two) >>> >>> cat /etc/crypttab >>> luks-md0 UUID="0c66fc77-a8a0-49e6-b96c-55e886a91f09" none >>> luks-md1 UUID="aaa6ec1e-e54f-4864-a793-cc95d5fa59d2" /etc/crypto-key-md1 >>> >>> Ciao, >>> Gerhard >>> >> Does "dracut -f" help to get the update crypttab in the initramfs? >> >> > > Removing quotes from the UUID helped. > > Thank you. > > Ciao, > Gerhard > Without even mention these UUIDs spaghetti. $ grep ^kernel /etc/dracut.conf.d/custom.conf kernel_cmdline="rd.auto=1" # lsinitrd -f $ lsinitrd -f etc/cmdline.d/01-default.conf rd.auto=1 This is -not- necessary for MD/RAID setups on Fedora 21: $ rpm -q dracut dracut-038-39.git20150518.fc21.x86_64 But it has become -mandatory- on MD/RAID setups on Fedora 22 and Fedora 23: $ rpm -q dracut dracut-041-10.fc22.1.x86_64 $ rpm -q dracut dracut-041-10.git20150219.fc23.x86_64 And already we have fought for this user's side simplification, but it seems developers are very persistent when they do not need to be.

8 years, 3 months

3
4
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

test May 2015