similar to: Upgraded to F18: now machines won't start

> Thanks, but I checked it and It shows I have already installed qemu-kvm. Please check if kvm and kvm_intel ( for systems with 'vmx' flag) / kvm_amd (systems with 'svm' flag) are loaded in the system. On Mon, Aug 26, 2013 at 9:40 AM, Qian Feng <qianfeng04161001@gmail.com>wrote: > Thanks, but I checked it and It shows I have already installed qemu-kvm. > >

Run with LIBGUESTFS_ATTACH_METHOD=appliance Fails with: inspect_os: mount_ro: /dev/sda on / (options: 'ro'): mount: /dev/sda is already mounted or /sysroot busy at /usr/share/perl5/vendor_perl/Sys/VirtConvert/GuestfsHandle.pm line 194. virt-inspector works as expected libguestfs-test-tool.log: http://pastebin.ca/2317900 virt-v2v.log: http://iaindb.pastebin.ca/2317938 Any

Should I be concerned? [root@fs1 ~]# cobbler import --name=F18 --path=rsync://mirrors.kernel.org/fedora/releases/18/Fedora/x86_64/os --arch=x86_64 task started: 2013-01-18_062009_import task started (id=Media import, time=Fri Jan 18 06:20:09 2013) Found a redhat compatible signature: Packages adding distros creating new distro: F18-x86_64 creating new profile: F18-x86_64 associating repos

Hi all, On a F18, I installed livecd-tools-18.15-1 I downloaded CenOS6.x minimal .iso and with livecd-iso-to-disk the resulting USB is never bootable: the computer doesnt boot on it. Tested on many computers. The fact is I succeded to install CentOS on a Netbook (no CD/DVD tray), but I dont remember how I invoked livecd-iso-to-disk. I tried with many combinations (/dev/sdc is the USB

Hello, This is regarding recent/ongoing discussions about F18 being merged in LLVM. I was going through these threads, and I found few important points which were possibly left unanswered (or I might have missed few threads). URL: http://lists.llvm.org/pipermail/flang-dev/2019-December/000120.html Point: Is (3) AST -> FIR -> MLIR LLVM-IR -> LLVM-IR) in a shape where we can

Am Sa., 2. März 2019 um 11:15 Uhr schrieb Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org>: > I’d be really opposed to flang reusing the Clang ASTs themselves. C++ is already a complicated language and mixing all of Fortran's concerns (including a completely different object model) will make both of them *worse* than having them stand alone IMO. Could there be a common base

Hi all F18 merging has finished so commit access should be back to normal. Thanks Rich > -----Original Message----- > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Richard > Barton via llvm-dev > Sent: 9 April, 2020 16:08 > To: llvm-dev at lists.llvm.org > Subject: [llvm-dev] F18 upstreaming Now! > > Hi all > > We are about to merge F18

On Mon, Feb 25, 2019 at 2:45 PM Chandler Carruth via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Mon, Feb 25, 2019 at 10:06 AM Stephen Scalpone via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> * The current f18 code will be committed to the new LLVM subproject. The >> f18 code is a set of libraries that implements the Fortran compiler. >>

On 4/10/19, 12:15 PM, "llvm-dev on behalf of Chris Lattner via llvm-dev" wrote: > The foundation recommends considering a new name for the project (e.g. flang or simply fortran) > to be more accessible and obvious for new contributors - in addition to being the repository name, > it will also be the base stem for mailing lists and other project related material. The f18

Hi llvm-dev We believe we have completed enough of the agreed pre-upstreaming changes to start talking about merging F18 into LLVM. The live status is tracked at [1]. There are a few details that we have not managed to hammer out and we propose to tackle inside the LLVM monorepo. I have put a summary of these at the bottom of this mail. Does anyone have any objections to flang being merged into

On 4/30/19 9:33 AM, David Greene via llvm-dev wrote: > "fortran" seems far too generic to me. What distinguishes it from a > different Fortran compiler? > > What about "flange" (Fortran language environment)? It's distinct from > the already-in-use-by-two-projects "flang" yet fits in with the existing > "clang" naming scheme. Plus it

On Mon, Feb 25, 2019 at 5:46 PM Chandler Carruth via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Mon, Feb 25, 2019 at 10:06 AM Stephen Scalpone via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> * The current f18 code will be committed to the new LLVM subproject. The >> f18 code is a set of libraries that implements the Fortran compiler. >>

On 01/03/2019 17:26, Troy Johnson via llvm-dev wrote: > This RFC started a good discussion and I’d like to hear responses from its author > to all of the points that have been made so far. > >   > > FWIW, I’m also in favor of reusing as much from Clang as practical.  In fact, with> the combined repo now, it might make sense to factor out some common front end code > that

Hi, I reported a bug to anaconda (rhbz 901905), but it might be btfs related. Anaconda does this: 18:49:10,317 INFO program: Running... mkfs.btrfs --data=single --label=fedora /dev/vdb1 /dev/vdc1 /dev/vdd1 /dev/vde1 18:49:10,742 INFO program: 18:49:10,746 INFO program: WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL 18:49:10,746 INFO program: WARNING! - see http://btrfs.wiki.kernel.org before

"Finkel, Hal J. via llvm-dev" <llvm-dev at lists.llvm.org> writes: > And then there is also the argument for reusing Clang tooling, > which David Greene keeps making, though that idea does not seem to > get a lot of interest. > > > I disagree. There's been a lot of interest in modeling Flang's tooling > after Clang's

I rebuild mesa with debug symbols, and now top functions using CPU looks like this: CPU: AMD64 family15h, speed 3800 MHz (estimated) Counted CPU_CLK_UNHALTED events (CPU Clocks not Halted) with a unit mask of 0x00 (No unit mask) count 100000 samples % image name symbol name ------------------------------------------------------------------------------- 222978 45.1489

Hi guys, I posted this question at virt list on Fedora Project but I guess its a best place to ask help for my problem. I'm trying to set up two kvm/libvirt hosts, I installed the set of packages contained in @kvm and @clustering groups, downloaded and installed glusterfs version 3.1.2, configured the cluster ( all working ), configured the gluster volume and mounted it on

On 04.03.2016 16:24, Predrag Ivanovic wrote: > Hi. > > Since the update to libvirt-1.3.2, virsh keeps disconnecting from qemu:///session. > Weirdly enough, qemu:///session works fine for root, and qemu:///system works for both the user and the root. > With the same configuration(tarball with files from /etc/libvirt attached), libvirt-1.3.1 works without problems. > > From

Hi. Since the update to libvirt-1.3.2, virsh keeps disconnecting from qemu:///session. Weirdly enough, qemu:///session works fine for root, and qemu:///system works for both the user and the root. With the same configuration(tarball with files from /etc/libvirt attached), libvirt-1.3.1 works without problems. From the virsh debug log(attached): --- grep error virsh.log.1.3.2 2016-03-03

Will the kvm_amd kernel module be in CentOS 5.2? Presently I run 2.6.24 on one machine so I get kvm_amd. It would be great if it is included. Jerry