00:00 <jdoss> I ran sgdisk --zap-all again while in the emergency shell and it worked fine.

02:19 <jdoss> Blah. More issues. Timeouts on partitioning now. https://usercontent.irccloud-cdn.com/file/VdBMuHvg/image.png

02:20 <jdoss> err on making the filesystems

02:27 <bgilbert> jdoss: haven't seen the first error before, odd

02:27 <bgilbert> could you post your Ignition config?

02:28 <bgilbert> or Butane, preferably

02:28 <jdoss> I ran into another one where you can't have the md named `/dev/md/root` specifically.

02:28 <jdoss> yah let me toss it up on a gist and clean it of my super secret secrets

02:33 <jdoss> bgilbert: https://gist.github.com/jdoss/0964f4c7572f6b76e9cdc9ac3658a7e9

02:33 <jdoss> I figure this is the only important thing since it is what is failing.

02:34 <bgilbert> jdoss: hmm. is the idea that you're booting from a different disk than any of these?

02:34 <jdoss> booting from the RAID

02:35 <bgilbert> well, you're not using the boot_device sugar, which is okay, but then you're responsible for _all_ of the partitioning

02:35 <bgilbert> this doesn't have /boot or the ESP

02:35 <bgilbert> (or the BIOS boot partition, in case you're BIOS booting)

02:35 <jdoss> ok I can add that in, but it's not timing out on that stuff

02:35 <jdoss> I will add it in and give it another go

02:35 <bgilbert> I understand

02:36 <bgilbert> but I can guarantee that this config won't work :-)

02:36 <bgilbert> any reason you don't want to use the sugar?

02:36 <jdoss> fair, fair.

02:36 <jdoss> I don't know what I don't know at this point. This is my first shot at using the RAID features in FCOS.

02:37 <bgilbert> I'd recommend you use the sugar if you don't have a reason to do otherwise

02:37 <bgilbert> last example in https://docs.fedoraproject.org/en-US/fedora-coreos/storage/#_reconfiguring_the_root_filesystem

02:39 <bgilbert> and the other problem is that "device: /dev/disk/by-partlabel/var-home" isn't correct

02:39 <bgilbert> there's a var-home RAID array but no var-home GPT partition

02:41 <jdoss> I guess I am not following.

02:43 <bgilbert> line 45 should be "device: /dev/md/var-home"

02:43 <jdoss> Yep, gahh!

02:44 <jdoss> Can I use by-id/wwn- IDs for the boot sugar?

02:44 <jdoss> or do I need to use /dev/sda etc

02:45 <bgilbert> I think the WWNs should work

02:45 <jdoss> I'll give it a shot

02:45 <jdoss> Stupid mistake on my end on that partition. Thanks for that.

02:48 <bgilbert> np!

02:49 <jdoss> bgilbert: Reprovisoning now. I will let you know how it goes

02:49 <bgilbert> +1

03:52 <jdoss> bgilbert No dice. Another error I think related to adding in the boot sugar with old partitions already present https://usercontent.irccloud-cdn.com/file/8WDGQ824/image.png

03:52 <bgilbert> could you post your new config?

03:54 <bgilbert> jdoss: ^

03:54 <jdoss> updating that gist sec

03:55 <jdoss> bgilbert: https://gist.github.com/jdoss/0964f4c7572f6b76e9cdc9ac3658a7e9 current.yaml

03:57 <bgilbert> jdoss: if you run that through Butane, you'll see it produces a bit of a mess wrt partition tables

03:57 <bgilbert> you have some redundant stuff in there

03:57 <bgilbert> Butane will let you do some overriding of the desugared output, but you have to match it

03:59 <bgilbert> I'd drop the wipe_table on the rootfs disks (technically correct, but confusing) and the start_mib and number on raid-root-1, then rename it to root-1 to match Butane

03:59 <bgilbert> doesn't work, hmm

04:00 <jdoss> updated that gist

04:01 <bgilbert> does work; I had typoed my copy

04:01 <jdoss> Story of my life.

04:02 <bgilbert> oh, and stop defining fcos-root

04:02 <bgilbert> raid or filesystem. Butane will do that

04:03 <jdoss> Remove the filesystem directives for fcos-root

04:03 <jdoss> and remove wipe_table on partitions

04:04 <bgilbert> here's what I've got: https://gist.github.com/bgilbert/cd8dd6c3ff0f19e43365518333ba5d6f

04:04 <bgilbert> also removed a few redundant keys

04:05 <jdoss> how does butane know that I want RAID1 or is that the default?

04:05 <jdoss> on the root

04:06 <bgilbert> boot_device.mirror only supports RAID1

04:06 <bgilbert> however

04:06 <bgilbert> I think you can define a RAID device matching the name Butane picks, and specify a different RAID level

04:07 <bgilbert> sugar is supposed to be overridable in a natural way

04:07 <jdoss> your example is confusing at first

04:08 <jdoss> I thought you ditched some raid directives but they are just combo'ed (line 14 for example)

04:09 <bgilbert> I ditched some stuff that just restates the defaults

04:09 <jdoss> I am going to try and document that better.

04:09 <bgilbert> sure

04:15 <jdoss> bgilbert: Reprovisoning

04:41 <jdoss> bgilbert: hell yeah we are up

04:41 <bgilbert> 🎉

13:05 <aleskandro[m]> hello, some time ago, I overrode the kernel package to use in an installation via rpm-ostree override replace --experimental --from repo=..... Now, I want to upgrade to a new base image that ships a new kernel and I get into an error as the new kernel packages conflict with the layered ones. The update is being done from a base image to the new one available in a remote registry with rpm-ostree update (ie., not rebasing to a

13:05 <aleskandro[m]> new image-tag pair). Is there a specific procedure I should follow to avoid removing the layered kernel, upgrade and layering again?

13:35 <travier[m]> aleskandro: If you have a local override and want to use the new kernel from the new image then you need to rpm-ostree override reset to remove the local override

13:54 <aleskandro[m]> Hi travier I don't want to use the new kernel but want to keep on that. It's actually a remoteOverride, not a local one

13:55 <aleskandro[m]> s/that/the version I overrode with/

14:35 <travier[m]> aleskandro: I don't understand what you have, what you're pulling, what you want. Maybe you should write a more descriptive post on the forums so that we can answer that