can't boot a Mint Cin 17.1 live Sandisk Ultra Fit 3.0 32GB

What does this mean?

  1. I can boot with the sandisk usb ultrafit 3.0 into linux on other computers.

  2. On the computer I want to boot, this usb fails.

  3. (some) other, non sandisks succeed in booting on this computer.

The message I get is:

(initramfs) Unable to find a medium containg a live file system".

When I have another usb also with a linux live image on it in another slot and try to boot from the sandisk, i get:

(initramfs) FAT-fs (sdc1): unable to read inode block for updating (i_pos 132651)

The computer in question is a chromebook, with a haswell cpu (celeron 2995U)

I tried the taking out and typing exit, i get a lot of script on t he screen with ‘end trace’ at the end of it.

When I have another usb also with a linux live image on it in another slot and try to boot from the sandisk, i get:

(initramfs) FAT-fs (sdc1): unable to read inode block for updating (i_pos 132651)

I suspect the other usb is sdc1 and the one you’re trying to boot is sdc2.  The boot manager is searching drives in sequence.

The computer in question is a chromebook,

I think that answers some of your questions.   :wink:

I’ve tracked down the basic problem many people have been experiencing.

The culprit lies in the Linux Kernel’s udev and USB subsystems. For some reason, the kernel is timing out on trying to read the Sandisk USB device descriptor. This means that the necessary entries never get created in /sys . What happens next is that the capser script bombs in this section :

 else # Scan local devices for the image i=0 while ["$i" -lt 60]; do livefs\_root=$(find\_livefs $i) if ["${livefs\_root}"]; then break fi sleep 1 i="$(($i + 1))" done fi if [-z "${livefs\_root}"]; then panic "Unable to find a medium containing a live file system" fi

But where does livefs_root come from? Well, if we dig deeper, then we find that find_livefs() is indeed failing to find the entries is /sys/block : 

# or do the scan of block devices for sysblock in $(echo /sys/block/\* | tr ' ' '\n' | egrep -v "/(loop|ram|fd|md)"); do devname=$(sys2dev "${sysblock}") [-e "$devname"] || continue fstype=$(get\_fstype "${devname}") if /lib/udev/cdrom\_id ${devname} \> /dev/null; then if check\_dev "null" "${devname}" ; then return 0 fi elif is\_nice\_device "${sysblock}" ; then for dev in $(subdevices "${sysblock}"); do if check\_dev "${dev}" ; then return 0 fi done elif is\_md "${devname}" || is\_mapper "${devname}" ; then if check\_dev "null" "${devname}" ; then return 0 fi elif ["${fstype}" = "squashfs" -o \ "${fstype}" = "ext4" -o \ "${fstype}" = "ext3" -o \ "${fstype}" = "ext2" -o \ "${fstype}" = "btrfs"]; then # This is an ugly hack situation, the block device has # an image directly on it. It's hopefully # casper, so take it and run with it. ln -s "${devname}" "${devname}.${fstype}" echo "${devname}.${fstype}" return 0 fi done return 1 }

find_livefs() in turn calls check_dev(), is_nice_device(), sys2dev() which takes an argument from sysfs and returns the corresponding device node path in /dev, and get_fstype(). Since the kernel udev and USB subsystems timed out on trying to read the Sandisk USB flash drive’s device descriptor, then the entries which should have corresponded to the flash drive never get created in /sys/block and hence the boot fails.

There is one possible solution :

add  

rootwait rootdelay=30 usbcore.autosuspend=120 usbcore.old\_scheme\_first=1 usbcore.initial\_descriptor\_timeout=60 usb-storage.delay\_use=10

to the Linux kernel’s boot command line. Note that I know some of the above parameters are redundant but I just wanted to be extra safe[TM] :stuck_out_tongue: . Also, the timeout values ( in seconds ) are very conservative.

If the above doesn’t work, then you can also try adding :

usb-storage.quirks=VID : PID : Flags

( remove the spaces between the colons above – for some reason the forum software is creating smileys even though the text is in a code block )

to the Linux kernel command line, where VID is your Sandisk USB flash drive’s Vendor ID as returned by “sudo lsusb -v” and the PID is the Product ID returned by the same command. For Flags, there are at least 19 ( documented here ), so you may have to try several combinations ( multiple flags can be used simultaneously ).

I hope this helps.

Regards,

jdb2

I apologize if this message is a duplicate, but this is possibly the 4th or 5th time I’ve tried posting this message after which it has “disappeared” from the Sandisk forums. I’ve snipped the title – perhaps it has something to do with too many characters.


Note, for some reason this message went missing or got deleted. It was originally posted on June 23th.


@ed_p wrote:

So the real question is, what procedure do theses live distros use to successfully detect the SDUF?

 

Sounds like the question is why do you not use a modern boot manager that supports all your ISOs, your SDUF drive and all other flash drives like Easy2BootRMPrepUSB or Grub4dos?

 

 

Thanks for the advice :smiley: . UNetbootin is suppose to support Debian/Ubuntu based ISOs, but for some reason the bootup process failed on my Cruzer Ultra before I RMA-ed the drive.

Right now I’m running my Linux live USB system off of my RMA-ed Cruzer Ultra which is plugged into a 2-port USB 3.0 ExpressCard which itself is plugged into the laptop on which I am typing this message. Since the BIOS doesn’t see the Cruzer Ultra when it’s plugged into a USB 3.0 port ( the laptop and its BIOS are quite old – the BIOS has been updated to the last version released though ) I’ve been using PlopKexec to chain-load my Linux Mint Cinnamon 64-bit install on the Cruzer Ultra. I boot into PlopKexec and then I select “Start Linux Mint.” It’s been working perfectly for a while now.

Regards,

jdb2


EDIT : B.T.W., I think that the boot manager is really not the culprit in this case ( or more specifically, the casper init scripts ) but instead the Linux kernel itself. As I explained in a previous message the kernel is timing out on trying to read the Sandisk flash drive’s USB device descriptor.

Many thanks to pepar and jdb2! My SanDisk Ultra Fit USB 3.0 now boots Knoppix 7.6.0 rather quickly (even on USB 2.0 port). The unplug / re-insert should not be necessary, I wish SanDisk would get with it on USB 3.0.

@dave194 wrote:

Many thanks to pepar and jdb2! My SanDisk Ultra Fit USB 3.0 now boots Knoppix 7.6.0 rather quickly (even on USB 2.0 port). The unplug / re-insert should not be necessary, I wish SanDisk would get with it on USB 3.0.

Thank you :smiley:

I’ve been able to get my Sandisk USB 3.0 flash drives to boot from my laptop’s USB 3.0 ports using PlopKexec . The only problem with PlopKexec is that I’ve had trouble when booting from it when other USB devices are plugged in which has led to it kernel panicking. Also, sometimes I get dropped to an initramfs busybox shell and I have to remove and reinsert the flash drive and then type “exit [ENTER]” to get my Linux install to boot from the flash drive.

Lately I’ve been using “kiyoshi’s help” which is another kexec based chain-boot loader, but it’s more sophisticated than PlopKexec and it boots my USB 3.0 flash drive from my laptop’s USB 3.0 ports perfectly, without any kernel panics, busybox initramfs shells or the need to pull out and reinsert the flash drive. I’ve built a custom ISO image from a custom Debian 7 install in VMware which I then burnt to a CD-R. If you don’t want to build “kyoshi’s help” yourself then here’s a link to my zipped ISO image :

https://www.dropbox.com/s/yfq8i8h16y3pq0e/kiyoshishelp.zip?dl=0

I hope this helps,

Regards,

jdb2

I’ve dealt with this issue for a while with my own SanDisk Fit 32 GB USB 3.0 thumb drive, and had come across the remove and re-insert trick somewhere, but I’d never found a permanent fix. I just read jdb2’s suggestion above from 2015, and his follow-up from 2016, but none of what he suggests seems to fix the problem for me. I tried adding those various parameters to the grub default boot line, making sure to update grub and everything, but none of them on that rootwait … line, nor any of the “quirks” parameters that I could discern seemed to work. Maybe I didn’t use the right quirks parameters? What did other people actually use? Also, it’s not clear how that “kiyoshi’s help” boot loader would help in this instance. Is there not just a straightforward config that is known to work with these faulty drives and, say, a standard Linux Mint Cinnamon install (with no special bootloader config required)?

Post your grub2 menu so we can see what you’re working with.

Some boot problems are equipment related; low power, heat, low RAM, conflicting USB devices, maxed out USB hub, oxidized electrical contacts.

Ed_P, I don’t know how much of this thread you’ve read (I genuinely don’t), but it’s quite certain if you read through it that the problem here is a bug within the firmware of some of these Ultra Fit 32GB drives, not anything in any particular with the OS or bootloader configuration.

To be sure, I’m able to boot this *exact same* image, a fresh install of Linux Mint, from practically any other thumb drive, using the standard, out of the box, default grub configuration, except for with this Ultra Fit 32GB drive.

The reason I posted was that I got the impression that some people had found a *specific* workaround for the buggy behavior with these Ultra Fit 32GB drives. That’s all I’m looking for. I’m not using any non-default grub configuration, it’s exactly as-is from a fresh Linux Mint install. I’d love to *know* some non-default grub configuration that would workaround the issue, though. :slight_smile:

I responded to your recent posting mmortal03, the other postings are 2 - 3 yrs old.  Drives manufactured today are not the same as they were 3 yrs ago.

Thanks for replying. This one is actually one of the older drives from a few years ago, not one I’ve recently purchased. I’ve been dealing with the issue for a few years now. Btw, a new finding, it *will* boot up without issue on a Samsung Series 7 Chronos laptop, but not on two or more other laptop models that I’ve tried it on. I don’t know what the common denominator is. Could be slower processor machines, or it might be some weird incompatibility with various USB hardware? How might the in-depth explanation that jdb2 gave apply to some machines and not others?

Different machines = different hardware = different drivers and different states of oxidation, dust, rust, power supply voltage and obsolesence.

No doubt those things might affect certain situations, but here is how I can rule that sort of stuff out. If I make an image of the Ultra Fit, write that image to another thumb drive, and insert that other drive into the *same* laptops, the problem isn’t there. And the Ultra Fit has been doing it from the beginning, so it’s not as if the Ultra Fit has oxidized or rusted or what have you and is only now showing the problem – it always has.

Ok, that eliminates some possibilities.  Are the SanDisk and “other” drive the same USB capabilities,  USB 2 vs USB 3?  Are they both formated the same way, with the same block alignments?  The same size?

Ok, that eliminates some possibilities. 

If the SanDisk drive works fine other than booting the problem is MBR related.  Are the SanDisk drive and the “another drive” both formated the same way, with the same block alignments and MBR locations?

Yes, I do believe so. The exact same dd raw image that I’m writing to them should very well contain the same boot record and the same formatting, block alignments, and everything, unless I’m missing something. I really think the problem is something lower level than this, like in the firmware of the SanDisk Ultra Fit 32GB or what have you. I really just thought someone here had a workaround. I doubt we’ll be able to discover the cause without lower level tools and detailed knowledge of the firmware.

@mmortal03 wrote:

“I’ve dealt with this issue for a while with my own SanDisk Fit 32 GB USB 3.0 thumb drive, and had come across the remove and re-insert trick somewhere, but I’d never found a permanent fix. I just read jdb2’s suggestion above from 2015, and his follow-up from 2016, but none of what he suggests seems to fix the problem for me. I tried adding those various parameters to the grub default boot line, making sure to update grub and everything, but none of them on that rootwait … line, nor any of the “quirks” parameters that I could discern seemed to work. Maybe I didn’t use the right quirks parameters? What did other people actually use?”

 

Well, I’m sorry that my suggested solution didn’t work for you :(. I didn’t work for me either which is why I started using a chain bootloader.

 

“Also, it’s not clear how that “kiyoshi’s help” boot loader would help in this instance. Is there not just a straightforward config that is known to work with these faulty drives and, say, a standard Linux Mint Cinnamon install (with no special bootloader config required)?”

 

Well, “kyoshi’s help” just searches your system for boot loaders and then presents you with a menu which lists the various boot loaders that the “kyoshi’s help” can chain load. I my case, my boot-loader was GRUB on ext4. It’s a big kludge though and it’s inconvenient because I had to burn “kiyoshi’s help” to a DVD and then I’d boot off of the DVD and then I’d select the boot-loader for my LInux Mint install, which was in an USB slot, and then my install would be chain-booted successfully

I hope this helps,

jdb2

“The exact same dd raw image that I’m writing to them should very well contain the same boot record and the same formatting, block alignments, and everything,”

I’m not sure that is true, especially the block alignments on different drives.

Rather than copying images to the drive, install a system to it.  Get the ISO of the system you want and use something like RMPrepUSB or Easy2Boot to install it to the USB drive then see if it boots.

"Well, “kyoshi’s help” just searches your system for boot loaders and then presents you with a menu which lists the various boot loaders that the “kyoshi’s help” can chain load. I my case, my boot-loader was GRUB on ext4. It’s a big kludge though and it’s inconvenient because I had to burn “kiyoshi’s help” to a DVD and then I’d boot off of the DVD and then I’d select the boot-loader for my LInux Mint install, which was in an USB slot, and then my install would be chain-booted successfully

I hope this helps,

jdb2"

Jdb2, thanks for getting back with me. Now it makes more sense. Coincidentally, I’ve done something like that before when I was in a pinch in a slightly different situation. Anyway, given that that was the only other potential solution mentioned here outside of the remove and re-insert trick, I think I’ll give up on this now and just use another drive. It looks like there’s no direct solution, just workarounds like these.

Ed_P, I’ve done a direct install to it in the past and that didn’t solve the problem, either. I really think it was just a flaw in a particular run of these drives from a few years back. I actually spent many hours on it back then thinking I was doing something wrong in the way I was installing Linux to it, and it turns out that it was just a flaw in the thumb drive itself. :frowning: It’s all good, though. Thanks for helping to troubleshoot it.

You’re welcome mmortal03.   But, it doesn’t cost anything, or take long, to try it with new software like Easy2Boot or RMPrepUSB.  :wink: