1

System Specs:

  • Processor: Intel Core i7-4790 @ 3.60 GHz

  • RAM: 32.0 GB

  • System type: x64-based processor

  • OS: Windows 10 Pro

  • USB Stick: Kingston 16 GB

Bug Description

I've followed the steps outlined in the following official Ubuntu tutorial link to a T: https://ubuntu.com/tutorials/create-a-usb-stick-on-windows#1-overview

Everything went smoothly, no errors during installation, yay! When I booted from the new USB, GNU GRUB appeared, again, so far so good.

However, when I selected Ubuntu, I immediately got an error that casper/vmlinuz is not found. I checked the USB drive (created with Rufus following the tutorial's instructions) and sure enough, vmlinuz was missing.

USB /casper directory:

Picture of USB /casper directory

I mounted the iso file used to generate the USB and sure enough, vmlinuz is there, along with a couple other files not seen on the USB drive, initrd and filesystem.squashfs.gpg.

ISO /casper directory:

Picture of ISO /casper directory

Repro Steps from a Windows PC

  1. Download a fresh iso image of Ubuntu (https://ubuntu.com/download/desktop)
  2. Download Rufus if not already installed (https://rufus.ie/)
  3. Follow all of the instructions on creating a bootable USB stick on Windows (https://ubuntu.com/tutorials/create-a-usb-stick-on-windows)
  4. Restart machine and open up BIOS to ensure boot order allows USB stick to boot before Windows
  5. Boot from USB stick created in Step 3.
  6. Observe the following error:
error: file `/casper/vmlinuz' not found.
error: you need to load the kernel first.

Press any key to continue...

Expected Results:

Ubuntu loads up correctly with no missing critical files that Ubuntu's startup depends on.

Actual Results:

The following error is seen:

Picture of Bootable USB OS Error

Suggested Fix:

Either fix the process or at the very least, we should include something in the tutorial page itself that the user may need to manually copy over specific installation files from a mounted ISO file onto the USB stick after writing the ISO to the USB stick using Rufus.

karel
  • 114,770
user2188400
  • 19
  • 1
  • 1
    What OS & release are you trying to write the to media? Testing releases can have issues, and are off-topic on this site (that error has existed for groovy daily ISOs, but they're off-topic here and problems belong on a bug-tracking site, not here). If you're on a supported release, bad writes to media (esp. thumb-drive media) do occur (i get at least one a week and hate them) which doesn't mean tutorial is faulty. – guiverc Sep 09 '20 at 05:51
  • 1
    Hey there, I'm trying to write the latest LTS version of Ubuntu on Windows 10 Pro. I'm not using a testing release, this is 20.04.1 LTS – user2188400 Sep 09 '20 at 05:53
  • To be clear, I'm not trying to replace Windows, I'm trying to create a bootable USB drive that I can use as a live installation of Ubuntu – user2188400 Sep 09 '20 at 05:55
  • This kind of info that it might just fail for no reason should absolutely be part of the tutorial then, users should be told that up front because this behavior is unexpected. – user2188400 Sep 09 '20 at 05:58
  • So if the tutorial is not faulty, there needs to be a user expectation set that it might just fail for no reason. – user2188400 Sep 09 '20 at 05:58
  • 1
    Just because you experience a bug once a week doesn't mean it's not a bug worth fixing. Why should it be happening to you at least once a week? – user2188400 Sep 09 '20 at 05:59
  • 2
    Flash media is not 100% reliable, adding validation & checking technology like HDD & SSDs have would increased the price of thumb-drive media many times what it's worth now. The issue is cheap & mass-produced media that isn't usually verified (given the low cost, few people return faulty products under warranty making it not worth if the the makers/suppliers to improve their QA). It's hardware issues, and not the result of software. Ubuntu has always had check disc for defects and validation checks (https://help.ubuntu.com/community/Installation/CDIntegrityCheck) to check for that – guiverc Sep 09 '20 at 06:17
  • 2
    I suggest that you try Rufus in 'dd-mode', which means cloning. That way the content of the iso file is copied directly to the USB pendrive (each byte is written as raw data). This method is more reliable than the extraction method, that is the standard method of Rufus (and cloning is likely to work better for you). You can see the missing file in the iso file, and it should also be there in the cloned system in the USB pendrive. Good luck :-) – sudodus Sep 09 '20 at 08:02
  • 1
    See this link: help.ubuntu.com/community/Installation/iso2usb and help.ubuntu.com/community/Installation/FromUSBStick, if you want more details about methods and tools to create live USB drives with Ubuntu. – sudodus Sep 09 '20 at 08:53
  • 3
    Have you checked the MD5/SHA1 checksum to confirm the ISO is not corrupt? There are quite a few reasons a bootable USB may not be working. https://askubuntu.com/questions/1190764/why-doesnt-a-bootable-usb-boot – C.S.Cameron Sep 09 '20 at 08:59

1 Answers1

5

Rufus author here. I am testing Ubuntu bootable media creation regularly (last test was 2 days ago) and I have never encountered this error, nor have I had reports of anything similar happening to the many people that use Rufus to create Ubuntu bootable media.

Can I please ask you to create an issue at the official Rufus issue tracker here and post the complete Rufus log of how you created your media?

If the vmlinuz file failed to copy, it should be apparent there.

And once again, I have to point out that, if you are encountering issues with Rufus, you should use its official issue tracker if you do care about having said issue investigated and possibly fixed. Posting on superuser or askubuntu is not an effective way get problems that are related to the use of a third party application sorted. Thank you.

Akeo
  • 1,455
  • +1; By the way, have you noticed that the boot system of the next Ubuntu version, Groovy Gorilla, is modified? – sudodus Sep 09 '20 at 18:34
  • 1
    Thanks for the info. I haven't had a chance to test Groovy yet, but I'm planning to do that shortly. As long as Ubuntu cares about ensuring that people can create UEFI bootable media, by simply extracting the content onto a FAT32 partition (which is a method that maintainers should always validate thoroughly, as it's the simplest cross-platform way of creating UEFI media) I don't expect breaking changes. But of course, I've seen occurrences of distros relying a bit too much on the "hybrid" part of ISOHybrid and breaking the ISO/FAT32 part as a result, so I'll definitely double check this. – Akeo Sep 09 '20 at 19:56
  • @Akeo: I have been tested the latest groovy-desktop-amd64.iso with Rufus. There is no persistence slider, writing in ISO Image mode gives a black screen with flashing white cursor but the dd Image mode install works okay. – C.S.Cameron Sep 10 '20 at 10:29
  • @C.S.Cameron, that's because I introduced a bug in Rufus 3.11 where, in some cases, the GRUB version from the ISO can't be read properly, so for ISOs that have only GRUB and no Syslinux/Isolinux, the trigger that adds persistence to the UI does not happen. But if you test with Rufus 3.10 you'll see that the persistence option is there. And it so happens that Ubuntu dropped Syslinux support from their latest ISOs (i.e. they are dropping conventional BIOS support altogether... which seems a bit premature to me), so this bug suddenly became relevant. Of course I'll get this fixed for 3.12. – Akeo Sep 10 '20 at 10:59
  • More worryingly however is that Ubuntu now seem to have completely drunk the ISOHybrid kool-aid by moving their EFI boot files to boot/grub/efi.img (this completely BREAKS the ability to create EFI bootable images by copying the ISO files to a FAT32 partition -- well done guys!) and even worse, they've switched BIOS boot to an ISOHybrid GRUB BIOS bootloader, which is going to be a massive pain in the ass to handle if I want to continue to provide BIOS boot support for ISO mode in Rufus. It's very disheartening to see what Ubuntu is doing, because they're really not helping their users... – Akeo Sep 10 '20 at 11:07
  • I am still trying to understand why they changed casper-rw to writable? – C.S.Cameron Sep 10 '20 at 11:35
  • Yeah, that made no sense to me either, and I really don't like the direction the Ubuntu maintainers are going at the moment, because they seem to be a lot more focused on easing up their maintenance work than they are on ensuring that they provide the best user-experience. By the way, I have now logged a bug for moving the EFI boot files to efi.img: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1895131 – Akeo Sep 10 '20 at 11:42
  • 2
    Sometimes I wonder if Tim Cook is involved in Ubuntu decision making. I will "affects me too" your bug report. – C.S.Cameron Sep 10 '20 at 11:58