Reply
Newbie
Posts: 1
Registered: ‎05-28-2015

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

[ Edited ]

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

 

SanDisk Guru
Posts: 2,538
Registered: ‎07-23-2010

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

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?

 

 

Ed
Important files = Backed up files
SanDisk User
Posts: 23
Registered: ‎05-10-2015

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


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

SanDisk User
Posts: 23
Registered: ‎05-10-2015

Re: Ok, here we go again


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

Newbie
Posts: 1
Registered: ‎09-09-2015

Also can't boot a live Sandisk Ultra Fit 3.0 32GB

[ Edited ]

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.

SanDisk Guru
Posts: 2,538
Registered: ‎07-23-2010

Re: Also can't boot a live Sandisk Ultra Fit 3.0 32GB

[ Edited ]

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.   Smiley Wink

Ed
Important files = Backed up files
SanDisk User
Posts: 23
Registered: ‎05-10-2015

Re: can't boot [snip]

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] Smiley 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

 

Newbie
Posts: 1
Registered: ‎01-06-2016

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

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.

SanDisk User
Posts: 23
Registered: ‎05-10-2015

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


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 Happy

 

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

 

Newbie
Posts: 5
Registered: ‎07-09-2018

Re: can't boot [snip]

[ Edited ]

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)?