Does the Dell N7110 meet the minimum system requirements for Ubuntu 18.04?

[sudodus]

A short explanation: mkusb can clone, and that is by far the best method for more than 90 % of the cases, when you want to create a USB boot drive.

- cloning - copy 1:1 from the iso file to the target device, robust method, creates live-only drives from Ubuntu family iso files.

- creating persistent live systems - in these cases you must do something more complicated than cloning, and mkusb has 3 different methods, that may fit different users and computers

. dus-persistent - the classic mkusb way to make persistent live drives

. dus-iso2usb - new, can be used both to make persistent live drives and live-only drives, can work where other methods fail (even where cloning fails or is very slow in some old computers)

. mkusb-plug - can clone to make live-only drives and 'semi-clone' to make persistent live drives with as little modification as possible of the boot structure from the iso file. 'semi-clone' works with Ubuntu family iso files with version 20.04.x LTS and newer (not with 18.04.x LTS). The name 'plug' is due to the special method to identify the target device (developed by Thomas Schmitt).

---

All mkusb versions and methods have one feature in common: They help the user find the correct target device (and avoid overwriting valuable data on other devices). This was actually the original reason why it was developed, and has still a very high priority.

[John_Patrick_Mason]

Sorry for the late reply, this is still an active thread. Like you, I'm trying to juggle the daily requirements of life with other things.

However some software re-organizes the ISO as it writes to media (to provide extra features, eg. persistence etc) which can create the failure to boot as you describe

Now that I think of it, I do remember trying to create a persistent drive for the privacy-focused distro, which failed to boot, after successfully creating a bootable non-persistent USB flash drive. I'm not sure which tool I used, probably `dd`, given that I was more familiar with that command than `mkusb`, at the time.

So, let me make sure I understand everything you wrote. Assuming I'm using a later version of Ubuntu, such as Ubuntu 22.04, and either `dd` or `mkusb`, if I create a bootable USB flash drive and attempt to boot from the drive on box 1, and later on box 2, and booting fails on box 1 and box 2, then, in all likelihood, the issue is caused by a bad write, either because I got unlucky because of the 5-8% failure rate of the USB thumb drive or because the software that I used to create the drive reorganized the ISO if I was trying to create, say, a persistent drive, but if booting fails only on box 1 but succeeds on box 2, then, in all likelihood, the BIOS/UEFI firmware on box 1 is just being difficult and I should rewrite the USB thumb drive in a different way?

I tend to use `mkusb` as I overwrote a 2TB data drive, then a 11TB drive array...

Stuff happens. I guess that's why it's sometimes called "disk destroyer."

[guiverc]

So, let me make sure I understand everything you wrote. Assuming I'm using a later version of Ubuntu, such as Ubuntu 22.04, and either `dd` or `mkusb`, if I create a bootable USB flash drive and attempt to boot from the drive on box 1, and later on box 2, and booting fails on box 1 and box 2, then, in all likelihood, the issue is caused by a bad write, either because I got unlucky because of the 5-8% failure rate of the USB thumb drive or because the software that I used to create the drive reorganized the ISO if I was trying to create, say, a persistent drive, but if booting fails only on box 1 but succeeds on box 2, then, in all likelihood, the BIOS/UEFI firmware on box 1 is just being difficult and I should rewrite the USB thumb drive in a different way?

Not really. I sort of know my boxes and the firmware in them mostly due to loads of experience booting ISOs written in various cycles of Ubuntu development.

In understanding ISOs written to media; I'd trust what @sudodus says, given he is a maintainer/developer of `mkusb` thus understands the issues far more thoroughly. Me, I'm really just a QA-tester in this regard and much of my knowledge is based on experience in QA, and I'd trust Sudodus over me.

I've found a ISO written to thumb-drive may fail to boot on another like boxes (eg. if I want to install on a BIOS/legacy/CSM box but it fails to boot; it may fail on other BIOS/legacy/CSM boxes, but successfully boot on uEFI/Secure-uEFI boxes) but boot successfully on uEFI/Secure-uEFI boxes. Thus I tend to treat
- BIOS/legacy/CSM
- uEFI
- Secure-uEFI
rather separately (and thus if it boots in one box; it'll usually boot in others of the same class).

With Lubuntu, those three are treated separately in our QA (Quality Assurance) testing, as is shown here and here as it's a flavor I'm heavily involved with. Lubuntu isn't unique though; if we have problems with a specific type of box - the next thing we do is confirm Ubuntu is also impacted, then another flavor too; as all will be impacted in 99% of cases. Our testing though in QA ensures all released products should boot in all modes if correctly written (eg. cloned to USB media), but that's not really an assumption I can make using dailies of an unreleased product. If however you're talking about a non-cloning write of ISO to media; I'm tempted to also assume nothing too. For the non-cloned ISOs written to media; I've found the types I've mentioned tend to act very much in groups (outside of firmware issues such as some uEFI & even some BIOS/CSM boxes booting very slowly with recent media; these unique firmware issues I cannot predict before they occur).

In summary; if it boots in other boxes of the same types I've specified here; I'll feel more confident in a successful write, though if it was me, I always jump to terminal & scan the systemd journals to ensure scan of media completed successfully (if it was older releases like 18.04 there is a menu item that performs this as it wasn't automatic though errors are still pretty easy to detect as squashfs errors). Failures to boot though don't allow you to scan any logs.

Please also note: As a boxes firmware can be different to other boxes; you cannot really assume anything (unless you have an exact duplicate make/model that you've checked booted with an OS & noted the firmware was actually identical); thus it's more confidence for mewith regards a successful write.

I apologize if I've clouded the issue for you.

[John_Patrick_Mason]

I apologize if I've clouded the issue for you.

No need to apologize. At least I now know that, sometimes, when a bootable USB flash drive fails to boot, it can be because of the particular BIOS/UEFI firmware on the box, assuming the ISO was written correctly.