llation, additionally
creating BIOS Boot partition, and run a post install script that does
`grub2-install --target=i386-pc` to add the BIOS bootloader?
Thoughts?
[1]
https://pagure.io/cloud-sig/issue/330
[2]
https://pagure.io/cloud-sig/issue/309
--
Chris Murphy
___
On Tue, Feb 9, 2021 at 12:41 PM Matthew Miller wrote:
>
> On Tue, Feb 09, 2021 at 11:36:34AM -0700, Chris Murphy wrote:
> > Anaconda requires a new subvolume for / but doesn't require a
> > reformat. The Custom UI shows the / mountpoint's reformat checkbox
> > g
On Tue, Feb 9, 2021 at 12:26 PM Chris Murphy wrote:
>
> On Tue, Feb 9, 2021 at 11:40 AM Martin Kolman wrote:
> >
> > On Tue, 2021-02-09 at 09:50 -0700, Chris Murphy wrote:
> > > On Tue, Feb 9, 2021 at 9:15 AM Michel Alexandre Salim
> > > wrote:
> > >
On Tue, Feb 9, 2021 at 11:40 AM Martin Kolman wrote:
>
> On Tue, 2021-02-09 at 09:50 -0700, Chris Murphy wrote:
> > On Tue, Feb 9, 2021 at 9:15 AM Michel Alexandre Salim
> > wrote:
> > > There's a further complication: Chris just informed me that on BIOS
&
grayed out and checked, which might give the impression that whole
partition will be reformatted. It's confusing but just a cosmetic UI
anomaly.
There is a way to do this with kickstart, btrfs --mkfsoptions
https://pykickstart.readthedocs.io/en/latest/ki
mfs are already compressed.
So if it's not difficult to exclude compression on /boot/ that's
probably preferred?
--
Chris Murphy
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
'm thinking it needs
to go somewhere in:
https://github.com/storaged-project/blivet/blob/3.4-devel/blivet/devices/btrfs.py
Am I on the right track, or does it need to go somewhere else, or in
addition to that?
Thanks,
--
Chris Murphy
___
Anac
is already in libblockdev.
But it's missing a minimum size check. That issue is referenced in the
fedora-btrfs#35 issue. I'm not sure where it belongs, but there
probably needs to be a check for number of devices and only support
shrink on single device Btrfs.
--
Chris Murphy
On Thu, Jul 16, 2020 at 6:41 AM Vendula Poncova wrote:
>
> On Thu, Jul 16, 2020 at 7:13 AM Chris Murphy wrote:
>>
>> I've tested some images and this is going OK for the Live ISOs, but
>> the boot.iso based images like netinstallers and dvds (silverblue,
>>
I think this
is also known as minimal package set) installation I used when doing
an Everything netinstall installation.
---
Chris Murphy
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Mon, Jul 13, 2020 at 5:38 AM Vendula Poncova wrote:
>
> On Fri, Jul 10, 2020 at 6:14 PM Chris Murphy wrote:
>>
>>
>>
>> On Thu, Jul 9, 2020, 12:58 PM Chris Murphy wrote:
>>>
>>> Use zram-generator instead of zram
>>> https://pagure.io/
On Thu, Jul 9, 2020, 12:58 PM Chris Murphy wrote:
> Use zram-generator instead of zram
> https://pagure.io/fedora-comps/pull-request/513
>
> Replace 'zram' with 'zram-generator', and exclude Cloud edition
> https://pagure.io/fedora-kickstarts/pull-reque
t.org/rpms/rust-zram-generator/pull-request/3#
I'll report back when these have been accepted, and then this can happen:
Replace the zram service
https://github.com/rhinstaller/anaconda/pull/2727
Thanks,
--
Chris Murphy
___
Anaconda-devel-list ma
On Thu, Jul 9, 2020 at 11:20 AM Brian C. Lane wrote:
>
> On Thu, Jul 09, 2020 at 09:21:31AM -0600, Chris Murphy wrote:
> > On Thu, Jul 9, 2020 at 7:27 AM Chris Murphy wrote:
> >
> > I've opened an issue with upstream zram-generator folks. Igor suggests
> >
On Thu, Jul 9, 2020 at 7:27 AM Chris Murphy wrote:
>
> One item I haven't worked through yet is how 'inst.zram' should
> inhibit the zram-generator. The generator runs during early boot.
>
> My current thinking is 'inst.zram' can just 'systemctl st
On Thu, Jul 9, 2020 at 5:33 AM Vendula Poncova wrote:
>
> On Thu, Jul 9, 2020 at 4:26 AM Chris Murphy wrote:
>>
>> Hi,
>>
>> I am confused. For default partitioning, the idea is to no longr
>> create a swap partition, instead there will be both zram-gene
all of the ks files
that contain 'autopart' also contain '--noswap'. Yet Workstation
edition and others, do have a swap partition created. Suggestions?
Thanks,
Chris Murphy
___
Anaconda-devel-list mailing list
Anaconda-devel-l
r.
The best experience performance wise would be to have the two swaps.
They gain from swap-on-zram at first, and perhaps mostly. Followed by
the secondary use of disk based swap. But I'm not opposed to disabling
zram-generator in this case. It is a more conservative option and
might better sq
ay forward. The references lead to quite
a lot of conversations and additional references. Also it's likely
permanently a draft because, well things are always changing, the
story doesn't yet have a conclusion. But in the meantime we need to
move forward the best
On Tue, Jun 2, 2020 at 10:13 AM Chris Murphy wrote:
>
> Yeah it's hard to find. In koji it's rust-zram-generator metapackage;
> but the actual command to try it out is 'dnf install zram-generator'.
>
I should have just pointed to this:
https://fedorapro
se openQA tests to face plant.
The openQA tests I think are the most likely impacted, if there are
two zram devices, since most of those VMs use 2G RAM and thus will
trigger the anaconda implementation to also create a zram device.
For most everyone else doing testing, they'll have more than 2G
Found this:
https://github.com/rhinstaller/anaconda/blob/master/scripts/zramswapon#L52
I'm not sure where that should live, if this script is removed.
--
Chris Murphy
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
planned
Critical feedback welcome.
--
Chris Murphy
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
ntributors get the information they need to know their
efforts are worthwhile? I have hundreds of hours invested in Anaconda
testing, perhaps 1/2 not related to Btrfs, over ~8 years. I would like
answers to these questions.
--
Chris Murphy
___
Anaconda-
ion.
And another question for QA. If it were Btrfs by default for
Workstation, would you just convert all the tests that rely only on
ext4 now to Btrfs? Or duplicate those tests so you can run them in
parallel? How much more testing is that and what's the impact on time
and resources?
--
Chri
On Tue, Aug 27, 2019 at 1:02 PM David Cantrell wrote:
>
> On 8/27/19 2:00 PM, Chris Murphy wrote:
> > The Fedora working group's technical specification states Btrfs is to
> > be the default. Yet the working group has said it's uncomfortable
> > taking action
t.org/archives/list/de...@lists.fedoraproject.org/message/CXW6IYIHETPS5U7IB2P6373FJDU2UAMB/
---
Chris Murphy
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Tue, Aug 27, 2019 at 12:00 PM Chris Murphy wrote:
> The Fedora working group's technical specification states Btrfs is to
> be the default. Yet the working group has said it's uncomfortable
> taking action on this decision expressly because the Federal kernel
> team
indeed.
> I'm not advocating one way or another for btrfs. But it seems we as a
> project need a larger decision and policy around btrfs in general so we
> can set expectations for users and developers.
That decision and policy has already been made. Do you want it reverted?
--
ed in Btrfs, but it's a very different thing if there's
resistance to it, and I'm getting a lot of language that is compatible
with resisting Btrfs no matter what.
[1]
https://bugzilla.redhat.com/show_bug.cgi?id=1717728#c10
--
Chris Murphy
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
t did.
It is completely reasonable for Red Hat to have maintainability
concerns about Btrfs for RHEL, and it's entirely fair for Red Hat to
have a bias against it. If it were true that Red Hat is, however
unintentionally, injecting its Btrfs bias i
ow who I am, even though I can't code my way
out of a hat. They've always been responsive when I show them bugs I
can reproduce.
--
Chris Murphy
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
re attention.
That's understandable and reasonable. I don't think anyone
uninterested in supporting Btrfs should be made to feel like they
ought to. Life is short, do what you're interested in doing, no more.
--
Chris Murphy
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
we'd just be
stuck until it got fixed. That work would have to be done upstream,
yes?
--
Chris Murphy
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
https://fedoraproject.org/wiki/Basic_Release_Criteria#System_logging
--
Chris Murphy
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
up /dev/urandom key
based encryption for it.
Also, there is a package, zram-0.3-1.fc30.noarch, which is more
recently developed and intended to be generic use. Any chance of
deprecating the anaconda zram stuff and depending on this zram package
ins
r something else.
Thanks,
--
Chris Murphy
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
ying there shouldn't be an /etc/multipath.conf file
already there, so that (basically) the anaconda call to mpathconf
causes the correctly formed /etc/multipath.conf file to be created.
--
Chris Murphy
___
Anaconda-devel-list mailing list
Anaco
as filed back in December.
Near as I can tell, no one's been able to do live installations of
Rawhide in about two months. I can reproduce it in a clean
virt-manager VM, and on baremetal.
Does this bug need info to get it fixed? I'm unclear what the hold
replicating an installation environment while troubleshooting
this bug:
So the questions are:
Is there a chroot?
Is there a way to discover the command being used?
And if there is a chroot, is there a way to log this command in the future?
https://bugzilla.redhat.com/show_bug.cgi?id=1289752
Thanks,
-
f the problem. I'm just trying to _maximize_ a GPT disk label's
> compatibility.
Required partitions should be created automatically by the thing that
requires them. If the Windows 7 or 8 installer doesn't create an MSR
into free space, that's a Microsoft bug
On Fri, Apr 22, 2016 at 12:08 AM, Chris Murphy wrote:
> On Mon, Apr 18, 2016 at 12:00 PM, Chris Lumens wrote:
>>> CL> The fix is to make /boot larger so more kernels can fit, say, 1GB.
>>>
>>> Doesn't Fedora have the same basic issue, though? My 500M /boot
s the first time I've ever
heard of this issue and when I tried to reproduce the problem, I
couldn't.
[1]
"It is particularly important that the MSR be created before other
primary data partitions."
https://msdn.microsoft.com/en-us/library/windows/hardware/dn640535%28v=vs.85
On Fri, Apr 22, 2016 at 2:28 AM, Bryan Smith wrote:
> Chris Murphy wrote:
>> You want to support installing Windows after Fedora? Why?
>
> No, I merely suggested we consider adding the _option_, with a
> checkbox, to Anaconda so it creates a GPT disk label that is
> compat
on. I've got kernel 4.5.2 nondebug
and kernel+initramfs+system.map takes up 30M in /boot, and 4.6.0.rc4
debug takes up 31M. So...? Fedora uses hostonly initramfs. Is that a
factor? Even if I go that route, it's only 59M for the debug kernel
and its initramfs and map. I don't
On Mon, Apr 18, 2016 at 12:28 PM, Bryan Smith wrote:
> Brian C. Lane wrote:
>> It's probably worth filing a bug about.
>
> Yeah, I might file a bug that is a bit "more broad," especially after
> Chris Murphy pointed out his [bz#1046577].
>
> E.g., in addit
expected to support FAT32, FAT16, and FAT12 so
it probably doesn't matter that the spec also says the system
partition (non-removable) should be FAT32, where only removables get
FAT16 or FAT12. The other thing -E would make possible is ensuring the
proper invariant "EFI file system"
clarify it: Unintended data loss of user valued data in
guided partitioning, where many prognostications where made by
Anaconda folks how data safe it is designed to be, is possible. And
yet no matter how many more people hit it, it would not be considered
a blocker.
It's a bad bug in cust
ly affects
OS X users with the default partitioning layout now in use on that OS,
and then the user proceeds with resizing this unknown partition for
whatever reason. Fix it whenever you want. Maybe someone beats you to
it. And consider trusting QA to
49 matches
Mail list logo
