Re: openSUSE MicroOS/Tumbleweed with systemd-boot available
On Thu, 21 Dec 2023 at 14:26, Ludwig Nussel wrote: > > Hi! > > JFYI openSUSE now has a MicroOS (transactional system with read-only /) > qcow image¹ suitable for use in qemu that uses systemd-boot. The image > is part of the Tumbleweed development process and automatically released > (ie potentially daily). It's fully integrated with btrfs snapshots and > rollback. As a special gimmick the image automatically encrypts itself > on first boot. Optionally the image can also leverage a TPM or FIDO2 key > to unlock the volume. Still quite WIP so I wouldn't recommend this for > production use. Nevertheless worth trying out to see how a mainstream > distro may leverage the technology. > > The image implements what I talked about at ASG². A more detailed > article is available on news.o.o³. Some screenshots in the wiki⁴ and a > video⁵ from openQA for the impatient :-) > > A Tumbleweed image with traditional writable file system will follow > soon. That one will be more convenient for development. > > cu > Ludwig > > [1] > http://download.opensuse.org/tumbleweed/appliances/openSUSE-MicroOS.x86_64-kvm-and-xen-sdboot.qcow2 > [2] https://www.youtube.com/watch?v=drgo6pvn5hI > [3] https://news.opensuse.org/2023/12/20/systemd-fde/ > [4] https://en.opensuse.org/Systemd-boot#Pre-built_MicroOS > [5] https://paste.opensuse.org/pastes/5e1a934d915f > > -- > (o_ Ludwig Nussel > //\ > V_/_ http://www.suse.com/ > SUSE Software Solutions Germany GmbH; GF: Ivo Totev, Andrew > McDonald, Werner Knoblich; HRB 36809 (AG Nürnberg) That's really cool, thanks for sharing
openSUSE MicroOS/Tumbleweed with systemd-boot available
Hi! JFYI openSUSE now has a MicroOS (transactional system with read-only /) qcow image¹ suitable for use in qemu that uses systemd-boot. The image is part of the Tumbleweed development process and automatically released (ie potentially daily). It's fully integrated with btrfs snapshots and rollback. As a special gimmick the image automatically encrypts itself on first boot. Optionally the image can also leverage a TPM or FIDO2 key to unlock the volume. Still quite WIP so I wouldn't recommend this for production use. Nevertheless worth trying out to see how a mainstream distro may leverage the technology. The image implements what I talked about at ASG². A more detailed article is available on news.o.o³. Some screenshots in the wiki⁴ and a video⁵ from openQA for the impatient :-) A Tumbleweed image with traditional writable file system will follow soon. That one will be more convenient for development. cu Ludwig [1] http://download.opensuse.org/tumbleweed/appliances/openSUSE-MicroOS.x86_64-kvm-and-xen-sdboot.qcow2 [2] https://www.youtube.com/watch?v=drgo6pvn5hI [3] https://news.opensuse.org/2023/12/20/systemd-fde/ [4] https://en.opensuse.org/Systemd-boot#Pre-built_MicroOS [5] https://paste.opensuse.org/pastes/5e1a934d915f -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; HRB 36809 (AG Nürnberg)
networkd: bridge is configured before interfaces are enslaved
Hello, I'm using systemd 244 on an embedded device, and I'm having a problem when trying to configure the onboard switch via networkd. The CPU is a TI J7200 SOC, which has a hardware switch. It is configured from linux like a regular bridge, with switchdev. Basically, you create a br0 interface, bind the device's physical interfaces to it. A driver will pick up that you're actually bridging interfaces belonging to the bridge, and enable the hardware offloading. The driver will then pick up any configuration done to the software bridge, and forward it to the hardware, so all vlans, QoS rules and such get registered on the hardware. The problem I'm having is that networkd is registering the vlans on br0 before the physical interfaces are enslaved. So: * br0 is created. At this point it's a regular software bridge. * The physical interfaces are added as links, pending udev initialization * bridge configuration begins, some vlans are created, and enslaved on the bridge * udev reports the physical interfaces as initialized * networkd switches them from pending to initialized * networkd then enslaves physical interfaces to br0. At this point the driver starts picking up configurations on br0. * bridge configuration continues The problem I have here is that in the hardware switch's driver will only pick up any configuration done after the physical interfaces are bound. Everything done before is unknown to the hardware. So, what would be the correct behaviour here? The easiest idea that comes to mind is to delay bridge configuration until the physical interfaces are bound. I can configure the network via shell scripts by doing things in this order. Should I patch networkd to add this dependency, or is there a cleaner way? I know 244 is an old version, and it is a possibility to move to a newer version if that will indeed fix the problem, but I'd like to know if that is the case before committing the resources needed for this update. __ Jordi Augé Embedded Linux Engineer Technica Electronics Barcelona
Re: Query on dynamic update of Kernel comandline
On Mi, 13.12.23 10:28, HARSHAL PATIL (QUIC) (quic_hgpa...@quicinc.com) wrote: > Hello Fellow Community, > > I have a following question. Your help will be really appreciated. > > "Kernel expects few params from kernel cmdline from underlying > firmware. Is there any mechanism to dynamically update the cmdline > updated by firmware (UEFI) during boot time in systemd-boot similar > to DT fixup protocol ?" I don't understand the question. Why would stuff from the UEFI firmware be added to the kernel cmdline? and what does that have to do with the DT fixup protocol? Various UEFI interfaces are available from userspace anyway, are you sure that whatever data you are looking for isn't readily available from /sys/ anyway? why must it be kernel command line? > Example : androidboot.serialno is read from firmware and needs to be appended > to kernel commandline I don't know what this is, and what that has to do with uefi, sd-boot or dt? Anyway, the question is very confusing, I am not surprised noone answered so far. Lennart -- Lennart Poettering, Berlin
Re: Query on dynamic update of Kernel comandline
On Thu, Dec 21, 2023 at 08:13:15AM +, HARSHAL PATIL (QUIC) wrote: > Hello Everyone, > > Can someone please reply to our query? > > We are really blocked due to this and unable to process in our project. It > will be really great. If you need paid support for a project that you depend on, I suggest contacting one of the many companies that provide such support. Otherwise, just asking the community to do your work for you again, isn't usually the best way to run a company project :) Why not work with the other developers in your company that have experience with the kernel and these things? Ignoring them feels very odd to me. good luck! greg k-h
RE: Query on dynamic update of Kernel comandline
Hello Everyone, Can someone please reply to our query? We are really blocked due to this and unable to process in our project. It will be really great. Thank You again for your support. Best Regards, Harshal Patil From: HARSHAL PATIL (QUIC) Sent: Wednesday, December 13, 2023 3:58 PM To: 'systemd-devel@lists.freedesktop.org' Subject: Query on dynamic update of Kernel comandline Hello Fellow Community, I have a following question. Your help will be really appreciated. "Kernel expects few params from kernel cmdline from underlying firmware. Is there any mechanism to dynamically update the cmdline updated by firmware (UEFI) during boot time in systemd-boot similar to DT fixup protocol ?" Example : androidboot.serialno is read from firmware and needs to be appended to kernel commandline Best Regards, Harshal Patil
