2023-06-12 07:21:49 <Kostya> hello
2023-06-12 07:23:24 <ncopa> hi
2023-06-12 14:20:31 <tomalok> ncopa: hiya!  would you like your recent ssh-authorized-keys to be released in a new 3.0.1 before we update 3.18-stable?
2023-06-12 14:21:07 <tomalok> *recent ssh-authorized-keys MR to tiny-cloud
2023-06-12 14:21:49 <ncopa> would be nice, yes
2023-06-12 14:22:03 <ncopa> there are some ERROR messages that are printed to std err
2023-06-12 14:22:16 <ncopa> when key is missing in yaml
2023-06-12 14:22:19 <ncopa> we should fix those too
2023-06-12 14:24:53 <tomalok> maybe a +e/-e switch for the wrapper function around yx -- similar to what is done in imds tool?  
2023-06-12 14:25:12 <tomalok> (and +E/-E)
2023-06-12 14:29:21 <ncopa> i think its enough with a 2>/dev/null
2023-06-12 14:29:39 <ncopa> we used to _imds 2>/dev/null
2023-06-12 14:29:49 <ncopa> but we can do it from yx
2023-06-12 14:30:10 <ncopa> i thought i had a rbanch with a fix for it
2023-06-12 14:30:14 <ncopa> but maybe i deleted it
2023-06-12 14:32:11 <ncopa> i think this is enough: https://tpaste.us/YYWP
2023-06-12 14:33:26 <ncopa> https://gitlab.alpinelinux.org/alpine/cloud/tiny-cloud/-/merge_requests/95
2023-06-12 14:34:45 <tomalok> lgtm
2023-06-12 14:37:52 <ncopa> thanks!
2023-06-12 14:45:56 <tomalok> will see if i have a chance to roll a 3.0.1 and get it into 3.18-stable around lunchtime today (4ish hours from now)
2023-06-12 14:46:42 <ncopa> i can backport things to 3.18-stable if you get it into git master
2023-06-12 14:46:51 <ncopa> or just tag the 3.0.1
2023-06-12 14:49:09 <tomalok> 3.0.1 tagged
2023-06-12 14:49:57 <ncopa> ok i can push release to master
2023-06-12 14:50:31 <ncopa> pushed to master
2023-06-13 16:49:47 <thresh> good morning!  hopefully aws cloud images are just around the corner for 3.18? :)
2023-06-13 17:00:02 <ncopa> we are still having issues with our arm machines
2023-06-13 17:00:06 <ncopa> network issues
2023-06-13 17:00:29 <ncopa> i have spent the day setting up new arm servers other location, but there is still some work left to do
2023-06-13 17:00:43 <ncopa> after that we can do alpine 3.18.1 release and aws images
2023-06-14 14:33:23 <ncopa> im tagging 3.18.1 ++ release now
2023-06-14 14:33:34 <ncopa> 3.15.9, 3.16.6, 3.17.4, 3.18.1
2023-06-14 14:45:52 <tomalok> ncopa: did tiny-cloud-3.0.1 get into 3.18-stable?
2023-06-14 14:46:15 <tomalok> aws cloud images will be broken without it
2023-06-14 14:47:48 <tomalok> (looks) 👍 thanks ncopa
2023-06-14 14:49:58 <ncopa> yes, i included tiny-cloud-3.0.1
2023-06-14 14:50:00 <ncopa> oh...
2023-06-14 14:50:02 <ncopa> man
2023-06-14 14:50:15 <ncopa> i think i may have forgotten mkinitfs update
2023-06-14 14:50:28 <tomalok> 🤦
2023-06-14 14:50:57 <ncopa> which means that 3.18.1 is broken
2023-06-14 15:10:30 <ncopa> tagged 3.18.2
2023-06-14 15:14:47 <ncopa> i need add tiny-cloud to my alpine-installer-testsuite to prevent this from happening again
2023-06-14 15:26:33 <tomalok> thanks ncopa - let me know when it's ready to start building cloud images
2023-06-14 15:28:08 <ncopa> the releases are done and uploaded
2023-06-14 15:33:10 <tomalok> build script needs releases.json updated to find the latest ones
2023-06-14 15:48:25 <ikke> tomalok: releases.json was updated
2023-06-14 20:04:44 <tomalok> ikke: thanks - started the build and then got busy with DayJob™
2023-06-15 03:42:33 <tomalok> 3.18 cloud images are all building fine, but 3.{15,16,17} uefi images are having a strange issue with a /usr/sbin/grub-install: error: unknown filesystem.error
2023-06-15 16:46:09 <minimal> tomalok: is the problem only with UEFI images or also with BIOS images on those releases?
2023-06-15 16:49:21 <minimal> if you#re creating ext4 fs on Alpine Edge/3.18.x and then using those on earlier Alpine versions you'd hit a Grub issue with it not handling ext4 options that newer mkfs.ext4 sets. But that would occur with both BIOS and UEFI images.
2023-06-15 16:56:39 <minimal> tomalok: ah...............you're using Syslinux, not Grub for BIOS images, so then you wouldn't see the above ext4 options/Grub issue as it doesn't affect Syslinux.
2023-06-15 20:02:31 <tomalok> minimal: yeah, only UEFI on images < 3.18 -- the builder itself is using 3.18, but then it's doing chrooty stuff for whatever version it's working on -- do you have a link to the missing/extra ext4 options and/or a workaround?
2023-06-15 20:04:45 <minimal> tomalok: right, so it is likely that issue then
2023-06-15 20:05:40 <minimal> the options used by default are defined in /etc/mke2fs.conf
2023-06-15 20:05:55 <minimal> so you could disable the checksum seed option there
2023-06-15 20:06:10 <minimal> or perhaps when you call mkfs.ext4 indicate the option is disabled
2023-06-16 18:37:40 <minimal> tomalok@ a reference to the mke2fs issue that I wrote prior to 3.18.0 release: https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.18.0#e2fsprogs_1.47.0
2023-06-16 18:46:37 <tomalok> 👍 thanks minimal - got a workaround and cloud images are building
2023-06-16 18:47:07 <ikke> tomalok: great
2023-06-16 18:47:16 <ikke> let me know when they're ready (I'm sure you will do)
2023-06-16 18:47:16 <minimal> tomalok: so what was your workaround?
2023-06-16 18:48:58 <tomalok> diabling metadata_csum_seedon the image volume -- i should probably double check to see what's up with orphan_filebefore releasing... 
2023-06-16 18:49:14 <tomalok> s/diabling/disabling/
2023-06-16 18:49:33 <minimal> orphan_file will affect/prevent older versions of fsck from working
2023-06-16 18:49:52 <minimal> so not just limited to a Grub issue
2023-06-16 18:50:35 <tomalok> yeah, fsck is kinda important.
2023-06-16 18:51:18 <minimal> well older versions of fsck won't fsck with a filesystem containing an option (orphan_file) that it doesn't know anything about
2023-06-16 18:52:23 <tomalok> so, a rebuild it is.
2023-06-16 18:52:39 <tomalok> fortunately didn't publish yet
2023-06-16 18:53:08 <minimal> so even when Syslinux is being used if you've created rootfs using 3.18 mke2fs which is setting orphan_file then I guess <= 3.17 would run happily until the first time a fsck is required and then refuse to work...
2023-06-16 18:54:39 <tomalok> yep
2023-06-16 18:58:13 <minimal> wondering WWGD? lol
2023-06-16 18:58:32 <minimal> or rather WWCD
2023-06-16 18:58:43 <minimal> what-would-chatGPT-do? ;-)
2023-06-16 19:15:07 <tomalok> well, local image builds don't take that long with --parallel 8 ... the whole set is done ... what will take a while is uploading/iimporting...
2023-06-16 22:32:21 <tomalok> ikke (etc.) PR to update https://alpinelinux.org/cloud for the latest releases -- https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/64
2023-06-17 00:10:43 <thresh> \o/ 3.18 aws images seem to boot fine for me.
2023-06-17 10:31:48 <ikke> tomalok: merged and pushed to production
2023-06-21 03:08:04 <thresh> hey.  It looks like alpine 3.18 EC2 images do not attempt fetching userdata when launched a second time?
2023-06-21 03:08:33 <thresh> I mean, I'm creating my own packer image based on 3.18, and it's all good;  but when I'm launching that image, I don't see instance-level user-data applied on that VM start
2023-06-21 03:08:44 <thresh> I've checked and curl http://169.254.169.254/latest/user-data works fine
2023-06-21 03:10:26 <thresh> looks like tiny-cloud early does not overwrite whatever it had before
2023-06-21 03:11:30 <thresh> ah https://gitlab.alpinelinux.org/alpine/cloud/tiny-cloud/-/issues/46 this is already filled out
2023-06-21 03:12:17 <thresh> so I guess as a workaround I can rm .bootstrap-complete when I'm creating my image
2023-06-21 03:13:09 <thresh> and/or userdata file
2023-06-22 00:03:28 <tomalok> thresh: you can tiny-cloud --bootstrap incomplete to force the bootstrap to happen on the next boot -- but 46 notes it doesn't re-pull user-data if it's already there.  so a workaround for the interim is to rm /var/lib/cloud/user-databefore the reboot
2023-06-22 00:04:15 <tomalok> (bootstrap must also be marked incomplete, too)
2023-06-22 18:26:51 <papertigers> I don't know if this is the best place to ask but I have a question about cloud-init. My config (NoCloud) provides a new name for an ethernet device.  However things seem to happen out of order.  /etc/init.d/networking fails to bring the interface up because it doesn't yet exist.  However when I login to the box I am able to see the new name in /sys/class/net/ -- So if I run
2023-06-22 18:26:53 <papertigers> /etc/init.d/networking restart it then brings the interface up properly.  Does anyone know where I would look to fix this? Perhaps I need to change the order things are depended upon?
2023-06-22 18:41:15 <papertigers> seems like there needs to be a dependency on devfs somewhere
2023-06-23 11:06:45 <minimal> papertiger: Hi, I'm the cloud-init package maintainer. NoCloud should setup /etc/network/interface early in boot and then /etc/init.d/networking should bring it up. Have you looked at /var/log/cloud-init.log to see what is happening? Can you provide details of the network-config.yml you are using? (I assume you are using NoCloud with a "cidata" ISO)
2023-06-23 11:07:03 <minimal> papertigers: ^^^
2023-06-23 13:42:20 <papertigers> minimal: what seems to happen is the udev rules arent taking effect when /etc/init.d/networking is started
2023-06-23 13:43:30 <papertigers> Logging in and running /etc/init.d/networking restart brings up the interface properly by the time I login becuase the interface name has actually been mapped to the correct name
2023-06-23 13:44:06 <minimal> papertigers: you need to provide some more info to diagnose this
2023-06-23 13:44:27 <minimal> I'm pretty sure I have renamed interfaces in the past successfully
2023-06-23 13:49:04 <papertigers> minimal: I can get some logs
2023-06-23 13:49:26 <minimal> also info on the cidata files you are using
2023-06-23 13:52:10 <papertigers> minimal: https://gist.github.com/papertigers/39d8a75e1421d33a902c520b9f7a9c4e
2023-06-23 13:52:34 <papertigers> I don't have time at the moment to collect everything.  But here's networking starting before cloud-init-local
2023-06-23 13:53:08 <papertigers> and at that point the udev rules don't seem to have been applied yet
2023-06-23 13:57:13 <minimal> papertigers: why are the hostname and networking init.d scripts running BEFORE cloud-init?
2023-06-23 14:01:35 <minimal> I'd expect to see the cloud-init "init-local" output (in "boot" runlevel) BEFORE "Setting hostname" (in "boot" runlevel) and "Setting networking" (in "default" runlevel)
2023-06-23 15:04:23 <papertigers> minimal: ah that may be the piece I was looking for!
2023-06-23 15:04:40 <papertigers> Are there official docs for cloud-init on alpine anywhere?
2023-06-23 15:06:42 <papertigers> minimal: should cloud-config and cloud-final be in boot as well and not default?
2023-06-23 15:27:19 <tomalok> iirc cloud-init has a setup-cloud-init command that should set up all the init scripts in the right place?
2023-06-23 15:31:08 <minimal> tomalok: it will set cloud-init's init scripts correctly, it won't touch other init scripts however
2023-06-23 15:31:49 <minimal> papertigers: the cloud-init-doc package contains a README.Alpine file
2023-06-23 15:32:12 <minimal> papertigers: did you run setup-cloud-init when you installed it in the image you created?
2023-06-23 15:32:48 <papertigers> nope, that's the missing piece I believe.  I will recreate this image with the proper modifications and run that before turning it into an image
2023-06-23 15:34:03 <minimal> papertiger: when you "apk add cloud-init" the output on the screen DOES SAY to run setup-cloud-init. Should I make it 24 point, red, and flashing? ;-)
2023-06-23 15:34:32 <minimal> i.e. https://git.alpinelinux.org/aports/tree/community/cloud-init/cloud-init.post-install
2023-06-23 15:36:22 <papertigers> minimal: I chose the trial and error path I guess :( 
2023-06-23 15:36:35 <papertigers> thanks for the help and sorry for blowing past the instructions