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

Hi jdb2,

I noticed that you are using different flash drive (Cruiser Ultra), but it looks like you know what you are doing (can’t say that about me when it comes to linux).

I’m totally lost about sector0. Could you explain in more detail what to do with it, please? Do you think it could work on Ultra Fit flash drive?

I also noticed difference in partitions. Mine is:

looking at part 0 (offset 1048576, size 31098667008, type 0x0b)

whereas yours is:

looking at part 0 (offset 4128768, size 31620923392, type 0x0c)

Attaching rest of the logs:

mydlo@mint ~ $ sudo smartctl -a -T verypermissive -d scsi /dev/sdb
smartctl 6.2 2013-07-26 r3841 [i686-linux-3.13.0-37-generic] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               SanDisk
Product:              Ultra Fit
Revision:             1.00
User Capacity:        31,104,958,464 bytes [31.1 GB]
Logical block size:   512 bytes
Serial number:        [censored]
Device type:          disk
Local Time is:        Wed Jun  3 23:54:00 2015 CEST
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Disabled or Not Supported

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

Error Counter logging not supported

Device does not support Self Test logging

mydlo@mint ~ $ sudo udevadm info --query=all --name=sdb
P: /devices/pci0000:00/0000:00:1d.7/usb2/2-6/2-6:1.0/host3/target3:0:0/3:0:0:0/block/sdb
N: sdb
S: disk/by-id/usb-SanDisk\_Ultra\_Fit\_[censored]-0:0
S: disk/by-path/pci-0000:00:1d.7-usb-0:6:1.0-scsi-0:0:0:0
E: DEVLINKS=/dev/disk/by-id/usb-SanDisk\_Ultra\_Fit\_[censored]-0:0 /dev/disk/by-path/pci-0000:00:1d.7-usb-0:6:1.0-scsi-0:0:0:0
E: DEVNAME=/dev/sdb
E: DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb2/2-6/2-6:1.0/host3/target3:0:0/3:0:0:0/block/sdb
E: DEVTYPE=disk
E: ID\_BUS=usb
E: ID\_INSTANCE=0:0
E: ID\_MODEL=Ultra\_Fit
E: ID\_MODEL\_ENC=Ultra\x20Fit\x20\x20\x20\x20\x20\x20\x20
E: ID\_MODEL\_ID=5583
E: ID\_PART\_TABLE\_TYPE=dos
E: ID\_PATH=pci-0000:00:1d.7-usb-0:6:1.0-scsi-0:0:0:0
E: ID\_PATH\_TAG=pci-0000\_00\_1d\_7-usb-0\_6\_1\_0-scsi-0\_0\_0\_0
E: ID\_REVISION=1.00
E: ID\_SERIAL=SanDisk\_Ultra\_Fit\_[censored]-0:0
E: ID\_SERIAL\_SHORT=[censored]
E: ID\_TYPE=disk
E: ID\_USB\_DRIVER=usb-storage
E: ID\_USB\_INTERFACES=:080650:
E: ID\_USB\_INTERFACE\_NUM=00
E: ID\_VENDOR=SanDisk
E: ID\_VENDOR\_ENC=SanDisk\x20
E: ID\_VENDOR\_ID=0781
E: MAJOR=8
E: MINOR=16
E: SUBSYSTEM=block
E: UDISKS\_PARTITION\_TABLE=1
E: UDISKS\_PARTITION\_TABLE\_COUNT=1
E: UDISKS\_PARTITION\_TABLE\_SCHEME=mbr
E: UDISKS\_PRESENTATION\_NOPOLICY=0
E: USEC\_INITIALIZED=3636733

mydlo@mint ~ $ sudo /lib/udev/udisks-part-id /dev/sdb
using device\_file=/dev/sdb syspath=/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-6/2-6:1.0/host3/target3:0:0/3:0:0:0/block/sdb, offset=0 ao=0 and number=0 for /dev/sdb
Entering MS-DOS parser (offset=0, size=31104958464)
MSDOS\_MAGIC found
looking at part 0 (offset 1048576, size 31098667008, type 0x0b)
new part entry
looking at part 1 (offset 0, size 0, type 0x00)
new part entry
looking at part 2 (offset 0, size 0, type 0x00)
new part entry
looking at part 3 (offset 0, size 0, type 0x00)
new part entry
Exiting MS-DOS parser
MSDOS partition table detected
UDISKS\_PARTITION\_TABLE=1
UDISKS\_PARTITION\_TABLE\_SCHEME=mbr
UDISKS\_PARTITION\_TABLE\_COUNT=1

I will really appreciate if you could help me with this issue.

Thank you in advance,

mydlo

@mydlo wrote:

Hi jdb2,

 

I noticed that you are using different flash drive (Cruiser Ultra), but it looks like you know what you are doing (can’t say that about me when it comes to linux).

I’m totally lost about sector0. Could you explain in more detail what to do with it, please? Do you think it could work on Ultra Fit flash drive?

I also noticed difference in partitions. Mine is:

looking at part 0 (offset 1048576, size 31098667008, type 0x0b)

whereas yours is:

looking at part 0 (offset 4128768, size 31620923392, type 0x0c)

 

 

The “0x0c”  is due to the fact that I have the LBA flag set. 

 

Could you please run the following commands in a terminal? :

 

cd ~/ sudo dd if=/dev/sdX of=sector0.bin bs=512 count=1 xxd sector0.bin > sector0.hex

Note : Please replace the “X” in “sdX” with the letter that corresponds to your USB flash drive’s block device file.

After the above, you can either attach the .hex file or just post the hex listing in a CODE section.

 

I will really appreciate if you could help me with this issue.

Thank you in advance,

mydlo

 

 


You are welcome :slight_smile:

 

Regards,

 

jdb2

Hello all,

I have experienced this very issue with my Sandisk Ultra Fit 3.0 32GB CZ43 (I have 2 of them), refered to below as SDUF.

I bought them with the intention to use them with Pogoplugs and Debian. But that is also a NO GO.
Please check out this thread for my findings: http://forum.doozan.com/read.php?2,21868

Summary:

  • Bodhi’s Debian cannot fully boot from the SDUF on Pogoplugs.
  • Many live ISOs fail to complete the boot process. But the following distros have no problem using and booting from the SDUF.
        TAILS, Kali, grml, AntiX, PCLinuxOS, Manjaro, Fedora.
  • A temporary work-around, to be able to boot from the SDUF, is to disonnect and reconnect it WHILE the kernel is loading,
    or shortly after (while still looking for the rootfs). The kernel then detects the SDUF properly and the boot process continues successfully.

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

Needless to say, this experience has forced me to look elsewhere (i.e. NOT SanDisk) for flash drives.

TIA

Pepar

1 Like

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?

@pepar wrote:

 

  • A temporary work-around, to be able to boot from the SDUF, is to disconnect and reconnect it WHILE the kernel is loading,
    or shortly after (while still looking for the rootfs). The kernel then detects the SDUF properly and the boot process continues successfully.

Yeah. I forgot to mention that my original Sandisk Cruzer Ultra 32GB USB 3.0 flash drive would boot if I waited for the kernel to drop me to a busybox shell. Then, I would unplug and then re-insert the drive, wait a few seconds until all the kernel messages had finished printing the and the device nodes were properly configured, and then I’d type “exit” and the drive would boot.

But, since I RMA-ed that drive, I no longer have this issue.

Regards,

jdb2

1 Like

@mydlo wrote:

Hi jdb2,

 

I noticed that you are using different flash drive (Cruiser Ultra), but it looks like you know what you are doing (can’t say that about me when it comes to linux).

I’m totally lost about sector0. Could you explain in more detail what to do with it, please? Do you think it could work on Ultra Fit flash drive?

I will really appreciate if you could help me with this issue.

Thank you in advance,

mydlo

 

 

Do you ever get to a bootloader prompt, such as a Syslinux or GRUB menu? Also, if the answer to the previous question is “yes,” then how far into the bootup process does your Linux install get before it fails? Do you see any kernel status messages while it’s booting? If not, then when you get a GRUB or Syslinux prompt, instead of just selecting your OS and pressing enter ( if you have no prompt then press escape to get one before the Kernel tries to boot ) edit the kernel command line such that it does not contain “quiet splash” and instead append “debug ignore_loglevel” and then post any error messages that concern USB storage.

Regards,

jdb2

@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

@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

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

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?