On Oct 2, 2012, at 10:39 AM, Andreas Tunek wrote:
livecd-iso-to-disk --format --reset-mbr --efi
--reset-mbr and --efi are conflicting options. I don't know if the script
automatically negates one of them or if you just end up with a messed up USB
stick.
Chris Murphy
--
devel mailing list
this.
I guess I vaguely recall from F17 that --reset-mbr --efi gets you a hybrid
MBR/GPT thing that did work for me, but I didn't realize that was an expected
outcome that it worked.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo
On Oct 9, 2012, at 8:31 AM, Matthew Miller wrote:
(Apparently Apple does the same thing? Not that that's directly relevant,
but we're not completely out in the weeds here.)
Admin users are place in group admin. Not wheel. Only root is in wheel.
Chris Murphy
--
devel mailing list
devel
to get wrapped lines in a
pager.
Fixed in F18.
Not for me. I get one result for the first command, and 20+ for the second:
journalctl | grep btrfs
cat /var/log/messages | grep btrfs
systemd-194-1.fc18.x86_64
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https
Choose your add-ons
Minimal Install Documentation
Alternatively, include the man files in the Standard add-on?
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
rsyslog.service all seem related.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Oct 10, 2012, at 2:54 PM, Lennart Poettering wrote:
On Wed, 10.10.12 14:39, Chris Murphy (li...@colorremedies.com) wrote:
How is rsyslog properly disabled?
sockets.target syslog.target rsyslog.service all seem related.
systemctl disable rsyslog.service should suffice.
I did
in the future, by way of kickstart commands, but that's not something
we're going to expose in the UI.
Infrastructure Server option comes pretty close, I think. 800MB vs 1.1G,
no-GUI, but does appear to have docs.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https
' and I recover after
using yum erase. It's on a Core 2 Duo. EFI booting. Only with 3.6.1-1, previous
kernels are OK.
Chris Murphy--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
to be a habit.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
-broadcom-4312
b43 with the extracted firmware doesn't support 802.11N on BCM4321, and
brcmsmac doesn't support the BCM4321 at all. But oops vs 802.11g, I guess it's
not quite a toss up.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman
/ff632508(prot.20).aspx
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
regardless of what
the uefi says…
I don't think that's the case, or possibly you've stumbled on a bug. You have
UEFI 2.3.1 based hardware that implements Secure Boot and it's enabled?
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo
On Dec 2, 2012, at 4:12 PM, Kevin Fenzi ke...@scrye.com wrote:
On Sun, 02 Dec 2012 17:32:20 -0500
Felix Miata mrma...@earthlink.net wrote:
On 2012-12-02 19:21 (GMT) bugzi...@redhat.com composed:
https://bugzilla.redhat.com/show_bug.cgi?id=872826
--- Comment #19 from Chris Murphy
is actually Btrfs by default,
and then grub2-install to a partition can be employed once again and simply
just work without extra effort on the part of the user as is the case with work
around 1.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org
blockers not via
documentation but by mimicking blocker bugs, or from the email list.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ways easier than dealing with grub.
http://lists.fedoraproject.org/pipermail/devel/2012-December/174786.html
And if there's a use case for UEFI VM's, why not use EFISTUB instead of grub?
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman
.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Dec 7, 2012, at 10:24 AM, Richard W.M. Jones rjo...@redhat.com wrote:
On Thu, Dec 06, 2012 at 03:25:21PM -0700, Chris Murphy wrote:
Why is a boot manager needed for a virtualized guest? It seems like all you
need is to point to a virtual disk (or current or past snapshot) and go
conflict with GRUB Legacy commands, e.g. grub-install vs
grub2-install. It's confusing.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
is saying no you can't use other tools and have me install
there, only through me do you get any kind of installation.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Dec 10, 2012, at 4:56 PM, Adam Williamson awill...@redhat.com wrote:
On Mon, 2012-12-10 at 14:43 -0700, Chris Murphy wrote:
1. To properly install to hardware RAID 0, 10, 5, 6, I effectively
have to learn kickstart. I can properly create the volumes myself,
informing the file system
called the
EFI System partition which must be specified when using the install command.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
, then colord would still enable
something useful. But I suspect you have at least one color display.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Dec 20, 2012, at 10:41 AM, Nicolas Mailhot nicolas.mail...@laposte.net
wrote:
Le Mer 19 décembre 2012 20:26, Chris Murphy a écrit :
If you have a bw display and only bw printers, then colord would still
enable something useful. But I suspect you have at least one color
display
.
Is it reasonable for me to complain about some program that has a libtiff
dependency if I say it didn't depend on libtiff before, I don't use TIFF,
therefore there should be no dependency now? Of course not.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org
it could introduce any number of other bugs.
Yeah, the F18 ship has sailed, we're way past freeze. In fact it needs to be in
Rawhide soon enough to get into F19.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Documentation says The GRUB menu defaults to being hidden, except on dual-boot
systems. but as far as I know this hasn't been true since Fedora 16 when GRUB2
started being used. Is there a plan to revert back to a hidden GRUB menu at
some point or is the current behavior stable?
Chris Murphy
On Jan 3, 2013, at 3:00 PM, Máirín Duffy du...@fedoraproject.org wrote:
On Thu 03 Jan 2013 04:55:22 PM EST, Chris Murphy wrote:
Documentation says The GRUB menu defaults to being hidden,
except on dual-boot systems. but as far as I know this hasn't been true
since Fedora 16 when GRUB2
://bugzilla.redhat.com/show_bug.cgi?id=891756
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
don't have hardware to test, it's all multi-boot.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Jan 3, 2013, at 8:28 PM, Felix Miata mrma...@earthlink.net wrote:
On 2013-01-03 17:44 (GMT-0700) Chris Murphy composed:
My recollection on actual hardware though for F16 and F17 is that I see a
GRUB
menu. At the moment I don't have hardware to test, it's all multi-boot.
Maybe you
.
Comments?
What's weird is a beta or early final TC, Live CD written direct to a USB
stick, booted this same hardware to graphical Gnome without this problem. So
I'm not sure what's going on.
Chris Murphy--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman
do have /etc/grub.d/ files, which is part of one or both of those packages.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Jan 8, 2013, at 12:22 PM, Chris Murphy li...@colorremedies.com wrote:
What package is responsible for writing the file /etc/default/grub? Because a
prior EFI system with grub-efi, which of course doesn't have an
/etc/default/grub, doesn't have it after a fedup upgrade, and still doesn't
On Jan 8, 2013, at 12:34 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
On Tue, Jan 08, 2013 at 12:16:52PM -0700, Chris Murphy wrote:
cp /boot/efi/EFI/fedora/grubx64.efi
/boot/efi/EFI/System/Library/CoreServices/boot.efi
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
Make sure
On Jan 8, 2013, at 12:45 PM, Chris Murphy li...@colorremedies.com wrote:
On Jan 8, 2013, at 12:34 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
On Tue, Jan 08, 2013 at 12:16:52PM -0700, Chris Murphy wrote:
cp /boot/efi/EFI/fedora/grubx64.efi
/boot/efi/EFI/System/Library/CoreServices
files are in /boot/efi/EFI/redhat. The replacement grub2 files
go in /boot/efi/EFI/fedora. So I'd expect the old ones to remain behind.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
. I'm not sure if systemd and dracut will handle rootfs defined by
subvolid. This is more stable, as the subvolume can be renamed or moved, and
things still work. Whereas with subvol (name) things can break.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https
?
7xx, 8xx, 9xx, 0xx,
The first number of a Fedora release seems mostly superfluous.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
with minimal metadata writes might mean you're at 92% capacity. So
which is correct to report? It depends on future usage, which is unknown. Small
problem.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
as Btrfs volumes don't. Not implemented yet, but planned is per subvolume and
per file raid levels, so in that case we have to be literal about the reported
size of volume being the combined capacity of all block devices in the Btrfs
volume. Or you get a real problem.
Chris Murphy
--
devel
On Jan 24, 2013, at 9:30 PM, Chris Murphy li...@colorremedies.com wrote:
2x 80GB virtual disks, mkfs.btrfs -d raid1 -m raid1:
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sdb160G 56K 158G 1% /mnt
Also, copying a 1G file to /mnt, and I end up with:
# df -h
from download to upgrade without
notification, concomitant with the potential for arbitrary and untimely
implosion that could hose the entire upgrade. And this is on a supposedly
important computer that can't be down for 2 hours? Umm? I really don't
understand this thread.
Chris Murphy
--
devel
, and things may be sluggish. Chances are your videos won't
stutter, but I guess that depends on the video bit rate, effectiveness of disk
and file system read ahead, and application buffering all are.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org
process before the ship will in fact sink.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Jan 26, 2013, at 11:16 AM, Reindl Harald h.rei...@thelounge.net wrote:
Am 26.01.2013 19:09, schrieb Chris Murphy:
I just don't see how it's best practices to be doing updates on live
processes. This seems sorta like a game to find out just how much one can
cheat the upgrade process
, and for valid reasons.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
is any
more or less, sensible than top posting.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
themselves.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
, looking to implement it. So I'm not certain
that it's strictly an installer limitation.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
is broken?
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Jan 29, 2013, at 12:34 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 29.01.2013 20:30, schrieb Chris Murphy:
On Jan 29, 2013, at 11:56 AM, Reindl Harald h.rei...@thelounge.net wrote:
grub2 in fedora is simply broken in this case
https://bugzilla.redhat.com/show_bug.cgi?id
May. Has this changed?
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
and no kworker process CPU % is significant.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
to explain how the kernel has 1/2 the time on a
core2duo+HDD, compared to corei7+SSD, I can accept that offline.)
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
no journal single partition, VDI,
VirtualBox, on OS X, on SSD. So that's two hits (vbox and xnu).
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
the lack of this command causes boot failure, but I'd like to know
what component the bug should be filed against.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
.fc18.
At the time of the mass yum update, this is the version of grubby that was
installed; while the update applied 8.22-1.fc18. I don't know if the old or the
new is used in such a case.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman
On Jan 29, 2013, at 4:52 PM, Chris Murphy li...@colorremedies.com wrote:
On Jan 29, 2013, at 4:33 PM, Adam Williamson awill...@redhat.com wrote:
I'd go for grubby. This sounds vaguely familiar, though - try searching
bugzilla for 'initrdefi' first, to see if there's an existing report
On Jan 29, 2013, at 5:07 PM, Chris Murphy li...@colorremedies.com wrote:
I've installed a few kernels with both grubby-8.20-1 and 8.22-1 and the
problem consistently occurs with both of them.
Do I reopen the bug, or file a new one?
OK I see the problem, I think.
For grub.cfg in /boot
for GRUB modules in
/boot/grub2/x86_64-efi, and also installs the modules in that folder. And it
looks in /boot/grub2 for grub.cfg.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
/UX part isn't much different on Windows, but the color management
ideology is, and that actually helps rather significantly for those who
actually care about such things. So the hopeful idea is to mimic the successes
of these companies, and avoid the mistakes. Should be easy. Ha!
Chris Murphy
On Jan 29, 2013, at 8:15 PM, Chris Murphy li...@colorremedies.com wrote:
The Fedora prebaked grubx64.efi doesn't include all GRUB modules (e.g. lvm,
xnu) and it isn't looking for standalone GRUB modules in the location that
grub2-install can install them into. And anaconda doesn't call
of inkjet printers to
something reasonable, while also not exposing dangerous and mutually exclusive
options in the print (driver) dialog GUI. I haven't looked at this in Fedora
yet.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo
fedora setups and *before* F19 nobody and nothing
touched grub.cfg due kernel update slike F19
Grubby has touched grub.cfg after kernel updates for a very long time. Since at
least F15.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman
and / or just
/. But if it's the former, it ends the debate about installing the bootloader
on a partition. XFS has no bootloader pad at all so it isn't possible. On EFI
systems, it doesn't matter.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org
have multiple ways to either reformat existing partitions, or
destroy individual partitions, or destroy all partitions.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code
, but yes you can't reuse an existing
subvolume for rootfs for a new install.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
by
default for ssds with btrfs either. And with dm-crypt there's a security
concern in that it exposes massive zero'd holes on the device instead of
current data being obscured by stale data.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman
somehow (although I
don't think it's related to balance, I could be wrong), and the solution is to
set VM images to nodatacow. So I wonder if there's some behavior of systemd
journaling that's similar?
Bug is here:
https://bugzilla.redhat.com/show_bug.cgi?id=1011714
Chris Murphy
--
devel mailing
maintains.
Yes, fair point. I should have qualified the assertion better to indicate
default discard to the physical device is probably not a good idea. Or maybe it
needs to get smarter, and initiated when the fs isn't particularly busy. A kind
of delayed discard.
Chris Murphy
--
devel mailing
On Sep 25, 2013, at 8:56 AM, Ric Wheeler rwhee...@redhat.com wrote:
On 09/25/2013 10:48 AM, Chris Murphy wrote:
On Sep 25, 2013, at 6:12 AM, Ric Wheeler rwhee...@redhat.com wrote:
We should not confuse TRIM that gets handled at the device layer (and is a
slow, non-queued S-ATA command
On Sep 25, 2013, at 9:02 AM, Michael Cronenworth m...@cchtml.com wrote:
Chris Murphy wrote:
So as it turns out some devices get really busy and slow down when TRIM is
used, so not all devices are well suited for discard and therefore it's
probably not a good idea for it to be set
On Sep 25, 2013, at 10:48 AM, Michael Cronenworth m...@cchtml.com wrote:
Chris Murphy wrote:
https://patrick-nagel.net/blog/archives/337
He provides no reliable testing method. I don't consider his results to be
scientific or useful. One blogger will not be enough evidence.
You say
? And is the main idea in
this roll out just to support the better faster thinp snapshots? Or am I
missing something?
Thanks,
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code
attached, no destination for installation.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Sep 27, 2013, at 12:59 PM, Alasdair G Kergon a...@redhat.com wrote:
On Fri, Sep 27, 2013 at 11:55:43AM -0600, Chris Murphy wrote:
I still can't choose a Desired Capacity that's larger than free space
in the VG. Ergo, I can't create a virtual size LV. Is this expected?
At this stage
On Sep 30, 2013, at 10:34 AM, Alasdair G Kergon a...@redhat.com wrote:
On Mon, Sep 30, 2013 at 10:04:08AM -0600, Chris Murphy wrote:
For an LV to take advantage of thinp snapshots needs to be a virtual
size LV drawn from the thin pool, correct? So it is a virtual size LV
in any case, it's
one naming convention in
its UI, but upon reboot the installed system uses a different naming
convention. And neither convention helps me know which of two ethernets are
being used.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo
now, and it's always reporting pXpY even though anaconda
reports enp* or enc* or whatever.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
, that's
merely in opposition with another, is the way forward.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
it manually with patch -p0 -R ?
Chris Murphy--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
what you want to mount needs to be formatted ext234 at this
stage of the startup process. It may even need to be ext2.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code
on Windows, since HP released My Display as a
separate program), but again I'm not sure.
You'd have to reverse engineer or ask HP/Apple what they actually do for this
to work.
then implement that.
Or maybe Intel would be forthcoming. It's their hardware.
Chris Murphy
--
devel mailing list
devel
On Oct 15, 2013, at 10:36 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
On Tue, Oct 15, 2013 at 09:36:32AM -0600, Chris Murphy wrote:
Or maybe Intel would be forthcoming. It's their hardware.
Not in this case. Target display mode is a vendor extension, and
switching it will be vendor
potential for fs corruption in the face of unclean shutdowns, compared to a
non-cached hard drive… assuming there are no bugs that make this supposition
wrong.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code
, but I'm wondering if it should work. If not, is there a rough
time frame on such support?
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Oct 15, 2013, at 3:46 PM, Richard W.M. Jones rjo...@redhat.com wrote:
On Tue, Oct 15, 2013 at 03:29:38PM -0600, Chris Murphy wrote:
The better snapshots sound ideal for VM testing. Snapshot a
successful install and then try to break the snapshot. Etc.
Presently virt-manager ignores
On Oct 15, 2013, at 4:30 PM, Josh Stone jist...@redhat.com wrote:
On 10/15/2013 02:46 PM, Richard W.M. Jones wrote:
On Tue, Oct 15, 2013 at 03:29:38PM -0600, Chris Murphy wrote:
The better snapshots sound ideal for VM testing. Snapshot a
successful install and then try to break the snapshot
On Oct 15, 2013, at 4:29 PM, Richard W.M. Jones rjo...@redhat.com wrote:
On Tue, Oct 15, 2013 at 04:04:28PM -0600, Chris Murphy wrote:
I'm happy to hear it argued I should instead use the LV space for a
regular partition formatted ext2 and drop the qcow2 file
there. There's still overhead
.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Oct 16, 2013, at 1:50 PM, Richard W.M. Jones rjo...@redhat.com wrote:
On Wed, Oct 16, 2013 at 01:09:25PM -0600, Chris Murphy wrote:
Caching mode was none in all prior cases.
Note that cache=none is almost never useful. It bypasses the host
cache so you don't get the benefit of having
On Oct 16, 2013, at 1:09 PM, Chris Murphy li...@colorremedies.com wrote:
I made the suggested cache change for both LVM and qcow2; and created the
qcow2 file as suggested (adding lazy_refcount):
Fedora 20 default standard partition guided install (ext4) to an LV takes
18m02s
On Oct 16, 2013, at 1:09 PM, Chris Murphy li...@colorremedies.com wrote:
Fedora 20 default BTRFS guided install to qcow2 on XFS, install time 17m21s.
Firstboot systemd-analyze:
874ms (kernel) + 1.558s (initrd) + 12.866s (userspace) = 15.300s
From above, two changes: 1. Use virt-manager
On Oct 17, 2013, at 10:22 AM, Chris Murphy li...@colorremedies.com wrote:
So whatever options virt-manager is using to create qcow2 files, is either
the same as -o preallocation=metadata,compat=1.1,lazy_refcounts=on, or any
difference in options isn't making a difference in performance
On Oct 17, 2013, at 1:57 PM, Pádraig Brady p...@draigbrady.com wrote:
On 10/17/2013 07:09 PM, Chris Murphy wrote:
On Oct 17, 2013, at 10:22 AM, Chris Murphy li...@colorremedies.com wrote:
So whatever options virt-manager is using to create qcow2 files, is either
the same as -o
, they don't need to
be in fstab. There are few bugs filed as a result of the ensuing confusion. So
it might be new behavior in anaconda 20.25.1 to ignore the request to reuse
existing swap by adding it to fstab since it knows systemd is going to use it
in any case.
Chris Murphy
--
devel mailing list
/should systemd use
UniquePartitionGUID in the GPT for swap partitions rather than the swap volume
format UUID? The UniquePartitionGUID is more stable.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct
it until the other GPT is toast. And the UEFI spec amusingly requires the
user be asked for confirmation before restoring a primary GPT, which is
probably not in either the kernel nor systemd's job description.
So that's why I ask if it makes sense to have an fsck for GPT disks.
Chris Murphy
1 - 100 of 2034 matches
Mail list logo
