Drop override of /etc/issue on installer #478
Conversation
No need to overwrite anything on install, we already have the branding on /oem that sets the /etc/issue and can be override by derivatives Signed-off-by: Itxaka <igarcia@suse.com>
| @@ -222,27 +222,6 @@ do_copy() | |||
| get_url "$COS_INSTALL_CONFIG_URL" $OEM | |||
| chmod 600 ${OEM} | |||
| fi | |||
| mkdir -p $TARGET/usr/local/cloud-config | |||
There was a problem hiding this comment.
What about having a similar flag for copying a file over here like we do for /oem?
There was a problem hiding this comment.
sure, the problem is not that I dont know how to do it. The problem is more philosophical, should we actually do it? what brings to the table, what are the advantages to it, what are the cons (more maintenance, another possible failure entrypoint), etc..
As I commented on the issue, I just dont see a user case for this when we have the user-data for deployment configuration AND the COS_INSTALL_CONFIG_URL for the installer, feels like going overboard with this.
There was a problem hiding this comment.
my opinion in this is that there is a location meant for user usage, like /usr/local/.. and /oem. I see it like this: if you are a sysadmin and have some users in the host (well.. always a possibility right) you might not want to give them access to /oem, but you might want to give a narrowed down version of it which is inside COS_PERSISTENT. This is also a way to workaround the fact that COS_OEM has a fixed size, kept small intentionally, and you could potentially encode chunk of binaries via YAML
There was a problem hiding this comment.
I really dont see the use case of a derivative having users in the sytem tbh, like that is so far away from the current mood in the IT world 🤣
The space issue could be a problem indeed but...like there is the correct way to add binaries to the system by bulding packages, if someone wants to drop binaries during the install...like we cannot support all the cases in the world. A user could potentially do that, but they could also scp files into COS_OEM, or download an ISO or just create a huge file, etc... there is no way we can protect against all those things except pointing it to the proper way of deploying binaries (create a package, do your stuff in there, will end up as part of the system)
There was a problem hiding this comment.
If you really think this is important, lets create a card to follow up on that so we dont forget about that 👍
* Add multi-arch support for pulling images This commit refactors the image pulling and extracting to be able to cross-build isos. In order to do this we make use of go-containerregistry and containerd to pull and extract the image. This refactor also removes alot of luet functionality mostly used for build-disk command which has been deprecated. * Introduce Platform struct Keep --arch flag and use both --arch and --platform to parse into new struct. The struct keeps both arch and golang-arch, since x86_64 and amd64 are used in different contexts (grub/efi artifacts vs container platforms). If both --arch and --platform are specified platform takes precedence. Platform flags are also added to install-command in order to be able to cross-arch install to loopback-devices. Signed-off-by: Fredrik Lönnegren <fredrik.lonnegren@suse.com>
No need to overwrite anything on install, we already have the branding
on /oem that sets the /etc/issue and can be override by derivatives
Closes #163
Signed-off-by: Itxaka igarcia@suse.com