Howto make USB boot drives

[oygle]

Dell's link looks good. Please notice that there is a difference between systems 2015 onwards and systems before 2015. I found documentation for your computer model from 2014, but the computer might still be manufactured 2015 onwards, so I don't know what to select.

Thanks, I have since been notified by Dell that it is a 2014 model.

Maybe it is safest to use FreeDOS.

Yes, probably.

- Disks alias `gnome-disks`is a tool to do several tasks with mass storage devices (disks, drives), and it is bundled with Ubuntu and several (maybe all) Ubuntu community flavours.

Okay, I guess if that is the tool they suggest, I'd better use that. Thanks for your help.

[marks2]

I've been using a persistent flash drive made with mkusb for a few weeks. The drive made with mkusb is more reliable than the other flash techniques including a full install to a flashdrive (actually all the other approaches corrupt within a day or two).

I know it's usually suggested that you can't upgrade grub on a persistent flashdrive, but since mkusb creates a real partition (not a iso file), I'm wondering if a method has been worked for making necessary upgrades.

In particular, I would like to upgrade grub to allow the insertion of the intel microcode. This is in response to the Meltdown/Spectre memory threat. If there was some minor concern about drivers I would not want to try this. But in light of the seriousness of the threat I thought an approach like this would be helpful

My strategy is posted below. Will this work? Could it work with tweaks? It would be sad if it corrupted my current setup, which has been working well.

Thanks!
Mark

Putting together posts from other forums and conversations, this is the strategy I was thinking of:

#1 Boot without persistence

# Make working directories
mkdir /media/{rootfs,cow,persist_usb}


#Mount the persistent directory
mount /dev/sd?4 /media/cow


#(I don't know what letter until I try this)

#Mount the supporting systems:

for dir in proc dev sys etc bin sbin var usr lib lib64 tmp; do
mkdir /media/rootfs/$dir && mount --bind /$dir /media/rootfs/$dir
done

# combine the supporting directories and persistent directory

mount -t aufs -o dirs=/media/cow/../upper=rw:/media/rootfs=ro unionfs /media/persist_usb


# change root to the combined directory and update grub
chroot /media/persist_usb

update-grub2 # inside chroot

[sudodus]

@marks2,

I'm glad that your persistent live drive works well

But I am not sure that it will work to upgrade grub in order to make your Intel microcode work. This does not mean that I think it will not work. I simply do not understand how to make it work and check that it really works.

On the other hand, you can use a new version of Ubuntu or Ubuntu community flavour (Kubuntu, Lubuntu, ... Xubuntu), where the Meltdown/Spectre memory threat is mitigated.

See this link: SpectreAndMeltdown

If you make a persistent live system from an 18.04.1 LTS iso file, there should be no problem.

If you want to keep the content of your home (personal files and tweaks), you can use mkusb to backup and restore home to this new persistent live system.

[marks2]

There are tests that will tell you if the microcode has been loaded.

I don't suppose there's a way to just replace the 18.04 partition (the one that is/was an ISO I assume) with 18.04.1 ?? Otherwise, if I run mkusb again, I assume everything (including all the software I've installed) will get wiped. So even though I've made a backup it will be a long time before everything is working OK.

Thanks!
-- Mark

[sudodus]

@marks2,

I thought that you were using an older version.

Also in Ubuntu 18.04 LTS (the original iso file released in April 2018) the Meltdown/Spectre memory threat is mitigated. This work was done during the end of 2017 and the very beginning of 2018.

So if you are happy with the function of your current persistent live system made from 18.04 LTS, you need not worry about the Meltdown/Spectre memory threat.

[marks2]

@sudodus

Maybe I'm trying to fix the wrong problem then. During the boot I get a microcode warning:

TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x22 (or later)

The subsequent lines report that microcode is updated to version 0x17. So it's 11 updates behind. I have no idea how significant that is.

Apparently the Meltdown thing is continuing to evolve.

I'm wondering if there is a way to just replace the iso9660 partition (it's dev/sdb4 on my setup) with the iso from a new live stick?

Thanks!
Mark

[sudodus]

@sudodus

Maybe I'm trying to fix the wrong problem then. During the boot I get a microcode warning:

TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x22 (or later)

The subsequent lines report that microcode is updated to version 0x17. So it's 11 updates behind. I have no idea how significant that is.

Neither do I (know how significant that is).

Apparently the Meltdown thing is continuing to evolve.

The microcode is doing other things too (not only mitigating Meltdown and Spectre), so the upgrades might focus on other tasks ...

I'm wondering if there is a way to just replace the iso9660 partition (it's dev/sdb4 on my setup) with the iso from a new live stick?

If there is space enough (in the partition) you can clone from the iso file to the partition (/dev/sdx4) but after that you cannot expect the persistent live drive to work. The 'system content' of the casper-rw partition will no longer match what it is supposed to overlay.

The 'home content' will be OK, but for example installed program packages will be lost, if you backup 'home', create a new system and restore 'home' to the new system. (What you suggest is equivalent to that action.)

[marks2]

It turns out that 18.04.1 has the same problem. Why did they release .1 without fixing that? So it might require the steps I initially outlined, attempting to write to partition that is usually read-only.

Thanks --
Mark

[sudodus]

@marks2,

Instead of fighting with a persistent live system, you can try to create an installed system in a fast USB 3 pendrive or an SSD connected via USB 3 or eSATA. This way you will get a system, where is it possible (maybe even easy) to install the Intel microcode, that you want. I am running such systems successfully, and I find them stable.

See this link with details to help with the installation: How do I install Ubuntu to a USB key? - install like into an internal drive

[marks2]

Yes, I'll probably try that next. I actually had done that with a Kingston USB3. It lasted maybe 3 days before corrupting. It seems to me that that there are optimizations for running on a flash that are not made with a full install. You don't want all that IO activity that a real drive can handle.

It may not be a fair comparison since the persistent drive I'm currently using supports higher speeds.

The best luck I've had with persistent setups was with puppy linux installed on a no-name USB2 flash drive that I used for years. The puppy approach prevented I/O blocking and over-frequent writes to the drive. Unfortunately, puppy is now only randomly supported.

The situation with Spectre sounds pretty dire. It appears that the new debian/ubuntu ISOs are being shipped with the bad microcode that intel rolled back. This may actually be worse than no microcode at all. The distributors probably assume that users can upgrade as soon as they install. But this isn't true with a live system.

Thanks!
-- Mark