On Thu, Dec 30, 2021 at 3:59 PM Chris Murphy wrote:
>
> ZFS uses volume and user properties which we could probably mimic with
> xattr. I thought I asked about xattr instead of subvolume names at one
> point in the thread but I don't see it. So instead of using subvolume
> names, what about stuffi
(I'm sorta not doing a great job of using "sub-volume" to mean
generically any of Btrfs subvolume or a directory or a logical volume,
so hopefully anyone still following can make the leap that I don't
intend this spec to be Btrfs specific. I like it being general
purpose.)
On Tue, Dec 21, 2021 at
On Tue, Dec 21, 2021 at 6:57 AM Ludwig Nussel wrote:
>
> Chris Murphy wrote:
> > The part I'm having a hard time separating is the implicit case (use
> > some logic to assemble the correct objects), versus explicit (the
> > bootloader snippet points to a root and the root contains an fstab -
> >
Chris Murphy wrote:
> On Tue, Nov 9, 2021 at 8:48 AM Ludwig Nussel wrote:
>> Lennart Poettering wrote:
>>> Or to say this explicitly: we could define the spec to say that if
>>> we encounter:
>>>
>>>/@auto/root-x86-64:fedora_36.0+3-0
>>>
>>> on first boot attempt we'd rename it:
>>>
>>>/@a
On Fr, 10.12.21 12:25, Chris Murphy (li...@colorremedies.com) wrote:
> On Thu, Nov 11, 2021 at 12:28 PM Lennart Poettering
> wrote:
>
> > That said: naked squashfs sucks. Always wrap your squashfs in a GPT
> > wrapper to make things self-descriptive.
>
> Do you mean the image file contains a GPT,
>>> Chris Murphy schrieb am 10.12.2021 um 16:59 in
Nachricht
:
> On Mon, Nov 22, 2021 at 3:02 AM Ulrich Windl
> wrote:
>>
>> >>> Lennart Poettering schrieb am 19.11.2021 um
>> >>> 10:17
>> in
>> Nachricht :
>> > On Do, 18.11.21 14:51, Chris Murphy (li...@colorremedies.com) wrote:
>> >
>> >> How
On Thu, Nov 4, 2021 at 9:39 AM Lennart Poettering
wrote:
> 3. Inside the "@auto" dir of the "super-root" fs, have dirs named
>[:]. The type should have a similar vocubulary
>as the GPT spec type UUIDs, but probably use textual identifiers
>rater than UUIDs, simply because naming dirs
On Thu, Nov 11, 2021 at 12:28 PM Lennart Poettering
wrote:
> That said: naked squashfs sucks. Always wrap your squashfs in a GPT
> wrapper to make things self-descriptive.
Do you mean the image file contains a GPT, and the squashfs is a
partition within the image? Does this recommendation apply
On Tue, Nov 9, 2021 at 3:57 PM Lennart Poettering
wrote:
> Now, at least in theory we could declare the same for this new
> directory auto-discovery scheme. But I am not entirely sure this will
> work out trivially IRL because I have the suspicion one cannot rename
> subvolumes which are the sour
On Tue, Nov 9, 2021 at 8:48 AM Ludwig Nussel wrote:
>
> Lennart Poettering wrote:
> > Or to say this explicitly: we could define the spec to say that if
> > we encounter:
> >
> >/@auto/root-x86-64:fedora_36.0+3-0
> >
> > on first boot attempt we'd rename it:
> >
> >/@auto/root-x86-64:fedor
On Fri, Nov 19, 2021 at 4:17 AM Lennart Poettering
wrote:
>
> On Do, 18.11.21 14:51, Chris Murphy (li...@colorremedies.com) wrote:
>
> > How to do swapfiles?
>
> Is this really a concept that deserves too much attention?
*shrug* Only insofar as I like order, and like the idea of agreeing on
where
On Mon, Nov 22, 2021 at 3:02 AM Ulrich Windl
wrote:
>
> >>> Lennart Poettering schrieb am 19.11.2021 um 10:17
> in
> Nachricht :
> > On Do, 18.11.21 14:51, Chris Murphy (li...@colorremedies.com) wrote:
> >
> >> How to do swapfiles?
> >
> > Is this really a concept that deserves too much attention
>>> Lennart Poettering schrieb am 19.11.2021 um 10:17
in
Nachricht :
> On Do, 18.11.21 14:51, Chris Murphy (li...@colorremedies.com) wrote:
>
>> How to do swapfiles?
>
> Is this really a concept that deserves too much attention? I mean, I
> have the suspicion that half the benefit of swap space
On Do, 18.11.21 15:01, Chris Murphy (li...@colorremedies.com) wrote:
> On Thu, Nov 18, 2021 at 2:51 PM Chris Murphy wrote:
> >
> > How to do swapfiles?
> >
> > Currently I'm creating a "swap" subvolume in the top-level of the file
> > system and /etc/fstab looks like this
> >
> > UUID=$FSUUID
On Do, 18.11.21 14:51, Chris Murphy (li...@colorremedies.com) wrote:
> How to do swapfiles?
Is this really a concept that deserves too much attention? I mean, I
have the suspicion that half the benefit of swap space is that it can
act as backing store for hibernation. But swap files are icky for
On Thu, Nov 18, 2021 at 2:51 PM Chris Murphy wrote:
>
> How to do swapfiles?
>
> Currently I'm creating a "swap" subvolume in the top-level of the file
> system and /etc/fstab looks like this
>
> UUID=$FSUUID/var/swap btrfs noatime,subvol=swap 0 0
> /var/swap/swapfile1 none swa
How to do swapfiles?
Currently I'm creating a "swap" subvolume in the top-level of the file
system and /etc/fstab looks like this
UUID=$FSUUID/var/swap btrfs noatime,subvol=swap 0 0
/var/swap/swapfile1 none swap defaults 0 0
This seems to work reliably after hundreds of boots
On 11.11.2021 19.27, Lennart Poettering wrote:
On Mi, 10.11.21 10:34, Topi Miettinen (toiwo...@gmail.com) wrote:
Doing this RootDirectory= would make a ton of sense too I guess, but
it's not as obvious there: we'd need to extend the setting a bit I
think to explicitly enable this logic. As oppo
On Do, 11.11.21 18:27, Lennart Poettering (mzerq...@0pointer.de) wrote:
> A patch for that should be pretty easy to do, and be very generically
> useful. I kinda like it. What do you think?
For now I added TODO list items for these ideas:
https://github.com/systemd/systemd/commit/af11e0ef843c19c
On Mi, 10.11.21 10:34, Topi Miettinen (toiwo...@gmail.com) wrote:
> > Doing this RootDirectory= would make a ton of sense too I guess, but
> > it's not as obvious there: we'd need to extend the setting a bit I
> > think to explicitly enable this logic. As opposed to the RootImage=
> > case (where
On 9.11.2021 23.03, Lennart Poettering wrote:
On Di, 09.11.21 19:48, Topi Miettinen (toiwo...@gmail.com) wrote:
i.e. we'd drop the counting suffix.
Could we have this automatic versioning scheme extended also to service
RootImages & RootDirectories as well? If the automatic versioning was als
On Di, 09.11.21 19:48, Topi Miettinen (toiwo...@gmail.com) wrote:
> > i.e. we'd drop the counting suffix.
>
> Could we have this automatic versioning scheme extended also to service
> RootImages & RootDirectories as well? If the automatic versioning was also
> extended to services, we could have A
On Di, 09.11.21 14:48, Ludwig Nussel (ludwig.nus...@suse.de) wrote:
> > and so on. Until boot succeeds in which case we'd rename it:
> >
> >/@auto/root-x86-64:fedora_36.0
> >
> > i.e. we'd drop the counting suffix.
>
> Thanks for the explanation and pointer!
>
> Need to think aloud a bit :-)
>
On 8.11.2021 17.32, Lennart Poettering wrote:
Besides the GPT auto-discovery where versioning is implemented the way
I mentioned, there's also the sd-boot boot loader which does roughly
the same kind of OS versioning with the boot entries it discovers. So
right now, you can already chose whether:
Lennart Poettering wrote:
> On Mo, 08.11.21 14:24, Ludwig Nussel (ludwig.nus...@suse.de) wrote:
> [...]
>> MicroOS has a similar situation. It edits /etc/fstab.
>
> microoos is a suse thing?
Yeah. https://get.opensuse.org/microos/
It uses regular package management but instead of installing rpms
On Mo, 08.11.21 14:24, Ludwig Nussel (ludwig.nus...@suse.de) wrote:
> Lennart Poettering wrote:
> > [...]
> > 3. Inside the "@auto" dir of the "super-root" fs, have dirs named
> >[:]. The type should have a similar vocubulary
> >as the GPT spec type UUIDs, but probably use textual identifi
Lennart Poettering wrote:
> [...]
> 3. Inside the "@auto" dir of the "super-root" fs, have dirs named
>[:]. The type should have a similar vocubulary
>as the GPT spec type UUIDs, but probably use textual identifiers
>rater than UUIDs, simply because naming dirs by uuids is
>weird. E
On Mi, 03.11.21 13:52, Chris Murphy (li...@colorremedies.com) wrote:
> There is a Discoverable Partitions Specification
> http://systemd.io/DISCOVERABLE_PARTITIONS/
>
> The problem with this for Btrfs, ZFS, and LVM is a single volume can
> represent multiple use cases via multiple volumes: subvolu
On 11/3/21 12:52 PM, Chris Murphy wrote:
There is a Discoverable Partitions Specification
http://systemd.io/DISCOVERABLE_PARTITIONS/
The problem with this for Btrfs, ZFS, and LVM is a single volume can
represent multiple use cases via multiple volumes: subvolumes (btrfs),
datasets (ZFS), and log
Lennart most recently (about a year ago) wrote on this in a mostly
unrelated Fedora devel@ thread. I've found the following relevant
excerpts and provide the source URL as well.
BTW, we once upon a time added a TODO list item of adding a btrfs
generator to systemd, similar to the existing GPT gene
There is a Discoverable Partitions Specification
http://systemd.io/DISCOVERABLE_PARTITIONS/
The problem with this for Btrfs, ZFS, and LVM is a single volume can
represent multiple use cases via multiple volumes: subvolumes (btrfs),
datasets (ZFS), and logical volumes (LVM). I'll just use the term
31 matches
Mail list logo
