Mounting an internally installed disk on a laptop spins up all
disks connected to this machine via USB. And I try to prevent these
externally connected disks to spin up.
The behaviour, IIRC, started a few months ago on the previous F27 and
continues now on F28. Before that I don't remember this behaviour to
I thought it was some smartd issue, and stopped this service
("/usr/bin/systemctl stop smartd.service") - to no avail: mounting the
internal disk still spins up the external ones.
The internal disk is identified by "smartctl -d test /dev/sda" like
[ ... ]
/dev/sda: Device of type 'scsi' [SCSI] detected
/dev/sda [SAT]: Device open changed type from 'scsi' to 'sat'
/dev/sda [SAT]: Device of type 'sat' [ATA] opened
(On a side note: I'm astonished that a smartctl simple info flag is
changing some device type like shown above)
External disks are identified by a smartctl test like so:
"[USB Sunplus]: Device of type 'usbsunplus' [ATA] detected"
the other one:
"[SAT]: Device of type 'sat' [ATA] detected"
Anyone an idea about where to start investigating this issue? Where
could such behaviour possibly be set up?
Thanks in anticipation.
After an update to Fedora29 I can print but not scan anymore with a HP
officejet 4620 in WLAN.
When running HP-check I get two messages : cups required incompat : cups
may nt be installed or running .
cups is installed and running.
python3-notify2 needs to be
installed : Question where can I "find it"
Has anyone the same experience ?
Ger van Dijck.
Using Opera's mail client: http://www.opera.com/mail/
Does Fedora 29 support the Intel RST (Rapid Storage Technology) chip for
hardware RAID? My new ThinkPad P72 came with an RST chip set up with two
2TB PCIe M.2 SSDs in a RAID1 config. The Fedora-29-MATE-Compiz spin DVD
doesn't "see" it. Nor does Clonezilla.
There's a BIOS mode setting for the Intel RST: "RST" mode for RAID, and
"AHCI" mode for separate SATA drives. Changing that setting to AHCI will
probably break the RAID1 array and render the P72 unbootable. I don't know
if that would a destructive, irreversible change, or if changing the mode
setting back to RST would restore everything.
I've only tried the MATE spin. One purpose of this question is to find out
if the full installation DVD supports the Intel RST chip.
Robert G. (Doc) Savage
Fairview Heights, IL
"Perfection is the enemy of good enough."
-- Admiral of the Fleet Sergei G. Gorshkov
Upgraded to F29. On KDE desktop starting EMACS in a privileged command
window locks the system. Starting EMACS with sudo locks the system. On
XFCE4 normal EMACS access with privilege.
Other file managers don't like root but there are times when cli is awkward.
I get *Failed to start Load Kernel Modules* during the boot.
Everytime Kernel is updated VirtualBox modules fail I have to reboot into
the new Kernel, run the following commands and then it starts working.
$ sudo akmods --force
$ sudo dracut -v -f
$ sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
Then everything starts working again and the boot error goes away. You can
found the background of the issue in the link below.
My question is how can I automate this task.
I currently run a couple of VMs (one Windows 10 and one Fedora Server)
under QEMU/KVM. I wanted to create a new one and got this:
Unable to complete install: 'internal error: process exited while connecting to monitor: 2018-12-31T14:23:14.816147Z qemu-system-x86_64: can't apply global IvyBridge-IBRS-x86_64-cpu.osxsave=on: Property '.osxsave' not found'
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/create.py", line 2559, in _do_async_install
File "/usr/share/virt-manager/virtinst/guest.py", line 465, in start_install
File "/usr/share/virt-manager/virtinst/guest.py", line 401, in _create_guest
domain = self.conn.createXML(install_xml or final_xml, 0)
File "/usr/lib64/python3.7/site-packages/libvirt.py", line 3718, in createXML
if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
libvirt.libvirtError: internal error: process exited while connecting to monitor: 2018-12-31T14:23:14.816147Z qemu-system-x86_64: can't apply global IvyBridge-IBRS-x86_64-cpu.osxsave=on: Property '.osxsave' not found
The last line is the key. This is similar to a bug I had a while back and reported at the time:
When it happened before I edited the XML file to remove the .osxsave
flag and that solved the problem. However now it's happening with a
fresh VM so there's no XML file to edit. Note that the new VM is a
small Windows test install with no special configuration, i.e.
everything just uses the default settings.
I've posted about this on the VFIO list but haven't received a solution
so far. See
I last updated my laptop on 12/26. It is running fc28.x86_64
Today I tried to run dnf update:
> # dnf update
> Traceback (most recent call last):
> File "/usr/bin/dnf", line 58, in <module>
> main.user_main(sys.argv[1:], exit_code=True)
> File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 179, in user_main
> errcode = main(args)
> File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 64, in main
> return _main(base, args, cli_class, option_parser_class)
> File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 99, in _main
> return cli_run(cli, base)
> File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 115, in cli_run
> File "/usr/lib/python3.6/site-packages/dnf/cli/cli.py", line 1015, in run
> File "/usr/lib/python3.6/site-packages/dnf/cli/cli.py", line 768, in _process_demands
> File "/usr/lib/python3.6/site-packages/dnf/base.py", line 475, in fill_sack
> File "/usr/lib/python3.6/site-packages/dnf/base.py", line 147, in _add_repo_to_sack
> _hawkey.Exception: repo_add_solv() has failed.
Is it Fedora 28? dnf? some dnf dependency? or my laptop? that is broken?
Kevin J. Cummings
Registered Linux User #1232 (http://www.linuxcounter.net/)
Le 16/12/2018 à 11:07, Francis.Montagnac(a)inria.fr a écrit :
> On Sun, 16 Dec 2018 09:24:44 +0100 François Patte wrote:
>> I corrected this file using grub2-mkconfig. So, my question is: why the
>> kernel script is unable to correctly use grub2-mkconfig?
> As far as I know it uses grubby.
Is that a reason? Whatever the kernel script is when a new kernel is
installed it *should not* choose a wrong partition as the root partition!!!
This is a new behaviour: before kernel 4.19.6 there was no problem.
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. +33 (0)6 7892 5822
I have just upgraded my F29 with
dnf upgrade -y
I continued to use the system without reboot and it suddenly stopped
working. Only the mouse was working. Ctrl+Alt+FN did not work but I
was able to ssh and reboot. It took a while to close linux before
rebooting and then I did not get the usual GRUB menu where I can choos
the kernel but instead just a black screen with a blinking cursor. So
I suspect that the upgrade broke GRUB and I cannot load fedora
I am probably able to boot with a USB stick. What should I do to go
back to normal?