Re: the akmod-nvidia will not work under kernel with version 4.0.7 for Fedora22
not yet. 2015-07-13 18:01 GMT+08:00 Frank Murphy frankl...@gmail.com: On Mon, 13 Jul 2015 17:27:46 +0800 Jean Jacques chao...@gmail.com wrote: will not generated an module for kernel but works well under 4.0.6 Have you check the rpmfusion mailing listslist for any other users reporting problems\solutions. ___ Regards Frank Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: the akmod-nvidia will not work under kernel with version 4.0.7 for Fedora22
On 07/13/15 17:27, Jean Jacques wrote: will not generated an module for kernel but works well under 4.0.6 I see you got your answer on the rpmfusion list. When you have a problem with akmods you can check /var/cache/akmods/akmods.log for information about what when wrong. -- Sorta what I want to say when folks habitually complain about Fedora - https://youtu.be/ZArl8fTfub4 -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
the akmod-nvidia will not work under kernel with version 4.0.7 for Fedora22
will not generated an module for kernel but works well under 4.0.6 -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Windows 8 Dual boot lost after Fedora upgrade
Hi Chris,
Thanks for this. Just had a fantastic honeymoon, but now back in the real
world and onwards with trying to fix this.
On Friday 03 July 2015 18:35:47 Chris Murphy wrote:
There's an awful lot going on here. And to vent, I'm going to start
out by saying dual boot sucks. It's not you, users are sane, and dual
boot support on Linux just sucks. OK...
On Fri, Jul 3, 2015 at 9:09 AM, Gary Stainburn
gary.stainb...@ringways.co.uk wrote:
I've finally decided to have a go at fixing the problem where the Windows
8 option disappeared from my GRUB menu when I upgraded from F19 to F20.
This suggests the computer does not have Secure Boot enabled, because
Fedora's GRUB has never support UEFI Secure Boot chainloading of the
Windows bootloader. The fact the GRUB menu entry used to work, and now
doesn't, suggests some other problem.
[snip]
1098EFF798EFD96C
else
search --no-floppy --fs-uuid --set=root 1098EFF798EFD96C
Is this the correct UUID for the Windows volume? Check with blkid.
grub2-mkconfig will get this right, which is why it should be used
instead of a static configuration.
./efi/EFI/Microsoft/Boot/bootmgfw.efi
This being the only thing in /boot/efi/EFI/Microsoft is perplexing.
I'm expecting a lot more stuff in here than this. So yet again I
wonder if maybe this EFI System partition was inadvertently formatted
when doing a Fedora installation? It's not difficult to accidentally
delete it, I've found.
The folder /efi/EFI/Microsoft did not exist, which tends to confirm your
suspicion that the the partition was reformatted during the upgrade. I
manually created the folder and copied bootmgfw.efi from \Windows\Boot\EFI\
But the fact is that you're not seemingly getting an error from this
OSLoader, you're getting it from GRUB not finding this path which
suggests the menu entry is malformed somehow.
Suggestions:
- Move /etc/grub.d/40_custom out of that directory so it doesn't get
used, but is still retained in case you want to revert.
- run
grub2-mkconfig -o ~/Downloads/grub.cfg
post that grub.cfg somewhere or maybe it'll all paste into the mailing
list which is fine too, I want to see the whole thing *unless* it
doesn't have a Windows menu entry listed in it. If it doesn't then I'm
going to guess that /etc/default/grub has os-prober disabled. If so
that needs to be commented out and you need to rerun the
grub2-mkconfig command.
--
Chris Murphy
Here is the generated grub.conf as requested. I've had a look at the file and
there is no mention of Windows anywhere. The windows partitions are mounted:
[root@gary ~]# mount|grep sda
/dev/sda3 on /boot type ext4 (rw,relatime,stripe=4,data=ordered)
/dev/sda2 on /boot/efi type vfat
(rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)
/dev/sda5 on /windows_recover type fuseblk
(rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096)
/dev/sda4 on /windows type fuseblk
(rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096)
[root@gary ~]# grub2-mkconfig -o ~/Downloads/grub.cfg
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.19.8-100.fc20.x86_64
Found initrd image: /boot/initramfs-3.19.8-100.fc20.x86_64.img
Found linux image: /boot/vmlinuz-3.19.5-100.fc20.x86_64
Found initrd image: /boot/initramfs-3.19.5-100.fc20.x86_64.img
Found linux image: /boot/vmlinuz-3.19.4-100.fc20.x86_64
Found initrd image: /boot/initramfs-3.19.4-100.fc20.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-da98f419484443dab77787b4692f3f8f
Found initrd
image: /boot/initramfs-0-rescue-da98f419484443dab77787b4692f3f8f.img
done
[root@gary ~]# cat ~/Downloads/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
load_env
fi
if [ ${next_entry} ] ; then
set default=${next_entry}
set next_entry=
save_env next_entry
set boot_once=true
else
set default=${saved_entry}
fi
if [ x${feature_menuentry_id} = xy ]; then
menuentry_id_option=--id
else
menuentry_id_option=
fi
export menuentry_id_option
if [ ${prev_saved_entry} ]; then
set saved_entry=${prev_saved_entry}
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z ${boot_once} ]; then
saved_entry=${chosen}
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
terminal_output console
set timeout=5
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/10_linux ###
menuentry 'Fedora, with Linux 3.19.8-100.fc20.x86_64' --class fedora --class
gnu-linux --class gnu --class os --unrestricted
$menuentry_id_option
Re: rebooting with new kernel
On 07/12/2015 11:31 PM, Chris Murphy wrote: On Sun, Jul 12, 2015 at 8:43 AM, Paul Cartwright pbcartwri...@gmail.com wrote: problem is, only a blinking cursor, no grub menu.. that's my problem. I know how to edit grub menus using e.. since I have multiple ( mostly linux) OSes, grub gets updated every now then, and I use e to make sure I am booting the latest kernel. kernel update RPMs call new-kernel-pkg which in turn call grubby, but none of that stuff ever touches any installed bootloader code. The only thing modified is the grub.cfg. I don't know how/why, but it's possible the modification of the grub.cfg is actually corrupting it but then GRUB should complain if it can't parse grub.cfg Sounds like this is a computer with BIOS firmware. On BIOS, Fedora puts grub.cfg at /boot/grub2/, and on UEFI it's at /boot/efi/EFI/fedora/. mine was Windows 7, so it is BIOS.. I always do grub2-mkconfig -o /boot/grub2/grub.cfg before I do the next update I'll copy grub.cfg, then run the update diff.. now, waiting for the next new kernel:) -- Paul Cartwright Registered Linux User #367800 and new counter #561587 -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: the akmod-nvidia will not work under kernel with version 4.0.7 for Fedora22
On Mon, 2015-07-13 at 18:38 +0800, Ed Greshko wrote: On 07/13/15 17:27, Jean Jacques wrote: will not generated an module for kernel but works well under 4.0.6 I see you got your answer on the rpmfusion list. When you have a problem with akmods you can check /var/cache/akmods/akmods.log for information about what when wrong. Same thing happened to me. I fixed it by checking the log and rerunning the modulebuild script manually. This was discussed on several recent threads (search for nvidia in the Subject) and is fast becoming a FAQ. The basic issue is that the akmod install script compiles the source module against the new kernel, creating a new rpm. It then tries to install the rpm, but the rpm database is already locked by a different process (presumably the dnf run that called the script in the first place, though I haven't verified this). The rpm install fails but the user isn't told directly, and when he reboots there is no nvidia module available for the new kernel. I suspect that this happens to those of us who run dnf directly from the Shell. I understand that the GUI tool under Gnome reboots into a special image before actually doing the installation, which therefore avoids the problem, but I don't use Gnome or GUI installation tools so this is pure conjecture. poc -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: rebooting with new kernel
On 07/12/2015 10:47 PM, Gordon Messmer wrote: On 07/12/2015 03:43 AM, Paul Cartwright wrote: rebooted and... a blinking cursor on a black background.. this seems to happen everytime now when I get a new kernel in F22 Next time you update, save a copy of /boot/efi/EFI/fedora/grub.cfg, then run grub2-mkconfig. You can compare them to see the changes: diff -u saved-grub.cfg /boot/efi/EFI/fedora/grub.cfg That should tell you what's breaking when you update. there is no grub.cfg in fedora, only: ls BOOT.CSV gcdx64.efi grubx64.efi shim.efi fonts grubenv MokManager.efi shim-fedora.efi grub.cfg is in /boot/grub2, but I will try that next time, thanks! -- Paul Cartwright Registered Linux User #367800 and new counter #561587 -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: the akmod-nvidia will not work under kernel with version 4.0.7 for Fedora22
On Mon, 13 Jul 2015 17:27:46 +0800 Jean Jacques chao...@gmail.com wrote: will not generated an module for kernel but works well under 4.0.6 Have you check the rpmfusion mailing listslist for any other users reporting problems\solutions. ___ Regards Frank Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: system response issue
On 07/13/2015 08:43 PM, g wrote: On 07/13/15 21:17, jd1008 wrote: On 07/13/2015 06:52 PM, g wrote: more for thought, is tar building finale file in memory, /tmp, or on the usb3 drive? :) Well, since I was using a pipe, I assume swap backed memory is used. However, the un-tar process is running in parallel, so the RAM pipe is shared between the producer tar and the consumer tar, which populates the destination directory with the contents of the source directory. That said, I do not think that the entirety of the source dir is first copied to the pipe, before it is then consumed by the untar process. I think the RAM pipe is being read (emptied), as the producer fills it (using thread synchronization primitives). Just my guess. I have not looked at tar's source code. ok. you have now thrown in *pipe* and process *un-tar*. are you using tar to pass files to target and have them end up as separate files, or as a single archive file? ria, all i see in your original post is tar -C /sdc1 -xpvf which would indicate archiving to a single file. just what is your actual command line? tar cf - BigDirArchive | tar -C /sdc1 -xpvf - -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: system response issue
On 07/13/15 21:54, jd1008 wrote: On 07/13/2015 08:43 PM, g wrote: ok. you have now thrown in *pipe* and process *un-tar*. are you using tar to pass files to target and have them end up as separate files, or as a single archive file? ria, all i see in your original post is tar -C /sdc1 -xpvf which would indicate archiving to a single file. oops. -x = extract. just what is your actual command line? tar cf - BigDirArchive | tar -C /sdc1 -xpvf - ok. that does make for better understanding. i stopped using tar years ago in favor of cpio, which has more advantages, when i was using tape for archiving. works well with usb memory and usb hdd drives. in fact, when i archive paths between hdd partitions or drives, i use cpio instead of cp -R. to perform same using cpio, command line would be; find path2BigDirArchive -depth -print0 | sort | cpio -p -adm /sdc1 or find . -depth -print0 | sort | cpio -p -adm /sdc1 in above, -p is 'copy-pass mode', equivalent to | and -x in tar. because you are having response time issues with usb, i believe you will find cpio to be more favorable than using tar. -- peace out. -+- If Bill Gates got a dime for every time Windows crashes... ...oh, wait. He does. THAT explains it! -+- in a world with out fences, who needs gates. -+- CentOS GNU/Linux 6.6 tc,hago. g . -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: aeskulap and dicom files
On Jul 11, 2015 12:38 PM, Gregory P. Ennis po...@pomec.net wrote: [root@HmGe f21]# rpm -Uhvf aeskulap-0.2.2-0.19beta1.fc21.x86_64.rpm error: Failed dependencies: `rpm` knows about dependencies but does not pull other packages to resolve them. That's dnf's job. Use dnf, do not use rpm directly. ... John, Can you give me a list of what repositories you are using. Here is what I got Greg [root@HmGe f21]# dnf --nogpgcheck --releasever=21 install aeskulap -0.2.2-0.19beta1.fc21.x86_64.rpm Extra Packages for Enterprise Linux 7 - x86_64 1.2 MB/s | 9.3 MB 00:07 You are not running Enterprise Linux 7. This repo is not for Fedora. Using it will cause conflicts and unpredictable problems. --Pete -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: system response issue
On 07/13/2015 06:52 PM, g wrote: more for thought, is tar building finale file in memory, /tmp, or on the usb3 drive? :) Well, since I was using a pipe, I assume swap backed memory is used. However, the un-tar process is running in parallel, so the RAM pipe is shared between the producer tar and the consumer tar, which populates the destination directory with the contents of the source directory. That said, I do not think that the entirety of the source dir is first copied to the pipe, before it is then consumed by the untar process. I think the RAM pipe is being read (emptied), as the producer fills it (using thread synchronization primitives). Just my guess. I have not looked at tar's source code. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: system response issue
On 07/13/15 21:17, jd1008 wrote: On 07/13/2015 06:52 PM, g wrote: more for thought, is tar building finale file in memory, /tmp, or on the usb3 drive? :) Well, since I was using a pipe, I assume swap backed memory is used. However, the un-tar process is running in parallel, so the RAM pipe is shared between the producer tar and the consumer tar, which populates the destination directory with the contents of the source directory. That said, I do not think that the entirety of the source dir is first copied to the pipe, before it is then consumed by the untar process. I think the RAM pipe is being read (emptied), as the producer fills it (using thread synchronization primitives). Just my guess. I have not looked at tar's source code. ok. you have now thrown in *pipe* and process *un-tar*. are you using tar to pass files to target and have them end up as separate files, or as a single archive file? ria, all i see in your original post is tar -C /sdc1 -xpvf which would indicate archiving to a single file. just what is your actual command line? -- peace out. -+- If Bill Gates got a dime for every time Windows crashes... ...oh, wait. He does. THAT explains it! -+- in a world with out fences, who needs gates. -+- CentOS GNU/Linux 6.6 tc,hago. g . -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Fedora21/22 grub doesn't recognize my raid1/LVM partitions
On Mon Jul 13 02:19:31 UTC 2015 Chris Murphy typed: So there's the kernel bug, 1225671, that ends up stopping the arrays, but then there's a misleading message saying there's a problem that's been corrected, yet clearly not corrected. The exact wording of the message is: 'Unexpected system error. The system has encountered a problem and recovered.' Does this same kernel call trace happen with Fedora 21's installer? Or does it fail for a different reason? With the F21 installer, there is no error message, and the installer does find the raid1 array. But it finds it only as one ~ 460 GB 'physical volume'; my existing LVM partitions are not recognized, so I can't install into them. There is a beta release criteria for this: Hardware and firmware RAID The installer must be able to detect and install to hardware or firmware RAID storage devices. And there are test cases, and there's an entry for software raid in the test matrix. So it should get tested multiple times per build, and there will be a dozen builds pre-alpha, pre-beta, and pre-final. So it's a bit surprising this is so easy to hit (the bug report has someone hitting it in virtual box). Obviously this can't be fixed with official media, you could roll your own workstation installer compose and instead use kernel 4.0.5 which should fix this bug, and then you'd be able to install F22 to this existing software raid. -- Chris Murphy Alas, rolling my own workstation installer is beyond my present skill level. I must decide whether to wait for Fedora 23, or to back up everything and let the F22 installer have a crack at creating a new raid1 array with LVMs on top of it. Thanks again for the help, -jmw- -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: aeskulap and dicom files
You are not running Enterprise Linux 7. This repo is not for Fedora. Using it will cause conflicts and unpredictable problems. --Pete Thanks Pete finally figured that out too. Greg -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Fedora21/22 grub doesn't recognize my raid1/LVM partitions
On Mon, Jul 13, 2015 at 11:33 AM, John Wright jwrig...@san.rr.com wrote: On Mon Jul 13 02:19:31 UTC 2015 Chris Murphy typed: So there's the kernel bug, 1225671, that ends up stopping the arrays, but then there's a misleading message saying there's a problem that's been corrected, yet clearly not corrected. The exact wording of the message is: 'Unexpected system error. The system has encountered a problem and recovered.' This is a message in the installer itself? Or is this a GNOME notification (a floating thing from the top-center)? I'm going to guess it's not in the installer because I've always seen it spit out the exact error message into the anaconda.log (or program.log if it's a helper program's error) and I don't see that in your attached logs. But I also don't see it in the journal either, so... I'm baffled exactly what system error it's referring to as well as this supposed recovery. GNOME bug... haha. Does this same kernel call trace happen with Fedora 21's installer? Or does it fail for a different reason? With the F21 installer, there is no error message, and the installer does find the raid1 array. But it finds it only as one ~ 460 GB 'physical volume'; my existing LVM partitions are not recognized, so I can't install into them. Goofy cakes. OK so that suggests PV metadata is recognized, but for some reason the VG/LV's are actually activated for some reason. This could be a variation of bug 825236, which causes linux installs on LVM to be recognized by grub-mkconfig; but you don't have the problem on Fedora 20 which is likewise afflicted. At least the VG should be available so you can add (space permitting) new LVs. But if the LV's aren't made active and listed, you couldn't shrink any of them to make room to make additional ones. Blek. So as a work around for Fedora 22's installer, I wonder if this oops is fatal or if you can assemble the array with mdadm -A before launching the installer, get the array going again, then lvchange -ay to activate the LVs, and then launch the installer. Either it'll see the LV's now, *OR* you get another kernel oops and the array stops again making everything go away. If the former, work around seems likely. If the latter, then you'd need to build your own installer ISO swapping out the kernel version for 4.0.5 or greater which should fix the problem. Alas, rolling my own workstation installer is beyond my present skill level. I must decide whether to wait for Fedora 23, or to back up everything and let the F22 installer have a crack at creating a new raid1 array with LVMs on top of it. Seeing as this is broken in two different ways with Fedora 21 and 22, it would benefit the project, other users, and yourself, to test this in Fedora 23 at some point. And if it's still not working, file a new bug if the failure doesn't match up with one of the existing bug reports, and mark as a blocker. More info on test@ list how to go about doing this. -- Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: OT Password problem -
On 2015-07-10 12:42, Joe Zeff wrote: On 07/10/2015 07:33 AM, Matthew Woehlke wrote: probably have a more benign reason (maybe to stop people that don't know what they're doing from accidentally bricking their machines). That's no excuse. Once you've paid for the machine and received it, what you do with it is none of their business. ...so if I sell you a gun, I should be sure to ship it to you with the safety *off*? Sure, that might be more convenient, but OTOH it's not like I welded the safety in the on position. I agree with the sentiment, and that's why I take a very low view of dealers that password lock the BIOS *and won't tell you the password*. If they're happy to tell you... I still don't necessarily agree with having one in the first place, but I'm much less inclined to ascribe sinister motives. (Or, as Bob indicated, maybe it was an accident. Maybe they test the BIOS password lock of every computer they sell and sometimes forget to remove the password again.) -- Matthew -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Mounting HD from Live CD
On 13.07.2015, Aaron Gray wrote: Cheers Mike. I did try mounting previously but did not work will try again tomorrow. If you want proper help, please post the output of your mount attempt, e.g. mkdir /test mount /dev/sdX /test Where X is the proper partition/device number. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: To the aeskulap guy
On 12.07.2015, tangen...@hushmail.com wrote: You can take the src rpm from Fedora 21 and use the command: rpmbuild --rebuild src rpm. This generates a version of aeskulap to Fedora 22. It works in several times. It doesn't. Aeskulap may compile, but won't work because the Dicom Toolkit provided by F22 is not fully backwards compatible to the (older) version needed by the F21 aeskulap package. The proper solution mentioned here in the corresponding thread is either installing the F21 rpm together with the F21 Dicom Toolkit, or replacing the F22 Dicom Toolkit with the latest from F21 and recompiling a recent version of aeskulap. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: [389-users] 389-ds access.log parsing - turning LDAP request type into an audit event
On 07/11/2015 09:29 PM, Burn Alting wrote: On Mon, 2015-07-06 at 08:00 -0600, Rich Megginson wrote: On 07/03/2015 05:49 AM, Burn Alting wrote: Has anyone authored code to parse a 389 Directory Server's access.log file(s) with an aim of generating audit events based around the LDAP request type. Basically, take the log sequence [21/Apr/2007:11:39:51 -0700] conn=11 fd=608 slot=608 connection from 207.1.153.51 to 192.18.122.139 [21/Apr/2007:11:39:51 -0700] conn=11 op=0 BIND dn=cn=Directory Manager method=128 version=3 [21/Apr/2007:11:39:51 -0700] conn=11 op=0 RESULT err=0 tag=97 nentries=0 etime=0 [21/Apr/2007:11:39:51 -0700] conn=11 op=1 SRCH base=dc=example,dc=com scope=2 filter=(uid=bjensen) [21/Apr/2007:11:39:51 -0700] conn=11 op=1 RESULT err=0 tag=101 nentries=1 etime=1000 notes=U [21/Apr/2007:11:39:51 -0700] conn=11 op=2 UNBIND [21/Apr/2007:11:39:51 -0700] conn=11 op=2 fd=608 closed - U1 And turn this into an audit event with a date/time (21/Apr/2007:11:39:51 -0700), a client location (207.1.153.51), server location (192.18.122.139), a user (cn=Directory Manager), an event (SRCH) and event metadata of (query - base=dc=example,dc=com scope=2 filter=(uid=bjensen), result set size - 1, timetaken = 1000 sec, etc) The logconv.pl script seems to do all sorts of analysis, but no event representation. This sounds like a request for a new feature. Would you be able to write up a description of the new feature based on http://www.port389.org/docs/389ds/design/design-template.html? If so, I will post it to the 389 wiki and assign a ticket. Rich, Find the write up below. Regards Burn Alting Thanks! https://fedorahosted.org/389/ticket/48222 http://www.port389.org/docs/389ds/design/audit-events.html Title - Parse audit-able events from 389/directory server access logs Overview A utility is required to parse 389/directory server access logs whose output is a well defined record (event) of the LDAP request and any resultant responses. Each event would contain the initiating host address and the current authenticated DN to make subsequent entity access analysis more efficient. In essence, generate a single event for every operation (common op=) performed for a unique connection. The events need to be well formed and consideration given to further downstream parsing. As the access log records are well documented, the output event should minimize changes to the content (if changed at all). The utility would need to support time based queries. That is, generate events between a given start and end time. Note that if the connection and authentication occurs BEFORE the given start time, this detail still needs to decorate the event output. The utility would need to indicate if the authenticated DN or initiating client could not be ascertained. That is, the information is NOT in the file(s) processed. Optionally can ignore internal operations. Use Cases - The following cases show a logfile extract and resultant parsed output. The output is in XML. Other well formed and parsable output could be chosen (eg json) - the intent is that downstream capability needs to parse the information. #1 Extract: [21/Apr/2009:11:39:51 -0700] conn=11 fd=608 slot=608 connection from 207.1.153.57 to 192.18.122.139 [21/Apr/2009:11:39:51 -0700] conn=11 op=0 BIND dn=cn=Directory Manager method=128 version=3 [21/Apr/2009:11:39:51 -0700] conn=11 op=0 RESULT err=0 tag=97 nentries=0 etime=0 [21/Apr/2009:11:39:51 -0700] conn=11 op=1 SRCH base=dc=example,dc=com scope=2 filter=(mobile=+1 123 456-7890) [21/Apr/2009:11:39:51 -0700] conn=11 op=1 RESULT err=0 tag=101 nentries=1 etime=3 notes=U [21/Apr/2009:11:39:51 -0700] conn=11 op=2 UNBIND [21/Apr/2009:11:39:51 -0700] conn=11 op=2 fd=608 closed - U1 Resultant sub-extract and Event output: [21/Apr/2009:11:39:51 -0700] conn=11 fd=608 slot=608 connection from 207.1.153.57 to 192.18.122.139 [21/Apr/2009:11:39:51 -0700] conn=11 op=0 BIND dn=cn=Directory Manager method=128 version=3 [21/Apr/2009:11:39:51 -0700] conn=11 op=0 RESULT err=0 tag=97 nentries=0 etime=0 Event DateTime21/Apr/2009:11:39:51 -0700/DateTime Client207.1.153.57/Client Server192.18.122.139/Server Connection11/Connection Operation0/Operation AuthenticatedDNcn=Directory Manager/AuthenticatedDN ActionBIND/Action Requests RequestBIND dn=quot;cn=Directory Managerquot; method=128 version=3/Request /Requests Responses ResponseRESULT err=0 tag=97 nentries=0 etime=0/Response /Responses /Event [21/Apr/2009:11:39:51 -0700] conn=11 op=1 SRCH base=dc=example,dc=com scope=2 filter=(mobile=+1 123 456-7890) [21/Apr/2009:11:39:51 -0700] conn=11 op=1 RESULT err=0 tag=101 nentries=1 etime=3 notes=U Event DateTime21/Apr/2009:11:39:51 -0700/DateTime Client207.1.153.57/Client Server192.18.122.139/Server Connection11/Connection Operation1/Operation AuthenticatedDNcn=Directory
Re: system response issue
On Mon, 2015-07-13 at 13:50 -0600, jd1008 wrote: I started a tar command from one external eSATA drive (ext4), connected to eSATA port, out to a USB flash drive (with vfat). The USB stick is touted to support 50MB/s write, 160MB/s read. Have you actually measured its real write speed for large files? Try something like: time dd if=/dev/zero of=/the/usb/drive count=1000 bs=1M You might be surprised. poc -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: aeskulap and dicom files
Date: Sun, 12 Jul 2015 06:43:50 -0500 On Sun, 2015-07-12 at 19:35 +0800, Ed Greshko wrote: On 07/12/15 19:23, Gregory P. Ennis wrote: Thank you for your reply. I had to remove f22 dcmtk before this would work, but at least I have my DICOM viewer back. Thanks again! You're welcome. You may want to add an exclude in your dnf.conf for the F21 packages so they get skipped the next time you do an update to your system. -- Sorta what I want to say when folks habitually complain about Fedora - https://youtu.be/ZArl8fTfub4 -- Everyone, I have been in dialog with the Fedora maintainer of aeskulap, Ankur Sinha, and he is working to get it ready for F22. He has filled a bug report for dcmtk. Ankur's response to one of my e-mails is as follows: No worries. I looked at the error, but it probably requires me to look into dcmtk changes to fix it. I've filed a bug here for the time being: https://github.com/pipelka/aeskulap/issues/2 This seems to be the original author of aeskulap, so I'm hopeful that we'll have a fix. Greg -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
system response issue
I started a tar command from one external eSATA drive (ext4), connected to eSATA port, out to a USB flash drive (with vfat). The USB stick is touted to support 50MB/s write, 160MB/s read. The USB port itself is USB 2.0 (480MBits/s). The desktop (Mate) response goes down the tubes. I ran top and found that cpu is only 3% usage by firefox. rest are a few at 1%, and rest showing 0%. Load average: load average: 5.95, 5.81, 6.05 Wow Why? I ran iotop -d 3 and found 3263 be/4 root0.00 B/s0.00 B/s 0.00 % 99.99 % [kworker/u16:3] 61 be/4 root0.00 B/s0.00 B/s 0.00 % 99.99 % [kswapd0] 3180 be/4 root 335.95 B/s3.62 M/s 0.00 % 99.99 % tar -C /sdc1 -xpvf - 4071 be/4 root0.00 B/s0.00 B/s 0.00 % 27.36 % [kworker/0:2] Processes that are started but idle: 1 instance of smplayer (idle - nothing being played) 2 instances of TB (for 2 different profiles) - idle - no incoming or outgoing emails. both check for mail every so many minutes. 1 instance of FF with a total of 6 tabs - all of them idle (no videos, no audios on them and no animations.). So, it seems that the scheduler is letting the disk io pretty much commandeer and hijack system response time for the DT. Is there a configuration tweak to grant more cycles to the DT (mouse, KB) interaction with other GUI based programs? -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: system response issue
On Mon, 2015-07-13 at 15:37 -0600, jd1008 wrote: On 07/13/2015 03:13 PM, Patrick O'Callaghan wrote: On Mon, 2015-07-13 at 13:50 -0600, jd1008 wrote: I started a tar command from one external eSATA drive (ext4), connected to eSATA port, out to a USB flash drive (with vfat). The USB stick is touted to support 50MB/s write, 160MB/s read. Have you actually measured its real write speed for large files? Try something like: time dd if=/dev/zero of=/the/usb/drive count=1000 bs=1M You might be surprised. poc Well, I am not surprised, but disappointed (seriously!!!) $ time dd if=/dev/zero of=/run/media/jd/USB3_ST1-2K/test-wr-speed.txt bs=1M count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 57.6116 s, 18.2 MB/s real0m57.88s user0m0.00s sys 0m1.28s So much for 50MB/s write speed USB flash drives only work efficiently at multiples of their internal block size, which is not usually directly visible to the host (Google for info on how flash drives actually work; hint: every write requires the entire block to be zeroed and then overwritten). The claimed I/O speed of these devices is achievable, just not under real conditions with a generic driver. poc -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: system response issue
On Mon, 2015-07-13 at 15:42 -0600, jd1008 wrote: On 07/13/2015 03:13 PM, Patrick O'Callaghan wrote: On Mon, 2015-07-13 at 13:50 -0600, jd1008 wrote: I started a tar command from one external eSATA drive (ext4), connected to eSATA port, out to a USB flash drive (with vfat). The USB stick is touted to support 50MB/s write, 160MB/s read. Have you actually measured its real write speed for large files? Try something like: time dd if=/dev/zero of=/the/usb/drive count=1000 bs=1M You might be surprised. poc As I just replied with the actual read/write performance data on this USB 3.0 SUperTalentExpress Drive (256GB), I am much more surprised by the fact that while tarring a large dir to it from a fast eSATA drive, the system becomes nearly unusable!!! So, if this shtick is so slow, why is writing to it killing the response time for everything else? IIRC USB drives are not DMA driven, i.e. each filesystem block written to the drive has to be pushed over the serial bus and handled by the CPU. Also, check if the drive is mounted with the 'flush' option, which sacrifices speed for greater integrity (i.e. less damage of the user pulls the drive without ejecting it). poc -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Fedora21/22 grub doesn't recognize my raid1/LVM partitions
On Mon, Jul 13, 2015 at 3:24 PM, John Wright jwrig...@san.rr.com wrote: The precise appearance of the error message is as follows: A small dark rectangular box appears at the top center of the blue wallpaper page. The box contains a large frowny-face and the words: That's an abrt message coming through the GNOME notification system. So it's picking up the oops. 'Oops, sorry, it looks like a problem occurred. If you'd like to help resolve...' On mouseover, the box expands to finish the sentence '...the issue, please send a report.', followed by a darker area at the bottom of the box containing the word 'Report'. Clicking on 'Report' opens a large light colored box with the '...encountered a problem and recovered' message, plus: I'm not sure what it means by recovered. I guess it means the kernel oops didn't cause a panic? It'd be nice if the installer could provide some error handling for such cases, but really a kernel oops is something that just shouldn't happen. Had this been reported and marked as a blocker for Fedora 22, I'm very confident it would have been accepted as a blocker because it very clearly violates a beta release criterion. This is a QA recruitment drive! The testing matrix for Fedora has really exploded lately, and all the features in the installer's custom panel just makes it all the more likely (and in my opinion increasingly likely) that bugs won't get caught unless the testing base keeps up with the feature additions. -- Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Fedora21/22 grub doesn't recognize my raid1/LVM partitions
On Mon Jul 13 18:52:16 UTC 2015 Chris Murphy typed: So there's the kernel bug, 1225671, that ends up stopping the arrays, but then there's a misleading message saying there's a problem that's been corrected, yet clearly not corrected. The exact wording of the message is: 'Unexpected system error. The system has encountered a problem and recovered.' This is a message in the installer itself? Or is this a GNOME notification (a floating thing from the top-center)? I'm going to guess it's not in the installer because I've always seen it spit out the exact error message into the anaconda.log (or program.log if it's a helper program's error) and I don't see that in your attached logs. But I also don't see it in the journal either, so... I'm baffled exactly what system error it's referring to as well as this supposed recovery. GNOME bug... haha. The precise appearance of the error message is as follows: A small dark rectangular box appears at the top center of the blue wallpaper page. The box contains a large frowny-face and the words: 'Oops, sorry, it looks like a problem occurred. If you'd like to help resolve...' On mouseover, the box expands to finish the sentence '...the issue, please send a report.', followed by a darker area at the bottom of the box containing the word 'Report'. Clicking on 'Report' opens a large light colored box with the '...encountered a problem and recovered' message, plus: Kernel-core Version 4.04.301.fc22.x86_64 plus boxes labeled 'Details' and 'log'. Clicking on 'log' opens a window that announces that the bug has already been reported, allows a login to bugzilla, thus adding my name to the cc for the bug, and a link to the bug, BZ 1225671. -jmw- -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Fedora 21 on mackbook air - no tilde key
Hi All; I've installed Fedora 21 KDE spin on a 2015 Macbook air. I installed the rpmfusion repos and enabled kmod-wl and kernel-devel packages to enable wireless support. At this point most everything works, the screen brightness keys, keyboard backlight keys, keyboard volume keys, etc all work. However if I press the tilde/back tick key I get a les than sign () and if I press shift-tilde I get a greater than sign () Anyone know how to enable the proper behavior for these keys? Thanks in advance -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: system response issue
On 07/13/2015 03:13 PM, Patrick O'Callaghan wrote: On Mon, 2015-07-13 at 13:50 -0600, jd1008 wrote: I started a tar command from one external eSATA drive (ext4), connected to eSATA port, out to a USB flash drive (with vfat). The USB stick is touted to support 50MB/s write, 160MB/s read. Have you actually measured its real write speed for large files? Try something like: time dd if=/dev/zero of=/the/usb/drive count=1000 bs=1M You might be surprised. poc Well, I am not surprised, but disappointed (seriously!!!) $ time dd if=/dev/zero of=/run/media/jd/USB3_ST1-2K/test-wr-speed.txt bs=1M count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 57.6116 s, 18.2 MB/s real0m57.88s user0m0.00s sys 0m1.28s So much for 50MB/s write speed Testing the read speed: $ time dd if=/run/media/jd/USB3_ST1-2K/F3296296960 of=/dev/null bs=8M 392+1 records in 392+1 records out 3296296960 bytes (3.3 GB) copied, 106.6 s, 30.9 MB/s real1m46.62s user0m0.00s sys 0m4.48s So much for 160MB/s read. I am going to diss this piece of ... [expletive/deleted] -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: system response issue
On 07/13/2015 03:13 PM, Patrick O'Callaghan wrote: On Mon, 2015-07-13 at 13:50 -0600, jd1008 wrote: I started a tar command from one external eSATA drive (ext4), connected to eSATA port, out to a USB flash drive (with vfat). The USB stick is touted to support 50MB/s write, 160MB/s read. Have you actually measured its real write speed for large files? Try something like: time dd if=/dev/zero of=/the/usb/drive count=1000 bs=1M You might be surprised. poc As I just replied with the actual read/write performance data on this USB 3.0 SUperTalentExpress Drive (256GB), I am much more surprised by the fact that while tarring a large dir to it from a fast eSATA drive, the system becomes nearly unusable!!! So, if this shtick is so slow, why is writing to it killing the response time for everything else? -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: system response issue
On 07/13/2015 05:15 PM, Patrick O'Callaghan wrote: On Mon, 2015-07-13 at 15:42 -0600, jd1008 wrote: On 07/13/2015 03:13 PM, Patrick O'Callaghan wrote: On Mon, 2015-07-13 at 13:50 -0600, jd1008 wrote: I started a tar command from one external eSATA drive (ext4), connected to eSATA port, out to a USB flash drive (with vfat). The USB stick is touted to support 50MB/s write, 160MB/s read. Have you actually measured its real write speed for large files? Try something like: time dd if=/dev/zero of=/the/usb/drive count=1000 bs=1M You might be surprised. poc As I just replied with the actual read/write performance data on this USB 3.0 SUperTalentExpress Drive (256GB), I am much more surprised by the fact that while tarring a large dir to it from a fast eSATA drive, the system becomes nearly unusable!!! So, if this shtick is so slow, why is writing to it killing the response time for everything else? IIRC USB drives are not DMA driven, i.e. each filesystem block written to the drive has to be pushed over the serial bus and handled by the CPU. Also, check if the drive is mounted with the 'flush' option, which sacrifices speed for greater integrity (i.e. less damage of the user pulls the drive without ejecting it). poc Good tip. I will check next time when I rerun the test. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: system response issue
On 07/13/15 19:38, jd1008 wrote: On 07/13/2015 05:15 PM, Patrick O'Callaghan wrote: IIRC USB drives are not DMA driven, i.e. each filesystem block written to the drive has to be pushed over the serial bus and handled by the CPU. Also, check if the drive is mounted with the 'flush' option, which sacrifices speed for greater integrity (i.e. less damage of the user pulls the drive without ejecting it). poc Good tip. I will check next time when I rerun the test. i agree with 'poc' 100% with both of his statements. also, i think you might want to rethink your thinking. you say you are connecting to a usb2 port and device is a usb3. near all reading of spec for usb3 devices that will work on usb2 have a statement that thru put speeds will be less if used on usb2. more for thought, is tar building finale file in memory, /tmp, or on the usb3 drive? -- peace out. -+- If Bill Gates got a dime for every time Windows crashes... ...oh, wait. He does. THAT explains it! -+- in a world with out fences, who needs gates. -+- CentOS GNU/Linux 6.6 tc,hago. g . -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
