misuto7 has quit [Remote host closed the connection]
misuto7 has joined #fedora-coreos
misuto7 has quit [Remote host closed the connection]
misuto7 has joined #fedora-coreos
misuto7 has quit [Remote host closed the connection]
misuto7 has joined #fedora-coreos
zodbot has quit [Remote host closed the connection]
zodbot has joined #fedora-coreos
misuto7 has quit [Ping timeout: 268 seconds]
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 268 seconds]
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 268 seconds]
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 246 seconds]
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 240 seconds]
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 256 seconds]
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 240 seconds]
jpn has joined #fedora-coreos
Betal has quit [Quit: WeeChat 3.8]
raism has joined #fedora-coreos
raism has quit [Quit: WeeChat 3.8]
raism has joined #fedora-coreos
jpn has quit [Ping timeout: 268 seconds]
fifofonix_ has joined #fedora-coreos
fifofonix_ has quit [Ping timeout: 240 seconds]
fifofonix[m]1 has joined #fedora-coreos
fifofonix[m]1 has quit [Remote host closed the connection]
fifofonix[m]1 has joined #fedora-coreos
cydox[m] has joined #fedora-coreos
raism has quit [Ping timeout: 240 seconds]
fifofonix_ has joined #fedora-coreos
fifofonix_ has quit [Client Quit]
<fifofonix[m]1>
I don
<fifofonix[m]1>
I don't think there is an arm64 ova that can be used with VMWare Fusion on Apple Silicon. Is there an issue there?
JohnnyArcitec[m4 has joined #fedora-coreos
<JohnnyArcitec[m4>
Hi. How is CoreOS building the OCI container layers in a way that re-uses old layers if the package files haven't been changed? Let's say you're installing 500mb of packages into a few different layers. Every time you `rpm-ostree install` something, it updates the RPM database and creates a "modified" layer anyway, so the old files can't be re-used. Are you therefore using some special tool to generate layers from the pure,
<JohnnyArcitec[m4>
raw, extracted RPM files independently of the RPM database?
<JohnnyArcitec[m4>
* Hi. How is CoreOS building the OCI container layers in a way that re-uses old layers if the package files haven't been changed? Let's say you're installing 500mb of packages into a few different layers. Every time you `rpm-ostree install` something, it updates the RPM database and creates a "modified" layer anyway, so the old layers can't be re-used since they'll be "modified" after every install. Are you therefore using
<JohnnyArcitec[m4>
some special tool to generate layers from the pure, raw, extracted RPM files independently of the RPM database?
<JohnnyArcitec[m4>
* Hi. How is CoreOS building the OCI container layers in a way that re-uses old layers if the package files haven't been changed? Let's say you're installing 500mb of packages into a few different layers. Every time you `rpm-ostree install` something, it updates the RPM database and creates a "modified" layer anyway, so the old layers can't be re-used since they'll be "modified" after every install. Are you therefore using
<JohnnyArcitec[m4>
some special tool to generate OCI layers from the pure, raw, extracted RPM files independently of the RPM database?
<JohnnyArcitec[m4>
* Hi. How is CoreOS building the OCI container layers in a way that re-uses old layers if the package files haven't been changed? Let's say you're installing 500mb of packages into a few different layers. Every time you `rpm-ostree install` something, it updates the RPM database and creates a "modified" layer anyway, so the old layers can't be re-used since they'll be "modified" after every install. Are you therefore using
<JohnnyArcitec[m4>
some special tool to generate OCI layers from the pure, raw, extracted RPM files independently of the RPM database? In short: How are you making the layers that can stay static until the package versions/files actually change?
<JohnnyArcitec[m4>
* Hi. How is CoreOS building the OCI container layers in a way that re-uses old layers if the package files haven't been changed?
<JohnnyArcitec[m4>
Let's say you're installing 500mb of packages into a few different layers. Every time you `rpm-ostree install` something, it updates the RPM database and creates a "modified" layer anyway, so the old layers can't be re-used since they'll be "modified" after every install.
<JohnnyArcitec[m4>
Are you therefore using some special tool to generate OCI layers from the pure, raw, extracted RPM files independently of the RPM database? In short: How are you making the layers that can stay static until the package versions/files actually change?
<JohnnyArcitec[m4>
* Hi. How is CoreOS building the OCI container layers in a way that re-uses old layers if the package files haven't been changed?
<JohnnyArcitec[m4>
Let's say you're installing 500mb of packages into a few different layers, optimized to make online updates as small as possible by re-using the same layers for as long as nothing in them has changed. But the problem is that every time you `rpm-ostree install` something, it updates the RPM database and creates a "modified" layer anyway, so the old layers can't be re-used since they'll be "modified" after every install during
<JohnnyArcitec[m4>
our "build" script.
<JohnnyArcitec[m4>
Somehow, CoreOS and Silverblue OCI have solved this issue. Are you therefore using some special tool to generate OCI layers from the pure, raw, extracted RPM files independently of the RPM database? In short: How are you making the layers that can stay static until the package versions/files actually change?
<JohnnyArcitec[m4>
* Hi. How is CoreOS building the OCI container layers in a way that re-uses old layers if the package files haven't been changed?
<JohnnyArcitec[m4>
our "build" script.
<JohnnyArcitec[m4>
Somehow, CoreOS and Silverblue OCI have solved this issue. Are you therefore using some special tool to generate OCI layers from the pure, raw, extracted RPM files independently of the RPM database? In short: How are you making the layers that can stay static until the actual package files/versions actually change?
<JohnnyArcitec[m4>
Let's say you're installing 500mb of packages into a few different layers, optimized to make online updates as small as possible by re-using the same layers for as long as nothing in them has changed. But the problem is that every time you `rpm-ostree install` something, it updates the RPM database and creates a "modified" layer anyway, so the old layers can't be re-used since they'll be "modified" after every install during
<JohnnyArcitec[m4>
* Hi. How is CoreOS building the OCI container layers in a way that re-uses old layers if the package files haven't been changed?
<JohnnyArcitec[m4>
Let's say you're creating Silverblue OCI by installing 500mb of packages into a few different layers, optimized to make online updates as small as possible by re-using the same layers for as long as nothing in them has changed. But the problem is that every time you `rpm-ostree install` something, it updates the RPM database and creates a "modified" layer anyway, so the old layers can't be re-used since they'll be "modified"
<JohnnyArcitec[m4>
Somehow, CoreOS and Silverblue OCI have solved this issue. Are you therefore using some special tool to generate OCI layers from the pure, raw, extracted RPM files independently of the RPM database? In short: How are you making the layers that can stay static until the actual package files/versions actually change?
<JohnnyArcitec[m4>
after every install during our "build" script.
<JohnnyArcitec[m4>
* Hi. How is CoreOS building the OCI container layers in a way that re-uses old layers if the package files haven't been changed?
<JohnnyArcitec[m4>
Let's say you're creating Silverblue OCI by installing 500mb of packages into a few different layers, optimized to make online updates as small as possible by re-using the same layers for as long as nothing in them has changed.
<JohnnyArcitec[m4>
I'm trying to figure out how you solved that. The problem for me is that every time you `rpm-ostree install` something, it updates the RPM database and creates a "modified" layer anyway, so the old layers can't be re-used since they'll be "modified" after every install during our "build" script.
<JohnnyArcitec[m4>
Somehow, CoreOS and Silverblue OCI have solved this issue. Are you therefore using some special tool to generate OCI layers from the pure, raw, extracted RPM files independently of the RPM database? In short: How are you making the layers that can stay static until the actual package files/versions actually change?
<JohnnyArcitec[m4>
* Hi. How is CoreOS building the OCI container layers in a way that re-uses old layers if the package files haven't been changed?
<JohnnyArcitec[m4>
Somehow, CoreOS and Silverblue OCI have solved this issue. Are you therefore using some special tool to generate OCI layers from the pure, raw, extracted RPM files independently of the RPM database? In short: How are you making the layers that can stay static until the actual package files/versions actually change?
<JohnnyArcitec[m4>
Let's say you're creating Silverblue OCI by installing 500mb of packages into a few different layers, optimized to make online updates as small as possible by re-using the same layers for as long as nothing in them has changed.
<JohnnyArcitec[m4>
I'm trying to figure out how you solved that. The problem for me is that every time you `rpm-ostree install` something, it updates the RPM database and creates a "modified" container layer anyway, so the old layers can't be re-used since they'll be "modified" after every install during our "build" script.
<JohnnyArcitec[m4>
* Hi. How is CoreOS building the OCI container layers in a way that re-uses old layers if the package files haven't been changed?
<JohnnyArcitec[m4>
Let's say you're creating Silverblue OCI by installing 500mb of packages into a few different layers, optimized to make online updates as small as possible by re-using the same layers for as long as nothing in them has changed.
<JohnnyArcitec[m4>
I'm trying to figure out how you solved that. The problem for me is that every time you `rpm-ostree install` something, it updates the RPM database and creates a "modified" container layer anyway, so the old layers can't be re-used since they'll be "modified" after every install during our "build" script. Therefore, I'm generating 1.2 GB of "updated" layers every day. Even when nothing changed. :(
<JohnnyArcitec[m4>
Somehow, CoreOS and Silverblue OCI have solved this issue. Are you therefore using some special tool to generate OCI layers from the pure, raw, extracted RPM files independently of the RPM database? In short: How are you making the layers that can stay static until the actual package files/versions actually change?
fifofonix[m]1 has quit [Remote host closed the connection]
fifofonix[m]1 has joined #fedora-coreos
<dustymabe>
fifofonix[m]1: I think a good way to get started on apple silicon macs may be podman machine. I don't think we have any arm64 VMWare images
<dustymabe>
though IIUC apple silicon runs x86_64 pretty well so I wouldn't be surprised if using Fusion with the x86_64 image did work
gursewak has joined #fedora-coreos
<fifofonix[m]1>
<dustymabe> "though IIUC apple silicon runs x..." <- Podman machine is a good idea and I will try it (long time since I used docker machine but I get the concept) although it would be good to be able to run through VMWare Fusion too so +1 for an arm64 OVA. Rosetta translation of executables does run well on Apple Silicon but I don't think you can run VMs that way
<dustymabe>
fifofonix[m]1: I'd say open an issue in the tracker with the request
<dustymabe>
you should be able to skip some of the questions because the platform already exists, it just needs to be enabled for the new architecture
<fifofonix[m]1>
dustymabe: will do, thanks! +1
jpn has joined #fedora-coreos
sashin[m] has joined #fedora-coreos
jpn has quit [Ping timeout: 240 seconds]
<sashin[m]>
How do I do this on core os?
<sashin[m]>
I'm trying to mount some block storage (in my case /dev/vdb) to my home directory (/var/home/sashin) in such a way that it's persistent
<sashin[m]>
Is the only way through providing ignition configuration? If this is the case, is it something that needs to be sorted before building the image (do I have to provide new configuration and install?)
<jmariondev>
You're on the right track with the systemd mount unit. You can include it in your Butane config to have it created on installation, but you can also create it manually in /etc/systemd/system/var-home-sashin.mount afterwards if you don't want to reinstall
<sashin[m]>
thanks!
<sashin[m]>
yeah, that would save me a bunch of trouble!
<jmariondev>
Or ultimately create it manually to debug it, then add it to your butane config for future installs 👍️
<sashin[m]>
Seems to be working, thanks for everything!!
<jmariondev>
Nice!
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 240 seconds]
misuto7 has joined #fedora-coreos
misuto7 has quit [Ping timeout: 246 seconds]
misuto7 has joined #fedora-coreos
daMaestro has joined #fedora-coreos
misuto7 has quit [Remote host closed the connection]