Something's not quite right with the installation image..

[nononsense]

So I went to https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/ to get the hybrid image to be written on a USB drive.
I'm on a Windows system, so I resorted to Win32DiskImager which has consistently worked well in the past and still works fine... except when
it comes to Debian image (specifically, the debian-10.0.0-amd64-xfce-CD-1.iso). At first I suspected Win32DiskImager to be the problem
which wasn't the case as I've tested with openSUSE and Archlinux isohybrid image and they worked without a hitch (even tried using Etcher just to confirm).
Then, I tried to verify the checksum of my image in case it got corrupted during download but it matches with the one listed for XFCE iso.

The problems? The resulting bootable drive isn't booting in UEFI. It can still boot though with a caveat... The boot option is labelled "Linpus Lite".
Isn't it weird for other distro's name to come up? A fedora-based distro no less. As of now, I'm thoroughly confused

[phenest]

The boot option is labelled "Linpus Lite".

Where are you seeing this? Your computers boot manager?

[nononsense]

Where are you seeing this? Your computers boot manager?

Yeah. It's during boot but not in UEFI though. Other distros' image and even the older 9.9 *Debian image iso boot fine in UEFI but not with
debian-10.0.0-amd64-xfce-CD-1.iso from https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/.
The name "Linpus Lite" also shows up if you were to "Use device" (Windows menu where you get from clicking "Restart" while holding your shift key).

*It does boot in UEFI, but CD integrity check always fail and I already made sure the image isn't corrupted by verifying the checksum

[nononsense]

You know what? I believe that I've had a probable answer as to why "Linpus Lite" is listed; It's most likely because of my laptop. It's made by Acer and I read that some
Acer made laptop are pre-installed with Linpus Linux and they probably have the firmware detect every Linux distro as such since my openSUSE live USB too ,apparently
listed as "Linpus Lite" from Windows' "Use drive" menu. I didn't notice this initially as it booted fine in UEFI that I didn't even go the "Use drive" menu from Windows to
try to figure out what went wrong.

That's one mystery unraveled. But still, my Buster USB drive wouldn't boot up in UEFI despite the resulting USB drive has EFI partition to show. I've eliminated the chance of
a corrupted iso image as I mentioned in my previous post that I've verified the checksum. It also isn't a problem with the writing software (Win32DiskImager) as I've tested it multiple times with other distro's images and only Debian consistently fail to boot in UEFI. Any suggestions?

[phenest]

*It does boot in UEFI, but CD integrity check always fail

Does that mean you can't install it?

I've downloaded that image, burnt to a CD, and booted via UEFI and legacy, and I can't see "Linpus Lite" anywhere. And I've installed it without issue.

[nononsense]

*It does boot in UEFI, but CD integrity check always fail

Does that mean you can't install it?

I've downloaded that image, burnt to a CD, and booted via UEFI and legacy, and I can't see "Linpus Lite" anywhere. And I've installed it without issue.

Regarding the Linpus Lite thingy, I've addressed it in my previous post. I still can't successfully install Buster with the installation image written to a USB drive. It just won't boot in UEFI. I see that it's working fine on your side. I'm quite surprised myself that it didn't boot on my system. Well, I guess I'll try to download the image again and see if there's any difference. Please note here that I'm writing in on a USB drive instead of a CD.

Anyway, thanks for taking the trouble and share the outcome.

[nononsense]

Here's my latest finding from the latest attempt at using debian-10.0.0-amd64-xfce-CD-1.iso written to a USB drive using Win32DiskImager.

This time around, I tested with 2 different setup; a laptop with i5-6200U and a Raven Ridge(Ryzen 2200G) on AMD B350m platform.
I'll do the breakdown for an attempt on these 2 setups as below:

1.Laptop
I have the laptop configured to boot up in UEFI and prioritise external USB drive to boot from. Contrary to what I said in my previous post, the Buster
installation media did boot in UEFI mode (I only realized after I tried to boot in BIOS mode) but I had to manually choose from boot manager despite
the priority setting (I don't have to do this with other installation image). From here, I tried to verify CD integrity using the installer option and I got this
The ./boot/grub/efi.img file failed the MD5 checksum verification. Your CD-ROM or this file may have been corrupted. I didn't go through
with the installation.

Is this verification failure is expected if you burn installation image to USB drive instead of CD?

2.Desktop PC
Progress was even worse on this setup. I only got as far as the welcome screen (where you choose to Graphical Install, text install, speech synthesis and etc.) in
UEFI mode before the screen froze in language option. In BIOS mode, I reached the installer, but the CD won't load. That was as far as I get. This setup has 2 graphics cards; onboard and external (AMD RX570). Could that be the reason the installer froze in UEFI mode? But that doesn't really explain why it can't detect the installation CD in BIOS mode I presume.

Am I the only person facing this?

[phenest]

What happens if you burn that iso to the usb drive using Linux software? It shouldn't make a difference, but you never know.

[Deb-fan]

^ Agree with him. Have had dd fail, whereas last I checked Debian docs advise using the cp command. So it's how I do it now and seems to always work.

[nononsense]

What happens if you burn that iso to the usb drive using Linux software? It shouldn't make a difference, but you never know.

I tried using balenaEtcher which I don't suppose is a strictly Linux software in comparison to utility like dd and cp. To do that, I'd probably
have to find older Debian installation image that works first as I'm not currently in possession of a working Linux system. I'll get back here to share
if I find anything useful.

^ Agree with him. Have had dd fail, whereas last I checked Debian docs advise using the cp command. So it's how I do it now and seems to always work.

Hate to admit it. This whole hit or miss thing is frustrating at times. I believe the docs could use some renovation. Last time I checked, there's a mention of ISOHYBRID not occupying the whole device and therefore you can add another partition for persistence storage to store missing firmware or use it like normal flash drive. I don't think that this will work though since ISOHYBRID has overlapping partition to work the magic of being capable to be written on both CD and USB drive.

I may appear to come up with response at odd times which is due to my timezone (GMT +8). So, pardon me if it's not too convenient.

[Deb-fan]

Dunno, would still say follow the docs. Somebody had to spend tons of time writing it all. You can use another gnu/nix usb-etc, Arch or OpenSuse in live session to create a Debian media. Granted that's a bit convoluted though. Could very well be windows freeware that will do dd too. Gonna shut it but where there's a will there's ways.

[phenest]

Whether you use dd, cp or some other Linux software, it's a better idea than using Windows stuff.

I like dd instead of cp because you can watch its progress by appending status=progress. Handy for slow usb drives and I don't know if that can be done with cp.

[nononsense]

This post here is to clarify things up for those who may have the same wonder and happen to stumbled across this post. The problem that I have in booting the Buster image has my laptop's broken UEFI implementation to blame for. There seems to be a change between Stretch and Buster image that causes the broken laptop firmware not booting it up automatically (requires intervention such as pressing F12 and etc.)

1.Laptop
I have the laptop configured to boot up in UEFI and prioritise external USB drive to boot from. Contrary to what I said in my previous post, the Buster
installation media did boot in UEFI mode (I only realized after I tried to boot in BIOS mode) but I had to manually choose from boot manager despite
the priority setting (I don't have to do this with other installation image). From here, I tried to verify CD integrity using the installer option and I got this
The ./boot/grub/efi.img file failed the MD5 checksum verification. Your CD-ROM or this file may have been corrupted. I didn't go through
with the installation.

I've figured out why the verification failed each and every time I wrote the image from Windows system. It's because Windows write System Volume Information on any filesystem it can understand (EFI boot partition in this case) which causes the checksum to fail. Conclusion? Win32DiskImager and Etcher work the way they should in making installation media on Windows. Just don't count for any built-in verification tool to pass as Windows may add the aforementioned file to any filesystem it understands which ultimately changes the checksum of the image.

Last time I checked, there's a mention of ISOHYBRID not occupying the whole device and therefore you can add another partition for persistence storage to store missing firmware or use it like normal flash drive. I don't think that this will work though since ISOHYBRID has overlapping partition to work the magic of being capable to be written on both CD and USB drive.

I stand corrected here. The docs is right. You may add partition on an ISOHYBRID. Just not using the same device from which you boot i.e. using the same live installation USB drive to boot and create the partition using the same USB drive from which the live system was booted.