Re: [systemd-devel] Fedora 38 and signed PCR binding
On Sat, Nov 11, 2023 at 5:10 PM Aleksandar Kostadinov wrote: > > On Thu, Oct 12, 2023 at 1:14 AM Dan Streetman wrote: > > On Sun, Oct 8, 2023 at 8:09 AM Aleksandar Kostadinov > > wrote: > > ... > > > Here's what I did: > > > > sudo systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto > > > > --tpm2-public-key-pcrs=11 /dev/sda3 > > > > This probably isn't what you want, because you're specifying > > --tpm2-public-key-pcrs= but not --tpm2-public-key=, so the > > --tpm2-public-key-pcrs= doesn't actually do anything (it should > > probably either fail or at least print a warning). > > in man pages I see: > --tpm2-public-key= option accepts a path to a PEM encoded RSA >public key, to bind the encryption to. If this is not specified >explicitly, but a file tpm2-pcr-public-key.pem exists in one of the >directories /etc/systemd/, /run/systemd/, /usr/lib/systemd/ >(searched in this order), it is automatically used. > > I do have such a file. ah ok, yeah that should be fine then. > > > Since you didn't specify --tpm2-pcrs=, it will default to use only > > PCR7, using the current value (at the time you ran > > systemd-cryptenroll). > > I specify --tpm2-public-key-pcrs=11, should I specify also > --tpm2-pcrs? I don't want to bind to plain PCRs. If you don't specify --tpm2-pcrs= at all, it will bind to PCR 7, even if you bind to a signature as well (at least this is the current behavior). If you want to bind only to a signature, you should use --tpm2-pcrs="" (i.e. empty string) to prevent binding to PCR 7. This is probably not the most intuitive default behavior, which we might want to change... > > > Just for testing, can you try: > > sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs="" /dev/sda3 > > > > That will enroll your tpm with *no* pcr values, so it should always > > successfully unlock your volume using the tpm (note, you probably > > don't want to do this other than for testing). Then see if it uses the > > tpm to unlock the volume on boot. If so, you just need to get the > > specific PCR parameters correct (and make sure to supply your PEM > > public key to systemd-cryptenroll using --tpm2-public-key=), and > > provide the correct signature. > > This is a nice check actually. And in fact it does not open the volume > automatically. Which is super strange. As it worked with the normal > grub based boot process. > > sudo systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto > --tpm2-pcrs= /dev/sda3 > then removed `tpm2-measure-pcr=yes` from /etc/crypttab, then > `dracut-f` and finally `ukify ..` with the exact same arguments as > before. > > Did I miss something? let's try manually unlocking it just to make sure the enrollment was ok, so after enrolling it try: systemd-cryptsetup test /dev/sda3 - tpm2-device=auto,headless=true (you don't need headless=true, that only skips asking you for the luks password if the tpm unlocking didn't work) that should unlock the luks device and create the /dev/mapper/test device. if that doesn't work, then there's some problem with the tpm enrollment into your luks device. if it does work, then the problem is with your boot setup. my guess would be you aren't building the initrd with all the right bits needed to unlock it (you'll probably have to manually add in some crypt modules to the dracut call) > > Strange is that in `journalctl -b` I still see "Couldn't find > signature for this PCR bank, PCR index and public key." So I wonder > what could be broken and how to fix it. How to inspect the initrd > inside the UKI? well you built the initrd before running ukify, so just take a look at it before you build the uki > > <...> >
Re: [systemd-devel] Fedora 38 and signed PCR binding
On Sun, Oct 8, 2023 at 8:09 AM Aleksandar Kostadinov
wrote:
>
> I've progressed past this point by upgrading to Fedora 39 Beta which
> apparently has a newer ukify version. The issue now though is that
> automatic unlock does not work. I need to enter password manually and
> I see no errors in console output.
>
> Here's what I did:
> > sudo systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto
> > --tpm2-public-key-pcrs=11 /dev/sda3
This probably isn't what you want, because you're specifying
--tpm2-public-key-pcrs= but not --tpm2-public-key=, so the
--tpm2-public-key-pcrs= doesn't actually do anything (it should
probably either fail or at least print a warning).
Since you didn't specify --tpm2-pcrs=, it will default to use only
PCR7, using the current value (at the time you ran
systemd-cryptenroll).
Just for testing, can you try:
sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs="" /dev/sda3
That will enroll your tpm with *no* pcr values, so it should always
successfully unlock your volume using the tpm (note, you probably
don't want to do this other than for testing). Then see if it uses the
tpm to unlock the volume on boot. If so, you just need to get the
specific PCR parameters correct (and make sure to supply your PEM
public key to systemd-cryptenroll using --tpm2-public-key=), and
provide the correct signature.
>
> > $ sudo cat /etc/crypttab
> > luks-### UUID=### none discard,tpm2-device=auto,tpm2-measure-pcr=yes
>
> > sudo dracut -f
>
> > /usr/lib/systemd/ukify build \
> > --linux=/lib/modules/6.5.5-300.fc39.x86_64/vmlinuz \
> > --initrd=/boot/initramfs-6.5.5-300.fc39.x86_64.img \
> > --pcr-private-key=/etc/systemd/tpm2-pcr-private-key.pem \
> > --pcr-public-key=/etc/systemd/tpm2-pcr-public-key.pem \
> > --phases='enter-initrd' \
> > --pcr-banks=sha1,sha256 \
> > --secureboot-private-key=/etc/secure_boot/db_custom.key \
> > --secureboot-certificate=/etc/secure_boot/db_custom.pem \
> > --sign-kernel \
> > --cmdline=@/etc/kernel/cmdline \
> > --measure \
> > --output=/boot/efi/EFI/fedora/uki/vmlinuz.efi
>
> > efibootmgr -c -d /dev/sda -p 1 -l /EFI/FEDORA/UKI/VMLINUZ.EFI -L "Fedora
> > UKI"
>
> The UKI entry now does boot. But waits for luks decryption password.
>
> I added a print line to the `ukify` executable to see the signature
> file generated.
>
> > {"sha1": [{"pcrs": [11], "pkfp":
> > "77cb92791d56699be04ab48bdc85adbd6e12ec2816241eadbe0859650684bee7", "pol":
> > "3d43ca831277c9a57f7741a23dca2896da9ece1417d1dc047c7a018014571580", "sig":
> > "hJ4fhnRPXmsEXdq6o5eVS9WbGyJJdp/Q+x8Op5EPp0JmnB79nuGZqtTK1tYaxjzgN6/w/Wq1k93p/owSks9I7SJ5wJ0ciA4Ruaou49HdK0eDBbDmJ+Bsb33t/tP7bgXrpz2KEzkpmxd9SkIfM/0cK9tHJfrlvuAZgNr9vr3zLBkaWGI2XkDhOCnujWvxatDX2L63IPUyAZ+CGqvSL95734MPsJ0VWeP3w0mBb9KfMw7jifWLVj+1A3V5iY2bK5HYCzMBab91XuQo2JjMRDfE33PlqkiRFq56AwpLkZAVijndFNHJj7zHrzXBBsKWsO+t3i6WVF4g2cmaISVs6ehIJw=="}],
> > "sha256": [{"pcrs": [11], "pkfp":
> > "77cb92791d56699be04ab48bdc85adbd6e12ec2816241eadbe0859650684bee7", "pol":
> > "76e24d931952b45046e001cac3ed6a6f9b76162fb3eb2366f704a6c360e720b1", "sig":
> > "t17dochSzptJyvNkrldHKSKF1WnVW6EncKNtvNftp7+VHJEb3/GL58/M67eRI7lDSxcTzKXEFCqgDUOJIBBod9hhY9i0QPirr7GOWOcV+3FsjFtT+q+SJ0QNBdYXCYvy5GwsrBe1RXRlw4JxfyNLXlaD4xVVsbEFd079yVK9HVd7LxIs8hVwDRTBMPnWgiglzinkYr6GxN7q0ipQAtVANyWOIWVMWAuYQ7fvZXqO4XEq1Bpu73vUxfMo+5g+GRJS0dXOnSXZWro8IssjZNaDimWOIgPPTmIDZVs4SptyLcQo9O6Z9YYScanP0jXtuJEkzCi7YxG+0QwHQQTp4mka2g=="}]}
>
> Any ideas what might be going wrong or how to further debug it?
>
> Thank you!
>
>
>
> On Fri, Sep 15, 2023 at 12:02 PM Aleksandar Kostadinov
> wrote:
> >
> > Will appreciate any pointers about debugging and fixing this!
> >
> > On Tue, Sep 12, 2023 at 2:55 AM Aleksandar Kostadinov
> > wrote:
> > >
> > > On Mon, Sep 11, 2023 at 2:57 PM Lennart Poettering
> > > wrote:
> > > >
> > > > On Mo, 11.09.23 14:48, Aleksandar Kostadinov (akost...@redhat.com)
> > > > wrote:
> > > >
> > > > > Hi again. I tried to boot from UKI to no avail.
> > > > >
> > > > > First created a "db" certificate
> > > > > > openssl req -newkey rsa:2048 -nodes -keyout db_arch.key -new -x509
> > > > > > -sha256 -days 3650 -subj "/CN=My DB cert/" -out db.pem
> > > > > > openssl x509 -outform DER -in db.pem -out db.crt
> > > > >
> > > > > Then uploaded it to secure boot trust VIA USB drive and the UEFI
> > > > > seup.
> > > > >
> > > > > Then created UKI:
> > > > > > /usr/lib/systemd/ukify \
> > > > > > /lib/modules/6.4.12-200.fc38.x86_64/vmlinuz \
> > > > > > /boot/initramfs-6.4.12-200.fc38.x86_64.img \
> > > > > >
> > > > > > --pcr-private-key=/etc/systemd/tpm2-pcr-private-key.pem \
> > > > > >
> > > > > > --pcr-public-key=/etc/systemd/tpm2-pcr-public-key.pem \
> > > > > >
Re: [systemd-devel] Should `MACAddressPolicy=persistent` for bridges/bonds/all-software-devices be reconsidered?
On Thu, May 12, 2022 at 2:27 PM Dan Streetman wrote: > > On Thu, May 12, 2022 at 1:50 PM Dusty Mabe wrote: > > > > > > > > On 5/12/22 13:36, Dan Streetman wrote: > > > On Thu, May 12, 2022 at 11:11 AM Thomas Haller wrote: > > >> > > >> Hi Zbyszek, > > >> > > >> > > >> > > >> I must say, I personally don't care too much. NetworkManager is fine > > >> either way. > > >> > > >> There is however the problem about RHEL8/9, which patches this > > >> downstream. I don't like that deviation, but I'd also be uncomfortable > > >> to push that change for RHEL(10) users. > > >> > > >> But let me play devil's advocate here... > > >> > > >> > > >> On Mon, 2022-05-09 at 19:27 +0200, Zbigniew Jędrzejewski-Szmek wrote: > > >>> > > >>> FWIW, I still think it's a better _default_. > > >> > > >> I don't agree that it's clearly better. Your arguments don't seem > > >> strong, arguably, neither are mine. Except, that it's not clear that > > >> this solves an actual problem, while it clearly causes problems for > > >> some people. Just look at the referened issues from !3374. > > >> > > >> > > >> Either > > >> > > >> - a user doesn't care about the MAC address, > > > > > > note that it's possible for a user not to care about the *specific* > > > mac address, only that they want the mac to remain consistent. > > > > > > for example, on my system i have br0 bridge with multiple interfaces > > > attached, and my local DHCP server is configured to provide a static > > > addr to br0's mac. If I replace an interface card (e.g. change from 1g > > > to 10g, or just replace a failing nic) then the br0 mac *does not* > > > change, if using systemd's default. If I had br0 inheriting its mac > > > from one of the attached interfaces, it would change, and i'd have to > > > update my dhcp server config. > > > > > > I think the argument really comes down to, should the default be to > > > have (without user configuration) a mac that is predictable or a mac > > > that is consistent. Your argument is for predictability, which makes > > > the field engineer's work deploying systems easier, but if you lose > > > consistency then the life of the maintenance engineer gets harder. > > > > Interested discussion. Let's take it a bit further. > > > > On your system how did your DHCP server get configured to provide an > > addr to br0's MAC? You had to install the OS, and create br0 first > > before you even knew the MAC to tell the network admin what the MAC > > was. Now you're golden, the MAC will never change for the lifetime > > of that OS install even if someone replaces a NIC, but it wasn't a great > > first experience really. > > No, but the alternative is for me to manually find the mac address > labels on my nics and use those to pre-configure my DHCP server. I > understand for large deployments those are typically provided in a > spreadsheet, but that isn't the case for me, and my approach (i.e. > simply check the mac once the system is installed) was *much* easier > and more reliable. > > And this doesn't even get into the nuances of figuring out *which* nic > mac the bridge/bond will get, which won't be obvious to everyone. Note > that the answer here *is not* that the bridge gets the mac of the > 'first' interface added to it; the bridge gets the mac of the *lowest* > mac that is currently attached to it. And yes, this does mean that if > you use this behavior (of a bridge getting its mac from the attached > interfaces), the bridge's mac *can change while it is up and running > with an address*. Try it out yourself ;-) And to clarify - bond interfaces do 'keep' the mac of the 'first' interface added - technically, the bond sets all interfaces added later to have the same mac. So this is even less 'predictable' than a bridge, where you can predict which of the 2 or more macs are 'lowest', a bond mac would just be whatever the 'first' added interface is. > > > > > > On the other hand, what if you re-provision that server often (new > > machine-id) > > you get a new MAC and you get to dance with your network admin again. OR > > what if you have disk failure? You most likely backed up your critical data, > > but did you backup your machine-id that hashes your new MAC? Probably not > > and even if you did would you want to duplicate that machine-id to the new >
Re: [systemd-devel] Should `MACAddressPolicy=persistent` for bridges/bonds/all-software-devices be reconsidered?
On Thu, May 12, 2022 at 1:50 PM Dusty Mabe wrote: > > > > On 5/12/22 13:36, Dan Streetman wrote: > > On Thu, May 12, 2022 at 11:11 AM Thomas Haller wrote: > >> > >> Hi Zbyszek, > >> > >> > >> > >> I must say, I personally don't care too much. NetworkManager is fine > >> either way. > >> > >> There is however the problem about RHEL8/9, which patches this > >> downstream. I don't like that deviation, but I'd also be uncomfortable > >> to push that change for RHEL(10) users. > >> > >> But let me play devil's advocate here... > >> > >> > >> On Mon, 2022-05-09 at 19:27 +0200, Zbigniew Jędrzejewski-Szmek wrote: > >>> > >>> FWIW, I still think it's a better _default_. > >> > >> I don't agree that it's clearly better. Your arguments don't seem > >> strong, arguably, neither are mine. Except, that it's not clear that > >> this solves an actual problem, while it clearly causes problems for > >> some people. Just look at the referened issues from !3374. > >> > >> > >> Either > >> > >> - a user doesn't care about the MAC address, > > > > note that it's possible for a user not to care about the *specific* > > mac address, only that they want the mac to remain consistent. > > > > for example, on my system i have br0 bridge with multiple interfaces > > attached, and my local DHCP server is configured to provide a static > > addr to br0's mac. If I replace an interface card (e.g. change from 1g > > to 10g, or just replace a failing nic) then the br0 mac *does not* > > change, if using systemd's default. If I had br0 inheriting its mac > > from one of the attached interfaces, it would change, and i'd have to > > update my dhcp server config. > > > > I think the argument really comes down to, should the default be to > > have (without user configuration) a mac that is predictable or a mac > > that is consistent. Your argument is for predictability, which makes > > the field engineer's work deploying systems easier, but if you lose > > consistency then the life of the maintenance engineer gets harder. > > Interested discussion. Let's take it a bit further. > > On your system how did your DHCP server get configured to provide an > addr to br0's MAC? You had to install the OS, and create br0 first > before you even knew the MAC to tell the network admin what the MAC > was. Now you're golden, the MAC will never change for the lifetime > of that OS install even if someone replaces a NIC, but it wasn't a great > first experience really. No, but the alternative is for me to manually find the mac address labels on my nics and use those to pre-configure my DHCP server. I understand for large deployments those are typically provided in a spreadsheet, but that isn't the case for me, and my approach (i.e. simply check the mac once the system is installed) was *much* easier and more reliable. And this doesn't even get into the nuances of figuring out *which* nic mac the bridge/bond will get, which won't be obvious to everyone. Note that the answer here *is not* that the bridge gets the mac of the 'first' interface added to it; the bridge gets the mac of the *lowest* mac that is currently attached to it. And yes, this does mean that if you use this behavior (of a bridge getting its mac from the attached interfaces), the bridge's mac *can change while it is up and running with an address*. Try it out yourself ;-) > > On the other hand, what if you re-provision that server often (new machine-id) > you get a new MAC and you get to dance with your network admin again. OR > what if you have disk failure? You most likely backed up your critical data, > but did you backup your machine-id that hashes your new MAC? Probably not > and even if you did would you want to duplicate that machine-id to the new > install you would do? > > Barring other reasons, if we simplify it down to just the consistency > argument, > one approach seems better for if you replace NIC cards often and one of them > seems better if you re-install your OS often. Yes, 'consistency' has to be based on something, so 'consistency' based on hardware is one approach; consistency based on software is another. As you said some users may have software churn and so would want to base their 'consistency' on their (presumably unchanging) hardware. However, software churn is pretty rare at the bare metal level, isn't it? Not unheard of, for sure, but I'd hardly say most datacenters redeploy their bare metal servers regularly (though I admit I have no real knowledge of how often that happens). If we're talking about virtual software churn, which I think is much more common (e.g. redeploying an os into a VM), then - assuming the actual VM definition doesn't change (because if it did, then there is no hw consistency to base the mac consistency on), the machine-id will re-use the VM's uuid (provided via DMI as previously mentioned) and so the systemd-generated mac won't change. > > Dusty > >
Re: [systemd-devel] Should `MACAddressPolicy=persistent` for bridges/bonds/all-software-devices be reconsidered?
On Thu, May 12, 2022 at 11:11 AM Thomas Haller wrote: > > Hi Zbyszek, > > > > I must say, I personally don't care too much. NetworkManager is fine > either way. > > There is however the problem about RHEL8/9, which patches this > downstream. I don't like that deviation, but I'd also be uncomfortable > to push that change for RHEL(10) users. > > But let me play devil's advocate here... > > > On Mon, 2022-05-09 at 19:27 +0200, Zbigniew Jędrzejewski-Szmek wrote: > > > > FWIW, I still think it's a better _default_. > > I don't agree that it's clearly better. Your arguments don't seem > strong, arguably, neither are mine. Except, that it's not clear that > this solves an actual problem, while it clearly causes problems for > some people. Just look at the referened issues from !3374. > > > Either > > - a user doesn't care about the MAC address, note that it's possible for a user not to care about the *specific* mac address, only that they want the mac to remain consistent. for example, on my system i have br0 bridge with multiple interfaces attached, and my local DHCP server is configured to provide a static addr to br0's mac. If I replace an interface card (e.g. change from 1g to 10g, or just replace a failing nic) then the br0 mac *does not* change, if using systemd's default. If I had br0 inheriting its mac from one of the attached interfaces, it would change, and i'd have to update my dhcp server config. I think the argument really comes down to, should the default be to have (without user configuration) a mac that is predictable or a mac that is consistent. Your argument is for predictability, which makes the field engineer's work deploying systems easier, but if you lose consistency then the life of the maintenance engineer gets harder. > - a user sets the desired MAC address themselves (possibly by > setting MacAddressPolicy=) > - or, the user intentionally does not set a MAC address (e.g. for > bridge/bond). > > In no case there is a strong argument why udev should do it, and it's > harmful in some cases. > > > > > > The patch that finally > > introduced this was my patch [1], so I'm obviously biased… Some more > > considerations: > > > > 1. this allows bridge devices to be created without attached > > interfaces, and have a stable MAC address. > > yes. Does somebody care? In particular, kernel will assign a certain > MAC address when the first port gets attached. Some people care about > that. > > > > 2. the idea that all interfaces are always available and always in > > the > > same order is something that isn't necessarilly true for modern > > systems > > where we want to react to hardware being detected dynamically. > > If we wait until late userspace to configure networking, then yeah, > > all > > devices will most likely have been detected by that time. But if we > > want > > to bring networking in the initrd, not all hardware must be detected > > by > > the time we start configuration. > > It's either way a well-known MAC address from one of the interfaces. > > > > > 3. one of the reasons to use bridge/bond and similar devices it that > > the agreggate device can function when some of the child devices die. > > By requiring the presence of one of the devices, we're partially > > defeating this. > > In practice, this race is not happening for many users. > > It's not clear why it's a problem to get the MAC address of an > "unexpected" port (due to the race). It does not negate the uses of the > bride/bond. > > > > > [1] https://github.com/systemd/systemd/commit/6d36464065 > > > > > 1) for bridge/bond interfaces, there is a special meaning of > > > leaving > > > the MAC address unassigned. It causes kernel to automatically set > > > the > > > MAC address when the first port gets attached. By setting a > > > persistent > > > MAC address, that automatism is not longer possible. > > > > > > The MAC address can matter, for example, if you configure the DHCP > > > server to hand out IP addresses based on the MAC address (or based > > > on > > > the client-id, which in turn might be based on the MAC address). If > > > you > > > boot many machines (e.g. in data center or cloud), you might know > > > the > > > MAC address of the machines, and thereby can also determine the > > > assigned IP addresses. With MACAddressPolicy=persistent the MAC > > > address > > > is not predictable. > > > > This is true. But one can just as well argument that with > > MACAddressPolicy=persistent the address is even more predictable. If > > you know the machine-id and device name, you can calculate the > > address > > in advance, even before deciding if the device will e.g. have this or > > that card attached. > > It's unpredictable, because you need to know the machine-id. If you > boot a machine the first, you may not know that before hand. > > Unless you explicitly specifying the machine-id via kernel command > line, or similar. At which point, you need individual boot options (or > images) for each
[systemd-devel] Ubuntu CI will be unavailable for part of Nov 20 and/or Nov 21
Starting sometime on Nov 20, some of the hardware used for Ubuntu CI tests will be down for maintenance, and it's likely some or all Ubuntu CI test runs will fail until the hardware is back up. I don't know the specific length of time it will take, but the maintenance window has been scheduled from Nov 20 until Nov 21. https://lists.ubuntu.com/archives/launchpad-announce/2020-November/000107.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Follow up on hid2hci: Fix udev rules for linux-4.14+
On Wed, Aug 28, 2019 at 1:59 PM Ville Syrjälä wrote: > > On Wed, Aug 28, 2019 at 08:50:51PM +0300, Ville Syrjälä wrote: > > On Wed, Aug 28, 2019 at 01:34:07PM -0400, Dan Streetman wrote: > > > It looks like this patch got lost at some point: > > > https://lore.kernel.org/patchwork/patch/902126/#1138115 > > > > > > but it seems to still be a problem and I'd like to pull it into Ubuntu: > > > https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1759836 > > > > > > Ville, did you ever follow up with a v2 for that patch and/or do you > > > know if it will be accepted soon? > > > > There's a more recent version of that somewhere on the mailing list. > > The problem is getting someone to actually apply it. Seems much harder > > than it should be... > > https://lore.kernel.org/patchwork/patch/1021109/ I added to this reply a few of the most recent commit authors to the bluez tools/ subdir...can any of you review and/or apply Ville's patch? Marcel, you appear to have created the hid2hci.rules file back in 2012, can you comment on the patch? > > > > > And IIRC I also posted a few other fixes for hid2hci tool which didn't > > get any response from the crowd. > > https://www.spinics.net/lists/linux-bluetooth/msg79803.html > > -- > Ville Syrjälä > Intel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Follow up on hid2hci: Fix udev rules for linux-4.14+
It looks like this patch got lost at some point: https://lore.kernel.org/patchwork/patch/902126/#1138115 but it seems to still be a problem and I'd like to pull it into Ubuntu: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1759836 Ville, did you ever follow up with a v2 for that patch and/or do you know if it will be accepted soon? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] how to add test sysfs nodes, to sys.tar.xz?
On Sun, Feb 5, 2017 at 6:26 PM, Zbigniew Jędrzejewski-Szmek
<zbys...@in.waw.pl> wrote:
> On Mon, Jan 30, 2017 at 05:40:40PM -0500, Dan Streetman wrote:
>> On Thu, Jan 26, 2017 at 9:36 AM, Zbigniew Jędrzejewski-Szmek
>> <zbys...@in.waw.pl> wrote:
>> > Thanks for working on the tests.
>> >
>> > On Thu, Jan 26, 2017 at 09:21:41AM -0500, Dan Streetman wrote:
>> >> However, I'd like to also add tests for whitespace replacement using
>> >> actual device $attr{}, which I think means the test/sys.tar.xz file
>> >> needs to be updated to add device (maybe a NVMe device) nodes that
>> >> include whitespace in its model and/or serial strings - is that how
>> >> new test sysfs device nodes are added? Updating the entire binary
>> >> seems like a big change just for a few device node files..
>> > It's only 162k. It's not perfect that we have to update it every time
>> > we add tests, but it's not too terrible.
>> >
>> > If you're feeling ambitious, you might want to convert that tarball to
>> > a script which generates the nodes. After all, it's just a bunch of
>> > directories, with symlinks and a few simple text files. Then this will
>> > be normal text file and git will be able to track changes to it. This
>> > would a much nicer solution in the long run.
>>
>> I crafted a script that does that, which isn't complex, although it
>> isn't simple either. However, I'm wondering, why not just store the
>> files directly in git? It would be simpler than either the tarball or
>> a script, and git can handle symlinks and binary files, unless there's
>> some shortcoming that I'm not seeing?
>
> In principle, this would work too. But git tools aren't too good when
> working with symlinks (e.g. git diff treats them as normal text files,
> and displays a stupid warning about a missing newline, etc). When
> scaled to the number of files in /sys, I think working with this
> approach would be rather unpleasant.
>
> Can you paste the script you have?
yep, opened pr 5250
https://github.com/systemd/systemd/pull/5250
>
> Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] how to add test sysfs nodes, to sys.tar.xz?
On Thu, Jan 26, 2017 at 9:36 AM, Zbigniew Jędrzejewski-Szmek
<zbys...@in.waw.pl> wrote:
> Thanks for working on the tests.
>
> On Thu, Jan 26, 2017 at 09:21:41AM -0500, Dan Streetman wrote:
>> However, I'd like to also add tests for whitespace replacement using
>> actual device $attr{}, which I think means the test/sys.tar.xz file
>> needs to be updated to add device (maybe a NVMe device) nodes that
>> include whitespace in its model and/or serial strings - is that how
>> new test sysfs device nodes are added? Updating the entire binary
>> seems like a big change just for a few device node files..
> It's only 162k. It's not perfect that we have to update it every time
> we add tests, but it's not too terrible.
>
> If you're feeling ambitious, you might want to convert that tarball to
> a script which generates the nodes. After all, it's just a bunch of
> directories, with symlinks and a few simple text files. Then this will
> be normal text file and git will be able to track changes to it. This
> would a much nicer solution in the long run.
I crafted a script that does that, which isn't complex, although it
isn't simple either. However, I'm wondering, why not just store the
files directly in git? It would be simpler than either the tarball or
a script, and git can handle symlinks and binary files, unless there's
some shortcoming that I'm not seeing?
>
> Z.
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] how to add test sysfs nodes, to sys.tar.xz?
Hi,
Re: bug 4833 and pull request 4837,
https://github.com/systemd/systemd/issues/4833
https://github.com/systemd/systemd/pull/4837
I was thinking of how to add some test cases for whitespace, and
keszybz just merged these tests:
https://github.com/systemd/systemd/pull/5158
which test for proper whitespace->underscore replacement using $env{}.
However, I'd like to also add tests for whitespace replacement using
actual device $attr{}, which I think means the test/sys.tar.xz file
needs to be updated to add device (maybe a NVMe device) nodes that
include whitespace in its model and/or serial strings - is that how
new test sysfs device nodes are added? Updating the entire binary
seems like a big change just for a few device node files..
Thanks!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
