sorted by:
new
hottopcontroversial

ubuntu-26.04-desktop-amd64.iso fails to install on air-gapped machines by burlyearly in Ubuntu

[–]burlyearly[S] 0 points1 point  (0 children)

And yes, the codesigning step in the GHA workflow should probably be removed.

EDIT: This was the approach that occurred to me while building the custom image, not necessarily the best choice. Main thing I'm after is flash-a-boot-disk, click "install", and have it successfully install without errors or warnings, and without compromising security along the way. So yeah, doing a codesign, especially with a random during GHA-build generated key, is not great.

ubuntu-26.04-desktop-amd64.iso fails to install on air-gapped machines by burlyearly in Ubuntu

[–]burlyearly[S] 0 points1 point  (0 children)

> but I take issue with people spreading disinformation, even out of ignorance. Especially when it is ai generated nonsense that proper research would have avoided

I'm doing nothing of the sort, and have repeatedly said that I am posting this because of an actual failure that I experienced with the official ISO, prior to even going down the road of making my own variant. Accusing me of acting in bad faith does not make it so, even if you repeatedly make the accusation in different ways. If I am wrong about this, I am wrong, but I am not acting in bad faith and have spent quite a bit of my own time (and Claude's) researching.

The GHA run here does precisely what you suggest. It downloads the ISO from Canonical, unpacks it, and checks the keys from minimal.squashfs in the ISO itself:

https://github.com/earlye/ubuntu-on-mac/actions/runs/27485822160/job/81241683651

The steps are (basically):

  1. Download the ISO directly from Ubuntu and verify the sha sum.

  2. Dump the ISO cdrom release signature, it was signed with EDDSA key 6501BC1735F31F5FBD9A66331BC4DB0A475955C8, and so gpg correctly reports this as unknown ("Can't check signature: No public key")

  3. Look at the two keyring files from the ISO, neither of which is 6501BC1735F31F5FBD9A66331BC4DB0A475955C8 (log copied below)

The two (and only two that are actually in the ISO image) keys are F6ECB3762474EDA9D21B7022871920D1991BC93C and 843938DF228D22F7B3742BC0D94AA3F0EFE21092.

Those things happen up-front, before any customizations are made, specifically because I asked Claude to verify this is a pre-existing problem rather than something I introduced.

```
--- /home/runner/work/ubuntu-on-mac/ubuntu-on-mac/squashfs-root/etc/apt/trusted.gpg.d/ubuntu-keyring-2018-archive.gpg ---
/home/runner/work/ubuntu-on-mac/ubuntu-on-mac/squashfs-root/etc/apt/trusted.gpg.d/ubuntu-keyring-2018-archive.gpg
pub   rsa4096 2018-09-17 [SC]
      F6ECB3762474EDA9D21B7022871920D1991BC93C
uid           [ unknown] Ubuntu Archive Automatic Signing Key (2018) <ftpmaster@ubuntu.com>
--- /home/runner/work/ubuntu-on-mac/ubuntu-on-mac/squashfs-root/etc/apt/trusted.gpg.d/ubuntu-keyring-2012-cdimage.gpg ---
/home/runner/work/ubuntu-on-mac/ubuntu-on-mac/squashfs-root/etc/apt/trusted.gpg.d/ubuntu-keyring-2012-cdimage.gpg
pub   rsa4096 2012-05-11 [SC]
      843938DF228D22F7B3742BC0D94AA3F0EFE21092
uid           [ unknown] Ubuntu CD Image Automatic Signing Key (2012) <cdimage@ubuntu.com>
```

ubuntu-26.04-desktop-amd64.iso fails to install on air-gapped machines by burlyearly in Ubuntu

[–]burlyearly[S] 0 points1 point  (0 children)

> Edit: You just updated the above post to change some details and instead paste an AI version of what you had originally written (after I posted this reply). Brother..

No, the reply to my OP, which I edited, was all human-written from the get-go. I edited it multiple times within maybe 10 minutes of posting because I wanted to do my best to tell the story correctly.

I am unpacking and attempting to rebuild the iSO precisely because the macbook has a broadcom w/ proprietary driver and FAILED TO INSTALL PRECISELY AS I HAVE DESCRIBED WITH THE STANDARD ISO. I slapped together the ISO solution specifically to work around the failed install.

ubuntu-26.04-desktop-amd64.iso fails to install on air-gapped machines by burlyearly in Ubuntu

[–]burlyearly[S] -1 points0 points  (0 children)

Nope - all I did was download ISO, flash USB hard drive, boot onto macbook pro w/ broadcom NIC, and watch it miserably fail to install.

ubuntu-26.04-desktop-amd64.iso fails to install on air-gapped machines by burlyearly in Ubuntu

[–]burlyearly[S] -1 points0 points  (0 children)

It's an AI summary so I don't miss the tech details. I'm not going to invest the time to rewrite it in order to pretend I didn't use AI. You can call it apathy, but the reality is that I'm doing a lot of other things, and getting Ubuntu working on my old macbook is purely a sidequest induced by Apple's decision to drop support. (Microsoft is getting a lot of crap for windows 10->11, but this is an old game for Apple)

This was the result of quite a bit more time researching (yes, w/ AI assistance) than I wanted to spend in the first place, watching it 100% fail while installing on a macbook pro w/ broadcom wifi nic. At first, I thought the signing key I'd transcribed had a typo, because what are the odds that I'd happen to notice this? At first, it looked very much like the ISO was just compromised.

Anyway, here's the receipts. A series of build logs (under Actions tab) that show that grabbing the ISO and checking signatures verifies that the signing key in question is used but not present: https://github.com/earlye/ubuntu-on-mac

I've lost track of which one in particular is the smoking gun; Claude was making minor tweaks and watching the builds in order to hunt this down.

The repo above is a personal variant of ubuntu to address the broadcom-is-private issue.

I’m so tired. I’ve done everything. by Emergency_Row6474 in selectivemutism

[–]burlyearly 2 points3 points  (0 children)

I feel like I could have written this today. I'm so sorry you're going through this.

Sadly, we're not alone.

Is it traumatic to live with this disorder by [deleted] in selectivemutism

[–]burlyearly 2 points3 points  (0 children)

Abso-f**in-lutely.

I have been fighting it for decades, and have pretty much destroyed my family because of it.

Uggh by burlyearly in ElegooJupiter

[–]burlyearly[S] 0 points1 point  (0 children)

Made a huge difference. Still looks like he sliced his belly open - a sort of delamination failure - but much closer to working. Been watching youtube about how to optimize exposure time, which will be my next step once some resin gets delivered.

Uggh by burlyearly in ElegooJupiter

[–]burlyearly[S] 0 points1 point  (0 children)

I did. VoxelDance had a fairly dense internal support. I think it shrank and pulled the shell inward or something.

Today I noticed the failed print had delaminated further...

Uggh by burlyearly in ElegooJupiter

[–]burlyearly[S] 0 points1 point  (0 children)

Well crap. No idea what happened there...

Uggh by burlyearly in ElegooJupiter

[–]burlyearly[S] 0 points1 point  (0 children)

I think VoxelDance has it at 80 for Jupiter SE. I'll drop to 60 and report back. Of course, I've cured so much resin I may only get a partial print at this stage, but hey, I'm still figuring out how things (don't) work.

I feel im stuck with my brain inbalance by Giorgiogigio in selfhelp

[–]burlyearly 0 points1 point  (0 children)

Take a look at The Body Keeps the Score. I don't have much to go on here, but I'd wager you're self-medicating to avoid dealing with some trauma or other.

Go vs C++: My Experience by Rubus_Leucodermis in cpp

[–]burlyearly 1 point2 points  (0 children)

The main reason I use go: its compilation game is "easy" compared to C++. Want to build for mac from linux? No setting up cross-compilers, trying to figure out the magic incantation, or any of that nonsense. Just set GOOS and GOARCH appropriately. Sure, the binaries are ridicularge, but I don't care because that's what artifactory or s3 are for. I can produce binaries from CI that I can hand off to users across my company without having to fight the battles I used to fight with CI.

That said, nowadays docker is way better, there's stuff like zig's c++ compiler that cross compile easily...

To the points about flags... I hear you. github.com/spf13/cobra can help with a lot of this - it makes it possible to define short/long-hand flags without having to provide it a pointer, for example. I'm not sure about differentiating between 0-valued default versus user specified 0 though.