unfortunately the "mkusb-installer" is no longer available as it seems as it was the most easy way to install it on debian

you can find a newer version here

https://phillw.net/isos/linux-tools/mkusb/

where the "mkusb-min" and "mkusb-minp" failed to create a proper beowulf netinst64bit iso-stick (at least on my pc) , the newer "dus" version from phillw.net functioned.

i installed several times in the last days devuan ascii and beowulf.

used "mkusb" to install to usb (look for "install to debian" version) and had no problems with netinstall64bit.
problem only with beowulf-live image 64 bit that gave errors during installation and after insatllation it booted the old linux (that was meant to be replaced) as if nothing was installed over it. i am not sure if i made an error but to me it seemed the live-installer was faulty.
maybe someone can confirm this?

I have managed to install after a second attempt devuan ascii, how ever my mda5sum / sha256sum check showed a discrepancy on the contents (from image) loaded to my flash drive, yet i managed to install ascii.
As ralph.ronnquist mentioned on 2019-11-18 23:29:06 that isolinux/isolinux.bin is left out because its md5sum count changes after installing on flash drive.
I am wondering if it applies the same to the rest of the files. ???
I ask this question since I had many problems with installing devuan jessie and getting it to work, until i did a sha256sum check on my downloaded file and found it corrupt. I re-downloaded the devuan_jessie_1.0.0_amd64_CD.iso file, sha256sum checked out, and re-installed. A number of the problems vanished including trying to get hplip to see my scanner (via hp-setup). So the same could be said for ascii.

How ever Altoid makes a very compelling argument on 2019-11-20 22:00:50 alluding to the fact that corruption can also occur in writing to flash drive. As can be seen by my results above my image seems a problem yet my installation went fine after second attempt.

fsmithred mentioned on 2019-11-19 15:03:35 a valid point: which i personally have experienced on both jessie and ascii and that is for whatever reason the installing of software and even boot loader (grub2) fails, on re-trying 'it came right'. Not a very stable installation though. I don't recall having this on ubuntu or linux mint, or puppy, knoppix etc! Not sure if it is due to large amounts of data needing to be downloaded to complete the installation, yet i expected devuan_ascii_2.1_amd64_dvd-1.iso to be a far more easier installation in this regard, since it did not require much download to complete the installation. Most files were in the iso. Yet it too was a problem.

IN CONCLUSION
So far my installed ascii does not show any signs of corruption. I installed a couple of programs that i use and they all went fine. I even installed my hp scanner the quickest way i found, by using hp-setup -i in command line.
I think it will be safe to say that if the flash drive being used is in question buy another one (good make), sha256sum check the downloaded iso with the sha256 values provided by devuan and write to flash as normal.
During installation: Make sure apt package manager is updated correctly, retry if having trouble. Retry any software failures and or bootloader install failures.
This is about the best advice i can give.
Devuan iso's have brilliant partitioning utility in their installer but the installation with setup has been the most difficult out of any linux so far. I entertain all the nonsense because i want to boot up with initd NOT systemd! I found devuan very fast on an old Intel Core 2 duo core E7500 PC, 4 Gb ram. 

You can make an iso that boots uefi or bios with refractasnapshot. See the config file. See the xorriso command in the script itself. There are a couple of options needed for uefi. If you have questions, we can talk about it in a separate thread.

NAME_OF_ISO would be the name of the .iso file you are creating. With just the file name and no path, it would be created in the current working directory. Add a path if you want it to land someplace else.

ISO_ROOT_OF_FILES is the top-level directory of the file tree you want to put inside the iso. Typically, it contains an isolinux directory and a live directory.

mkisofs -o NAME_OF_ISOIMAGE -b isolinux/isolinux.bin -no-emul-boot -boot-load-size 4 -boot-info-table ISO_ROOT_OF_FILES

Do I replace NAME_OF_ISOIMAGE with the location of the iso?
also what do I replace ISO_ROOT_OF_FILES with?
I have working Iso, However,  I had used refracta snapshot to get it. It dd s just fine. (So I am in no rush to try a minimal and build a new one but I noticed I have over 1500 packages trying to debloat a bit .

Issue is, isn't -b bios boot only?(wow this conjunction xD) I would like to get a EFI booting Iso. would I use -e instead?
I am happy with bios boot on my thinkpad, however, sometime EFI is easier to work with as I'm planning to make a more minimal Iso. (so I may have 2 partitions temporarily for easier backups)  Maybe, eventually I'll remove the efi grub tools.

PS: I have not tried rufus on windows. last time I used that was probably couple years ago when I did my first bare metal install  not counting wheezy on a pi. Now I'd prefer to build the iso on linux. DD has worked fine up untill now. If mkisofs is the best way to do things I'd gladly switch and figure it out.

Note that isolinux/isolinux.bin is the "El Torito boot image", and that mkisofs does something to the first 64 bytes on transfer from disk to CD/DVD image, i.e. when the .iso is created.

Why not use something like tail --bytes=+64 isolinux.bin | md5sum to skip the first 64 bytes. That should tell you if the bulk of the file is OK.

Chris

mkisofs -o NAME_OF_ISOIMAGE -b isolinux/isolinux.bin -no-emul-boot -boot-load-size 4 -boot-info-table ISO_ROOT_OF_FILES

The parameter "-boot-info-table" is essential, to get it working. But this parameter does the following: it modifies isolinux.bin itself during the build of the isofile. A previously created checksum will never match after that! That's why this special file should be always excluded from such checksum-tests.

Or in other words: It is not a bug, it is a feature ...

Best Regards, FM_81

I got the hash to match if I dd it into a partition rather than just the root of the drive.

Same here.

It has to match exacly.
Seemed won't do. 

Just pulling your leg ...   =-D

In my limited experience, the first check you do is on the *.iso file you downloaded.

Then you do a check on ther file burned on the CD/DVD or USB.

I found a way to do this here:
https://askubuntu.com/questions/547332/ … -boot-disk

The third and final step is to boot the installaiton *.iso and run a check on the installation media itself with the tool available in the menu.
Although, as we have seen in this thread, it can sometimes give a false positive.

Cheers,

A.

However, downloading and verifying the check sum seemed to match for the iso.

When I dd it onto a USB. Try to boot to it, I get grub but than an error it wont boot the kernel. Missing magic number you need to load the kernel first'.

Not sure what went wrong. Usually that's all I need to do is dd it to a bootable USB and check the hash.

OK.

OK.

OK.

It's all rather over my head/pay grade.
Eventually, I guess ...

I computed them in a teminal so it would be hard to make a typo and checked the values twice.

A coincidence?
 
This isolinux.bin only came up because of my checking the installation media with the install's verification routine.
The *.iso file was intact after download and was correctly written to media.

But as you pointed out, the issue did not come up in the 2.0.0 *.isos because isolinux.bin was not in the respective md5sum.txt file. 
It was not scanned, ergo no error was computed.   =-)

Agreed ...
As I mentioned in my email, due to a USB stick with not enough space.

I suppose then that all is well?

Thanks for taking the time to look into this.

Best,

A.

f03d6ecc57dad4524a0cab76b7afab41

I checked some Refracta isos and the i386 and amd64 are different (assuming for the same reason as the desktop-live) but the md5sums are consistent over time and only change occasionally. Possibly with new versions of isolinux or something else.

Getting back to the original post, I think the problem with installing software is not related to isolinux.bin. Sometimes the installer fails to get all the software and you need to repeat that step. This was more common with jessie isos, but I think it's happened with ascii, too.