user/transactional-update: new package

[tulilirockz]

OpenSuSE MicroOS's approach to immutability and its dependencies, depends on snapper - #2944

[tulilirockz]

should be good now

[tulilirockz]

also, ive noticed that it generates stuff with /sysroot. what directory does initramfs-tools generate for the new root? /newroot? /root? - probably should patch to make that work fine

[nekopsykose]

/init says rootmnt=/root and does stuff with that, so probably that, feel free to test

[tulilirockz]

yeah i also checked it out rn - probably will work with /root

[tulilirockz]

probably should make a initramfs script that mounts overlayfs /etc off of the user's fstab (if it is applied) then moves it over to /root/etc

[q66]

how does this even work at all? it seems to need dracut

also shouldn't it be called transactional-update

[q66]

i'm not really interested in packaging software that will conditionally break because of requiring random stuff depending on how you invoke it (i see references to... dracut, systemctl, ... and considering a lot of this consists of random shell that is presumably not tested on non-gnu userland, there is probably more, even if it "works" on the surface)

so i think this is only fine if you can guarantee that this stuff will not randomly break and that it won't be a net longer term maintenance burden

[tulilirockz]

how does this even work at all? it seems to need dracut

also shouldn't it be called transactional-update

Transactional-update is the OpenSUSE-specific implementation of this thing, tukit is just a snapper wrapper that makes is to you can do something like tukit execute apk upgrade and have the updates be applied on-boot if they worked

[tulilirockz]

i'm not really interested in packaging software that will conditionally break because of requiring random stuff depending on how you invoke it (i see references to... dracut, systemctl, ... and considering a lot of this consists of random shell that is presumably not tested on non-gnu userland, there is probably more, even if it "works" on the surface)

so i think this is only fine if you can guarantee that this stuff will not randomly break and that it won't be a net longer term maintenance burden

Most of these dependencies only appear on the tukitd thing which is not necessary for the usage of this system, you can totally just go with tukit and ur good to go. Transacional-update is also not necessary due to it just straight up being an OpenSUSE tool, so no need to worry about the shell wrapper

[tulilirockz]

The dracut dependency is also just for making it so the initramfs mounts /etc as an overlayfs like this fstab entry overlayfs /etc overlay defaults,lowerdir=/root/var/lib/overlay/15/etc:/root/etc,upperdir=/root/var/lib/overlay/17/etc,workdir=/root/var/lib/overlay/17/work-etc 0 2.

[tulilirockz]

i just added the initramfs hooks! they work completely fine apparently (although there is a warning when running update-initramfs). everything else, like etc cleanup or whatever should be implemented by a higher level tool (like transactional-update on suse) - this should actually totally be good to go now! would this be welcome or is it better not to merge?

[q66]

i don't really understand why it's the initramfs that needs to mount that, why can't it be done after initramfs by early dinit services?

[q66]

also as far as i can tell the package should still be called transactional-update as that's the name of the repo/project

also i don't see any reason to leave out tukitd? it only depends on sd-bus api (you can supply it with basu or elogind, preferably the former here) and the systemd service seems optional (the dbus service has traditional activation) so you can just not install it

[tulilirockz]

also as far as i can tell the package should still be called transactional-update as that's the name of the repo/project

i mean, at this point it is just a naming thing - i just think that it makes more sense for it to be "tukit" since we arent really messing around wirh the transactional-update cli, right?

[tulilirockz]

also i don't see any reason to leave out tukitd? it only depends on sd-bus api (you can supply it with basu or elogind, preferably the former here) and the systemd service seems optional (the dbus service has traditional activation) so you can just not install it

i just didnr know you could do that! ill be changinf this PR to include that! sweet!

[tulilirockz]

i don't really understand why it's the initramfs that needs to mount that, why can't it be done after initramfs by early dinit services?

honestly it doesnt make that much sense indeed, this probaly could just run on the early- time on boot. but from what i understood you arent really supposed to have an /etc folder, it jusr mounts /var/lib/overlay/(current overlay)/etc + (previous overlay etc) to provide that. mounting it on initramfs time makes it so dinit works fine while not having that base /etc folder

[q66]

dinit should still work fine without it if the overlay mount is done early enough, it does not depend on that in any way

[q66]

also as far as i can tell the package should still be called transactional-update as that's the name of the repo/project

i mean, at this point it is just a naming thing - i just think that it makes more sense for it to be "tukit" since we arent really messing around wirh the transactional-update cli, right?

https://github.com/chimera-linux/cports/blob/master/Packaging.md#naming

package name is the project/repo name

[tulilirockz]

also as far as i can tell the package should still be called transactional-update as that's the name of the repo/project

i mean, at this point it is just a naming thing - i just think that it makes more sense for it to be "tukit" since we arent really messing around wirh the transactional-update cli, right?

https://github.com/chimera-linux/cports/blob/master/Packaging.md#naming

package name is the project/repo name

fair! ill just rename it real quick

[tulilirockz]

dinit should still work fine without it if the overlay mount is done early enough, it does not depend on that in any way

i thought it had to have the /etc/dinit.d directory to actually work, but i guess theres /usr/lib/dinit.d, right?

[tulilirockz]

Not mounting /etc on the initramfs leads to some really funky behaviour from tukit, like, it just cant do anything outside of $PWD=/ for some reason

[q66]

dinit should still work fine without it if the overlay mount is done early enough, it does not depend on that in any way

i thought it had to have the /etc/dinit.d directory to actually work, but i guess theres /usr/lib/dinit.d, right?

it can get services from there, but it doesn't need it present per se, especially not in early boot (so it's fine if it appears later)

initramfs shouldn't be doing this because one doesn't even necessarily need to have an initramfs, it should never be a hard assumption

[tulilirockz]

After some debugging and testing, I managed to make it work without the initramfs things! - This, though, doesnt seem like the best solution... Like, upstream they just expect that you have an initrd generated to mount /etc. Should this package still have the initramfs stuff as an optional subpackage or should it just only support the non-initramfs approach? @q66

Edit: just made the initramfs-tools not have the install_if thing. Everything should work fine now

[tulilirockz]

Been using this on my main system for a bit - without using the initramfs hook - and it doesn't seem to have broken anything? - I hope this can be merged since its such a wonderful way for atomic updates.

[tulilirockz]

oh! thanks for the typo fix! i didnt see it earlier @triallax