=== five6184803392 is now known as five618480339 [11:02] Hello arm community, I'm using the 24.04 image on my raspberry pi, and I noticed some changes to the users/groups in the ubuntu image (some nice changes to mirror raspbian) I was curious as to the thinking of UID/GID for users such as 'spi' being above the 1000 UID/GID range, rather than in the lower system UID/GID's [11:03] ikonia, that ... shouldn't be the case. There certainly shouldn't be an "spi" group (I'm guessing?) in the "regular user" range. Is this the server or desktop image you're using? [11:07] server [11:07] let me login and I can confirm for you [11:08] damn it, my config management has cleaned it up [11:09] let me put a clean build on a pi [11:09] uid spi was 1000 as I recall [11:09] ahhh GID for SPI is 1001 [11:10] that's still there [11:10] so I suspect UID for SPI was also 1001 [11:10] interesting -- I'm not seeing the same on my noble server pi, but then it wasn't installed from the official image (it's one I've upgraded and upgraded). I wonder if it's something cloud-init is getting up to ... [11:10] this was a clean image, however my config management has cleaned up (it was that which alerted me to it) [11:11] let me put a new image on a pi [11:11] I'll spin one up here and see if I can replicate [11:22] ikonia -- okay, fresh boot of 24.04 server (release image) on a pi 4 and I can't see an spi group. Is there some package you might be installing that could be adding the group? [11:22] booting a clean image myself as we speak [11:23] give me a few minutes for it to come up [11:23] sure :) [11:45] ok - so default group out of the box is 1001 for spi [11:46] on a clean image [11:46] but there is no user, it's just the group [11:46] shouldn't this be under the 1000 GID [11:46] gpio, i2c are also 1001/1002 [11:46] GID [11:47] so it was GID's in the error I saw, not UID [11:49] I would have expected them to be under the 1000 GID list, but I guess that's argumentative depending on what you class personally as "system" [12:07] just checked through all the CFGMGT stuff, and it looks like that was it, it's the GID's not the UID's [13:14] ikonia, this doesn't match what I'm seeing with the 24.04 release image. The only users and groups with id >= 1000 are "ubuntu" -- I don't see a gpio, i2c, or spi group. Are you sure this is the server image? Or maybe it's one of the flavours? (though I didn't think there were any pi server images from the flavours) [13:16] looking at the unbooted image itself, there aren't any users/groups with id >= 1000 (other than "nobody" but that's also outside the regular user range) [16:16] waveform: something wrong here then [16:16] waveform: I got the image from the Raspberry PI image tool, other OS -> Ubuntu -> Ubuntu Server 24.04 [16:17] is it possible it's not getting the official image (that seems unlikely) [16:17] mattd@locutus:~$ grep spi /etc/group [16:17] spi:x:1001: [16:18] thats from a clean image deployed [16:18] let me grab the image from ubuntu.com [16:18] remove doubt [16:21] bizarre -- the rpi-imager tool should be grabbing the image direct from cdimage (I should know as I deal with updating the JSON for it! :) [16:21] so it should be the official image; let me double check that my local copy is the same as what we're serving from rpi-imager [16:22] waveform: this was my expectation also [16:22] thank you for checking [16:23] local copy matches the SHA256 sum on the server so I'm pretty confident I'm looking at the same thing as being served by rpi-imager ... so I'm rather baffled as to what's going on here [16:23] mattd@locutus:~$ grep 1002 /etc/group [16:23] i2c:x:1002: [16:24] totally untouched [16:24] this is straight after first boot? [16:24] booted, logged in, checked, updated re-checked [16:24] (wanted to see if an update was doing it) [16:25] hang on ... your username isn't "ubuntu" ... so is there a customized cloud-init that might be installing something? [16:25] sorry, I added the user [16:25] ahh, okay [16:25] oh, I wonder if adding a user ... let me try that [16:25] (so my keys work etc) [16:26] I've just run the config management tooling I use to see if it errors (and it correctly does) [16:26] I'll bounce from a new image again in a minute [16:27] nope, just ran "sudo adduser dave" and it's just added dave:dave with 1001:1001 -- stil no spi/i2c/gpio groups showing up [16:29] let me re-image [16:29] oh, your config management tooling -- how is that installed? (wondering if any of its deps are pulling in something that's creating those groups) [16:30] puppet [16:30] no deps [16:30] and also I verified before install [16:34] how are you installing puppet? from apt, or some other mechanism? [16:43] from apt [16:43] pointed at apt.puppet.com [16:43] just grabbing the image on the card [16:46] ahh, a third-party apt repo. I was checking the ubuntu archive copy -- have to go grab dinner, but I'll take a look at this after [16:46] thanks, I'll firm up the info for you, appreciate you taking a look [16:54] 16:54:03 up 3 min, 2 users, load average: 0.72, 0.84, 0.38 [16:54] been up 3 mins on a fresh image [16:54] ubuntu@locutus:~$ grep spi /etc/group [16:54] spi:x:1001:ubuntu [16:54] ubuntu@locutus:~$ grep mattd /etc/passwd [16:54] so nothing changed form initial boot [20:09] ikonia, back again -- I've had a look at the puppet-agent package from the apt.puppet.com source and it doesn't look like it's responsible, but *something* you're installing is adding those groups as they're not there on the image either before or after first boot [20:10] it may be worth grepping /var/log/apt/term.log for "Adding (new|system) (user|group)" to see if anything interesting pops up -- but that assumes what's adding those groups is an apt package [20:14] (I've also tried installing the puppet8 agent from that source on a spare Pi 4, but again no spi/i2c/gpio groups appeared so it's not that directly, although it might be something puppet's later configured with) [20:27] nah, it's not puppet [20:27] 100000% sure of that [20:27] the text I sent through was from a clean image, up 3 minutes post first boot [20:29] so its got to be either a.) something in the image b.) something is happening to the image from the pi-imager when it's written to the card [20:29] as I'd not touched anything in the 3 minute uptime [20:29] oooooooh [20:29] ohhh, now it could be rpi-imager's customization bits -- I haven't checked if there are any changes there, just a mo [20:30] also..... [20:30] apt's background updater after first boot [20:30] ok - it's not hit it in the first 3 minutes, so it's sort of moot [20:30] but.... [20:31] the apt log, shows a ton of objects being updated in the background [20:31] Taking backup of jedec-spi-nor.dtbo. [20:31] Installing new jedec-spi-nor.dtbo. [20:31] Taking backup of spi5-2cs-pi5.dtbo. [20:31] (for example) [20:31] that's just flash-kernel writing stuff to the boot partition (and being horribly noisy while doing it) [20:32] some of the device tree overlays (dtbo) are concerned with (for example) the extra SPI outputs on the pi4/5 which are configurable via the overlays [20:32] I thought a few of those object wouldn't exist if components such as ic2 where not installed [20:32] (hence the appearance of spi5 there -- that's the overlay for activating spi5 with 2 chip-select lines) [20:33] they have to be on the boot partition for the bootloader to read the overlays and apply any that are automatically selected (or manually configured via config.txt) before it passes the modified device-tree to the linux kernel [20:34] ah, I thought they got dropped in once the package to support then was installed [20:34] ok, red herring [20:34] no, they're always there, hiding away in /boot/firmware/overlays :) [20:36] this is most confusing [20:37] I think you're onto something with the rpi-imager customization -- I have a vague recollection of the cloud-init code in there, and I'm currently trying to track down where I saw it [20:38] ooooh [20:38] let me have a look too [20:39] ohhh, it's in the QML -- that's why I couldn't find it [20:39] got it [20:39] https://github.com/raspberrypi/rpi-imager/blob/qml/src/OptionsPopup.qml#L644 [20:40] that's constructing a cloud-init user-data configuration that'll try and add the default user to all those groups ... several of which don't exist in ubuntu for $reasons [20:40] NICE [20:40] ok, let me take a look properly [20:40] you should find that your /boot/firmware/user-data has something very similar to that in it [20:40] thank you [20:40] let me look [20:40] (because rpi-imager re-wrote it after writing the image) [20:42] years ago, I did try and get spi/i2c/gpio groups added to the ubuntu pi images, but that was veto'd as security felt that the user-access mechanism was the proper way of handling it (and I'd generally trust their judgment on such things, although it is a bit of a pain). Anyway ... that's a bit of an issue in rpi-imager. I'll open an issue for it once I've had a bit of a think about the "proper" way of handling this [20:43] (rpi-imager shouldn't be assuming all those groups exist on all distros it handles, and I'm not sure the "users:" key is the one they actually want either as they presumably want to customize the default user rather than define a new one) [20:43] (oh ... though I suppose they've excluded "default" there so the "ubuntu" user wouldn't be created ... urgh, I need to have a deeper dig into this) [20:45] anyway, *that's* the source of your groups -- for now I would either skip the image customization in rpi-imager, or tweak the user-data file manually (I left a pile of comments in the default one to hopefully provide some useful suggestions on customization) [20:45] https://github.com/snapcore/pi-gadget/blob/classic/configs/noble-arm64-server/user-data <-- this is the default user-data file on noble [20:57] on it ! [20:57] great work