Booting Debian with "Fixed" type flash drive

Hello all,


1st off, thank you Bodhi, for this great resource and all your efforts.

Has anyone had problems booting from flash type USB-HDD devices (Windows To Go certified????), i.e. Sandisk Ultra Fit CZ43 32GB USB 3.0?

I have tried many USB flash devices, but only have problems with the above.
It seems initrd cannot find it. Same result in Pogo V4 and Pogo E02.

Any tips or ideas? Any help much appreciated.


TIA
pepar



Edited 2 time(s). Last edit at 05/15/2015 11:41AM by pepar.

pepar,

Sandisk Ultra USB 3.0 should work for booting. Make sure:

- You format it completely. If needed, run Sandisl tool to remove the hidden software (it was there in previous versions of the Sandisk UBS drives).
- Do not use a hub. If must use a hub, it should be USB 3.0 hub.
- On Pog V4, it must be plugged into the top USB 2.0 port.

Let me know if you still have problem. I could try it with my spare Sandisk Ultra USB 3.0.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

pepar Wrote:
-------------------------------------------------------
> Has anyone had problems booting from flash type
> USB-HDD devices (Windows To Go certified????),
> i.e. Sandisk Ultra Fit CZ43 32GB USB 3.0?
>
> I have tried many USB flash devices, but only have
> problems with the above.
> It seems initrd cannot find it. Same result in
> Pogo V4 and Pogo E02.
>
> Any tips or ideas? Any help much appreciated.
>
>
> TIA
> pepar

First, I do not believe the Sandisk Ultra Fit is Windows To Go Certified. Second, I have a Sandisk Ultra Fit and it works just fine.

-grayman4hire
======================================
Pogoplug V2 and V3 Serial Connection
Tutorial - Pogoplug v4 (Series 4 and Mobile) with Linux (Debian or Arch)
OpenWRT on Pogoplug Mobile
Tutorial - Pogoplug E02/V4 with Arch Linux ARM
Hacking the Pogoplug v3/Oxnas (Pro/Classic) with Debian
OpenWRT on Pogoplug v3/Oxnas (Pro/Classic)

pepar Wrote:
-------------------------------------------------------

> Has anyone had problems booting from flash type
> USB-HDD devices (Windows To Go certified????),
> i.e. Sandisk Ultra Fit CZ43 32GB USB 3.0?
>
> Any tips or ideas? Any help much appreciated.
> pepar

I have found sometimes I needed to use this program: SD Card Formatter on both SD cards and flash drives to "clear" them out in order to facilitate Linux ext3 or ext4 formatting. I know it doesn't make sense, formatting a card with Windows to make it work as a Linux formatted drive but like I said, it has worked for me.

Also, I have run the Sandisk UF 16Gb on both a PP Pro and an PP E02 and have not experienced any issues.

I've moved this topic to this new thread..

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 05/13/2015 03:33AM by bodhi.

@pepar

i have used many different types of usb hdd / flash sticks and use the one you mention in your original post.

On these devices and as long as you follow the points made above you should have no issues.

1) Always boot the usb flash drive or adapted hardware from the USB 2. * socket

2) Wipe any and all partitions that exist from the manufacturer and create your own

3) if booting from a hub ensure it can deliver the necessary power requirement, as bodhi pointed out above. a USB 3 hub is the best option, in that it delivers more than 500ma per port.

Thank you guys for the help.


However, none of the suggestions so far have helped.

- wiped, formated & re-formated (even using dd) check
- not using hubs check
- on Pogo V4, using top USB 2.0 port check
- use SD Card Formatter (had already tried Rufus, RMPrepUSB,..) check

As stated in OP, my problems are with the SanDisk Ultra Fit CZ43 32GB USB 3.0, referred to as SDUF from hereon. Also, verified on 2 different device types (Pogo V4 and Pogo E02) with 2 different flash drives.

The real issue concerns "Fixed" vs "Removable" type flash drives, stemming from Microsoft's Windows 8/To Go "feature", as acknoledged by Sandisk:
http://forums.sandisk.com/t5/All-SanDisk-USB-Flash-Drives/32-GB-Cruzer-Glide-useless-because-it-shows-as-fixed/m-p/297749#M5437
http://forums.sandisk.com/t5/All-SanDisk-USB-Flash-Drives/USB-Flash-Drive-showing-up-as-LOCAL-DISK/m-p/316915#M8258

Has anyone else encountered this issue, with SDUF or other flash drive?
Found a solution?



If you have read this far and your curiosity is piqued:
TLDR version, in the interest of saving time, effort, and for documenting purposes.

A few months back, I bought 2 of these, at the same time (presumably from the same batch).
I have subsequently done a fair amount of research. I use USB keys to boot live ISOs to do IT support, and regularly use Easy2Boot (and others). To that end, I follow and read threads in www.reboot.pro forums.

Most live ISOs fail to complete the boot process (as bodhi's Debian jessie rootfs does), because they look for the rest of the system on "traditional" media. But the following distros have no problem using and booting from the SDUF. Notice that most of them are Debian based.
TAILS, Kali, grml, AntiX, PCLinuxOS Note: even Puppy & variants do not boot (normally quite versatile and resilient)

For a deeper understanding of the problem, more reading: www.google.com/search?q=usb+fixed+vs+removable

I believe the only correct solution is to change the initramfs detection script(s), because it seems impossible to alter the drive's "configuration".

One final note: I have been using the Pogos for a few months now, and Linux for many more years than I have fingers. I am unlikely to be the only one experiencing this issue, just probably more tenacious. It is definitely easier to just use other flash drives (as I have), but given some pointers, I am sure it can be resolved (and help make it "Just Works").


TIA
pepar


PS: I have noticed that on some hubs/ports, sometimes the SDUF does not get detected. Yet if I insert it slowly, it does get detected. It may or may not be relevant because so many variables are involved (hardware manufacturers, drivers, kernels,...).



Edited 3 time(s). Last edit at 05/15/2015 01:15PM by pepar.

pepar Wrote:
-------------------------------------------------------

> It is definately easier to just use other flash
> drives (as I have), but given some pointers, I am

If you have a series of drives you have had good luck with I am sure it would be beneficial to forum members for you to recommend one. There were several threads years ago on this forum (and over at Arch) where people shared their experience using various drives. It's been a while since (at least a couple years) so maybe you can help others out by letting us know what drives you have had good experience with. I for one would like to know because like I said, there isn't much recent info to go by and I bought the Ultra Fit because it appeared well rated on Amazon AND it was really cheap on sale. Maybe I just got lucky or have yet to experience your circumstance. Regardless, I hope you can share the drives that have worked for you.

Edit: When you share your preferred drives, if you could post some hdparm numbers that would be helpful as a simple point of comparison.



Edited 2 time(s). Last edit at 05/15/2015 12:18PM by LeggoMyEggo.

I'm really surprise your ultra fit is a fixed disk drive (aka windows to go certified). I have the cruzer you linked about and use it for windows to go but definitely would prefer the compactness of the ultra fit.

My personal opinion, use it for windows to go assuming it's on the larger side and get yourself a new drive.

If you insist, there are tools and such out there to flip the fixed disk bit. I bricked one of my drives trying though.

If you want to continue troubleshooting a serial/net console log might be helpful.

-grayman4hire
======================================
Pogoplug V2 and V3 Serial Connection
Tutorial - Pogoplug v4 (Series 4 and Mobile) with Linux (Debian or Arch)
OpenWRT on Pogoplug Mobile
Tutorial - Pogoplug E02/V4 with Arch Linux ARM
Hacking the Pogoplug v3/Oxnas (Pro/Classic) with Debian
OpenWRT on Pogoplug v3/Oxnas (Pro/Classic)

pepar,


> If you have read this far and your curiosity is
> piqued

:) definitely. I'll test my 64GB Ultra Fit (I don't have the 32GB).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@pepar,

I've confirmed that the Ultra Fit 64GB booted without problem on the top USB 2.0 port of the Pogo V4.

I think we should go back to the basic troubleshooting:

- Is the Ultra Fit the only drive plugged in? if not then remove all other drives.
- When you say it seems "initrd could not find it", did you see that in serial console?
- Did you use roots label for booting? what is your u-boot envs look like?
- If you have serial console, pls post the serial bootlog.

FWIW, I do not think the problem that you have described (fixed flash drive) would apply here. IMO, it does not matter to the Linux boot process what drive it is identified as.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 05/15/2015 07:56PM by bodhi.

Follow up.


I have already tried the tools out there to flip the fixed disk bit, unfortunately that did not work (for me). SanDisk also had already said (in one of the forum posts above) that was not possible.

- Is the Ultra Fit the only drive plugged in? if not then remove all other drives check

- When you say it seems "initrd could not find it", did you see that in serial console?
Just typing too fast. Really meant initramfs (close).

- Did you use roots label for booting? what is your u-boot envs look like?

u-boot>> printenv
arcNumber=2097
baudrate=115200
bootcmd=usb start; run force_rescue_bootcmd; run ubifs_bootcmd; run usb_bootcmd; usb stop; run rescue_bootcmd; run pogo_bootcmd; reset
bootdelay=3
console=ttyS0,115200
ethact=egiga0
ethaddr=00:25:31:04:AE:C5
force_rescue=0
force_rescue_bootcmd=if test $force_rescue -eq 1 || ext2load usb 0:1 0x1700000 /rescueme 1 || fatload usb 0:1 0x1700000 /rescueme.txt 1; then run rescue_bootcmd; fi
if_netconsole=ping $serverip
ipaddr=192.168.1.10
led_error=orange blinking
led_exit=green off
led_init=green blinking
mainlineLinux=yes
mtdids=nand0=orion_nand
mtdparts=mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)
partition=nand0,2
pogo_bootcmd=if fsload uboot-original-mtd0.kwb; then go 0x800200; fi
preboot=run if_netconsole start_netconsole
rescue_bootcmd=if test $rescue_installed -eq 1; then run rescue_set_bootargs; nand read.e 0x800000 0x100000 0x400000; bootm 0x800000; else run pogo_bootcmd; fi
rescue_installed=0
rescue_set_bootargs=setenv bootargs console=$console ubi.mtd=2 root=ubi0:rootfs ro rootfstype=ubifs $mtdparts $rescue_custom_params
serverip=192.168.1.100
start_netconsole=setenv ncip $serverip; setenv bootdelay 10; setenv stdin nc; setenv stdout nc; setenv stderr nc; version;
stderr=serial
stdin=serial
stdout=serial
ubifs_bootcmd=run ubifs_set_bootargs; if ubi part data && ubifsmount rootfs && ubifsload 0x800000 /boot/uImage && ubifsload 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000; fi
ubifs_mtd=3
ubifs_set_bootargs=setenv bootargs console=$console ubi.mtd=$ubifs_mtd root=ubi0:rootfs rootfstype=ubifs $mtdparts $ubifs_custom_params
usb_boot=mw 0x800000 0 1; ext2load usb $usb_device 0x800000 /boot/uImage; if ext2load usb $usb_device 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000; else bootm 0x800000; fi
usb_bootcmd=run usb_init; run usb_set_bootargs; run usb_boot
usb_device=0:1
usb_init=run usb_scan
usb_root=/dev/sda1
usb_rootdelay=10
usb_rootfstype=ext2
usb_scan=usb_scan_done=0;for scan in $usb_scan_list; do run usb_scan_$scan; if test $usb_scan_done -eq 0 && ext2load usb $usb 0x800000 /boot/uImage 1; then usb_scan_done=1; echo "Found bootable drive oe
usb_scan_1=usb=0:1 dev=sda1
usb_scan_2=usb=1:1 dev=sdb1
usb_scan_3=usb=2:1 dev=sdc1
usb_scan_4=usb=3:1 dev=sdd1
usb_scan_list=1 2 3 4
usb_set_bootargs=setenv bootargs console=$console root=$usb_root rootdelay=$usb_rootdelay rootfstype=$usb_rootfstype $mtdparts $usb_custom_params

Environment size: 2590/131068 bytes
u-boot>>

- If you have serial console, pls post the serial bootlog.

U-Boot 2011.12 (Feb 20 2012 - 21:21:59)
Pogoplug E02

SoC:   Kirkwood 88F6281_A0
DRAM:  256 MiB
WARNING: Caches not enabled
NAND:  128 MiB
In:    serial
Out:   serial
Err:   serial
Net:   egiga0
88E1116 Initialized on egiga0
Using egiga0 device
host 192.168.1.100 is alive
Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.18.5-kirkwood-tld-1 (root@tldDebian) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 PREEMPT Thu Feb 5 17:58:07 PST 2015
[    0.000000] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=0005397f
[    0.000000] CPU: VIVT data cache, VIVT instruction cache
[    0.000000] Machine model: CloudEngines Pogoplug E02
[    0.000000] Memory policy: Data cache writeback
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
[    0.000000] Kernel command line: console=ttyS0,115200 root=/dev/sda1 rootdelay=10 rootfstype=ext2 mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)
[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Memory: 244888K/262144K available (5640K kernel code, 365K rwdata, 1920K rodata, 268K init, 305K bss, 17256K reserved)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xffe00000   (2048 kB)
[    0.000000]     vmalloc : 0xd0800000 - 0xff000000   ( 744 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
[    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
[    0.000000]       .text : 0xc0008000 - 0xc076a240   (7561 kB)
[    0.000000]       .init : 0xc076b000 - 0xc07ae000   ( 268 kB)
[    0.000000]       .data : 0xc07ae000 - 0xc08096fc   ( 366 kB)
[    0.000000]        .bss : 0xc08096fc - 0xc0855d84   ( 306 kB)
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000016] sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 21474836475ns
[    0.000411] Console: colour dummy device 80x30
[    0.000440] Calibrating delay loop... 1191.11 BogoMIPS (lpj=5955584)
[    0.090122] pid_max: default: 32768 minimum: 301
[    0.090264] Security Framework initialized
[    0.090365] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.090385] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.091122] Initializing cgroup subsys devices
[    0.091155] Initializing cgroup subsys freezer
[    0.091188] Initializing cgroup subsys net_cls
[    0.091212] Initializing cgroup subsys blkio
[    0.091315] CPU: Testing write buffer coherency: ok
[    0.091768] Setting up static identity map for 0x557418 - 0x557470
[    0.092065] mvebu-soc-id: MVEBU SoC ID=0x6281, Rev=0x2
[    0.094540] devtmpfs: initialized
[    0.097177] prandom: seed boundary self test passed
[    0.101278] prandom: 100 self tests passed
[    0.101307] pinctrl core: initialized pinctrl subsystem
[    0.101811] regulator-dummy: no parameters
[    0.105869] NET: Registered protocol family 16
[    0.106332] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.130118] cpuidle: using governor ladder
[    0.160116] cpuidle: using governor menu
[    0.160539] Feroceon L2: Enabling L2
[    0.160586] Feroceon L2: Cache support initialised.
[    0.160966] [Firmware Info]: /ocp@f1000000/ethernet-controller@72000/ethernet0-port@0: local-mac-address is not set
[    0.165150] No ATAGs?
[    0.201816] vgaarb: loaded
[    0.202203] usbcore: registered new interface driver usbfs
[    0.202285] usbcore: registered new interface driver hub
[    0.202350] usbcore: registered new device driver usb
[    0.203431] Switched to clocksource orion_clocksource
[    0.241873] NET: Registered protocol family 2
[    0.242639] TCP established hash table entries: 2048 (order: 1, 8192 bytes)
[    0.242676] TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
[    0.242707] TCP: Hash tables configured (established 2048 bind 2048)
[    0.242777] TCP: reno registered
[    0.242791] UDP hash table entries: 256 (order: 0, 4096 bytes)
[    0.242813] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[    0.243015] NET: Registered protocol family 1
[    0.243392] RPC: Registered named UNIX socket transport module.
[    0.243405] RPC: Registered udp transport module.
[    0.243412] RPC: Registered tcp transport module.
[    0.243419] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.243745] Unpacking initramfs...
[    0.799392] Freeing initrd memory: 6384K (c1100000 - c173c000)
[    0.799529] NetWinder Floating Point Emulator V0.97 (double precision)
[    0.800889] futex hash table entries: 256 (order: -1, 3072 bytes)
[    0.800923] Initialise system trusted keyring
[    0.801038] audit: initializing netlink subsys (disabled)
[    0.801094] audit: type=2000 audit(0.790:1): initialized
[    0.801907] zpool: loaded
[    0.801925] zbud: loaded
[    0.802238] VFS: Disk quotas dquot_6.5.2
[    0.802298] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    0.802909] NFS: Registering the id_resolver key type
[    0.802955] Key type id_resolver registered
[    0.802964] Key type id_legacy registered
[    0.802991] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    0.803007] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[    0.803227] jffs2: version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
[    0.803624] msgmni has been set to 490
[    0.803788] Key type big_key registered
[    0.806729] alg: No test for stdrng (krng)
[    0.806774] Key type asymmetric registered
[    0.806791] Asymmetric key parser 'x509' registered
[    0.806883] bounce: pool size: 64 pages
[    0.806976] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
[    0.806999] io scheduler noop registered
[    0.807015] io scheduler deadline registered
[    0.807073] io scheduler cfq registered (default)
[    0.808405] kirkwood-pinctrl f1010000.pin-controller: registered pinctrl driver
[    0.809049] irq: Cannot allocate irq_descs @ IRQ32, assuming pre-allocated
[    0.809456] irq: Cannot allocate irq_descs @ IRQ64, assuming pre-allocated
[    0.809979] mv_xor f1060800.xor: Marvell shared XOR driver
[    0.843509] mv_xor f1060800.xor: Marvell XOR: ( xor cpy )
[    0.883499] mv_xor f1060800.xor: Marvell XOR: ( xor cpy )
[    0.883683] mv_xor f1060900.xor: Marvell shared XOR driver
[    0.923497] mv_xor f1060900.xor: Marvell XOR: ( xor cpy )
[    0.963497] mv_xor f1060900.xor: Marvell XOR: ( xor cpy )
[    0.963940] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[    0.965278] console [ttyS0] disabled
[    0.965342] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 26, base_baud = 12500000) is a 16550A
[    1.567646] console [ttyS0] enabled
[    1.572820] nand: Could not find valid ONFI parameter page; aborting
[    1.579268] nand: device found, Manufacturer ID: 0xad, Chip ID: 0xf1
[    1.585666] nand: Hynix NAND 128MiB 3,3V 8-bit
[    1.590132] nand: 128MiB, SLC, page size: 2048, OOB size: 64
[    1.595844] Scanning device for bad blocks
[    1.677897] 4 cmdlinepart partitions found on MTD device orion_nand
[    1.684213] Creating 4 MTD partitions on "orion_nand":
[    1.689379] 0x000000000000-0x000000100000 : "u-boot"
[    1.694827] 0x000000100000-0x000000500000 : "uImage"
[    1.700234] 0x000000500000-0x000002500000 : "rootfs"
[    1.705682] 0x000002500000-0x000008000000 : "data"
[    1.711876] libphy: Fixed MDIO Bus: probed
[    1.716328] libphy: orion_mdio_bus: probed
[    1.726492] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
[    2.814150] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC address 00:25:31:04:ae:c5
[    2.823104] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    2.829701] ehci-pci: EHCI PCI platform driver
[    2.834259] ehci-orion: EHCI orion driver
[    2.838457] orion-ehci f1050000.ehci: EHCI Host Controller
[    2.844029] orion-ehci f1050000.ehci: new USB bus registered, assigned bus number 1
[    2.851883] orion-ehci f1050000.ehci: irq 29, io mem 0xf1050000
[    2.873468] orion-ehci f1050000.ehci: USB 2.0 started, EHCI 1.00
[    2.879700] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    2.886544] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.893819] usb usb1: Product: EHCI Host Controller
[    2.898719] usb usb1: Manufacturer: Linux 3.18.5-kirkwood-tld-1 ehci_hcd
[    2.905468] usb usb1: SerialNumber: f1050000.ehci
[    2.910921] hub 1-0:1.0: USB hub found
[    2.914781] hub 1-0:1.0: 1 port detected
[    2.919623] mousedev: PS/2 mouse device common for all mice
[    3.233496] usb 1-1: new high-speed USB device number 2 using orion-ehci
[    3.385138] usb 1-1: New USB device found, idVendor=05e3, idProduct=0608
[    3.391883] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[    3.399088] usb 1-1: Product: USB2.0 Hub
[    3.403978] hub 1-1:1.0: USB hub found
[    3.408137] hub 1-1:1.0: 4 ports detected
[    3.693765] usb 1-1.1: new high-speed USB device number 3 using orion-ehci
[    3.933459] rtc-mv f1010300.rtc: internal RTC not ticking
[    3.939091] i2c /dev entries driver
[    3.943933] hidraw: raw HID events driver (C) Jiri Kosina
[    3.949737] drop_monitor: Initializing network drop monitor service
[    3.956296] TCP: cubic registered
[    3.959634] NET: Registered protocol family 17
[    3.964255] Key type dns_resolver registered
[    3.969383] Loading compiled-in X.509 certificates
[    3.974259] registered taskstats version 1
[    3.979360] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[    3.987972] Freeing unused kernel memory: 268K (c076b000 - c07ae000)
Loading, please wait...
[    4.063965] systemd-udevd[58]: starting version 215
[    4.070950] random: systemd-udevd urandom read with 6 bits of entropy available
[   18.773774] usb 1-1.1: device descriptor read/64, error -110
[   23.963767] usb 1-1.1: device descriptor read/64, error -71
[   24.153765] usb 1-1.1: new high-speed USB device number 4 using orion-ehci
[   24.263763] usb 1-1.1: device descriptor read/64, error -71
[   24.463762] usb 1-1.1: device descriptor read/64, error -71
[   24.653764] usb 1-1.1: new high-speed USB device number 5 using orion-ehci
[   25.083461] usb 1-1.1: device not accepting address 5, error -71
[   25.163763] usb 1-1.1: new high-speed USB device number 6 using orion-ehci
[   25.593463] usb 1-1.1: device not accepting address 6, error -71
[   25.599894] usb 1-1-port1: unable to enumerate USB device
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Waiting for root file system ... done.
Gave up waiting for root device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
   - Check root= (did the system wait for the right device?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  /dev/sda1 does not exist.  Dropping to a shell!
modprobe: module i8042 not found in modules.dep
[   45.934408] uhci_hcd: USB Universal Host Controller Interface driver
[   45.950550] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[   45.967520] usbcore: registered new interface driver usbhid
[   45.973126] usbhid: USB HID core driver


BusyBox v1.22.1 (Debian 1:1.22.0-9+b1) built-in shell (ash)
Enter 'help' for a list of built-in commands.

/bin/sh: can't access tty; job control turned off
(initramfs)

What do you make of that?
Incidentally, it is exactly the same behavior (can't locate root fs) as I mentioned above with the failed live ISO boot. BUT Debian based ones (and others) DO succeed. It is either the detection scripts (udev?), or maybe a missing module?

What do you think?


TIA
pepar

pepar,

Quote

[ 18.773774] usb 1-1.1: device descriptor read/64, error -110
[ 23.963767] usb 1-1.1: device descriptor read/64, error -71
[ 24.153765] usb 1-1.1: new high-speed USB device number 4 using orion-ehci
[ 24.263763] usb 1-1.1: device descriptor read/64, error -71
[ 24.463762] usb 1-1.1: device descriptor read/64, error -71
[ 24.653764] usb 1-1.1: new high-speed USB device number 5 using orion-ehci
[ 25.083461] usb 1-1.1: device not accepting address 5, error -71
[ 25.163763] usb 1-1.1: new high-speed USB device number 6 using orion-ehci
[ 25.593463] usb 1-1.1: device not accepting address 6, error -71
[ 25.599894] usb 1-1-port1: unable to enumerate USB device

Interesting! this is telling us that it can not read the descriptor from the drive, so higher level format is not a problem. It's not udev, module, or initramfs. I think there are 2 possibilities:

- For a few new USB 3.0 drives, sometime we need a quirk input to the kernel (as parameter) to make it work in initialization. In this case, there is nothing you can do other than finding the correct quirk input for the drive.

- The other distros might have a patched USB driver that alters the timing. But it also depends on which hardware platform that the SDUF is used for booting:

Quote

But the following distros have no problem using and booting from the SDUF. Notice that most of them are Debian based.
TAILS, Kali, grml, AntiX, PCLinuxOS Note: even Puppy & variants do not boot (normally quite versatile and resilient)

I would suggest to try:

- Boot with different USB drive, and see if the SDUF is detected and spin up correctly in Debian. This is to confirm if we need to do something extra in initramfs.
- Google the drive model to see if there is quirk out there. I'll also take a look in the source code to see if this already in there as a special case.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi bodhi,

I booted with another USB drive & inserted, then mounted the SDUF:

[  135.193775] usb 1-1.3: new high-speed USB device number 4 using orion-ehci
[  135.304647] usb 1-1.3: New USB device found, idVendor=0781, idProduct=5583
[  135.311576] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  135.319215] usb 1-1.3: Product: Ultra Fit
[  135.323247] usb 1-1.3: Manufacturer: SanDisk
[  135.327785] usb 1-1.3: SerialNumber: 4C531001391224110122
[  135.340128] usb-storage 1-1.3:1.0: USB Mass Storage device detected
[  135.353108] scsi host1: usb-storage 1-1.3:1.0
[  136.354502] scsi 1:0:0:0: Direct-Access     SanDisk  Ultra Fit        1.00 PQ: 0 ANSI: 6
[  136.368694] sd 1:0:0:0: [sdb] 60751872 512-byte logical blocks: (31.1 GB/28.9 GiB)
[  136.376467] sd 1:0:0:0: Attached scsi generic sg1 type 0
[  136.390453] sd 1:0:0:0: [sdb] Write Protect is off
[  136.399453] sd 1:0:0:0: [sdb] Mode Sense: 43 00 00 00
[  136.400204] sd 1:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[  136.444424]  sdb: sdb1 sdb2
[  136.456946] sd 1:0:0:0: [sdb] Attached SCSI removable disk
[  877.678507] kjournald starting.  Commit interval 5 seconds
[  877.684949] EXT3-fs (sdb1): using internal journal
[  877.689777] EXT3-fs (sdb1): mounted filesystem with ordered data mode

So once booted, the kernel has no problem handling the SDUF.
It seems to me, it should be possible to handle the SDUF from initramfs, no?

I have not found anything pointing to a specific quirk.
Maybe the problem is actually caused by a quirk ...


TIA
pepar

pepar,

I think most likely a quirk. And if we find it, it can be passed into the kernel through a parameter, no need to change intramfs. But I've not been able to find the quirk parameter either.

However, it doesn not hurt to try some known quirk, please post output of

lsusb -v

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 05/17/2015 02:58AM by bodhi.

OK bodhi.

Bus 001 Device 004: ID 0781:5583 SanDisk Corp.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x0781 SanDisk Corp.
  idProduct          0x5583
  bcdDevice            1.00
  iManufacturer           1 SanDisk
  iProduct                2 Ultra Fit
  iSerial                 3 4C531001391224110122
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              224mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength           22
  bNumDeviceCaps          2
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes   0x00000002
      Link Power Management (LPM) Supported
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x00
    wSpeedsSupported   0x000e
      Device can operate at Full Speed (12Mbps)
      Device can operate at High Speed (480Mbps)
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   1
      Lowest fully-functional device speed is Full Speed (12Mbps)
    bU1DevExitLat          10 micro seconds
    bU2DevExitLat         256 micro seconds
Device Status:     0x0000
  (Bus Powered)

Anything else I can experiment with?


TIA
pepar

pepar,

There are a couple way to try the quirks. The easiest way is to use uEnv.txt so that you don't have to change u-boot envs for real. But that requires the new u-boot that I've realesed.

You're still running the old u-boot from davygravy, so you need to change u-boot env. But having serial console, it does not matter, you can experiment and not saving it.

Boot with serial console, and interrupt u-boot. At the prompt, set the usb custom param to ignore uas and then boot:

> setenv usb_custom_params 'usb-storage.quirks=0x0781:0x5583:u'
> boot

The UAS quirk above was one of the known quirks that causes a kernel panic. There is a list of quirks that you could try (I don't think they apply to this SDUF case, though). Note the flag u in the quirk string: 0x0781:0x5583:u. It does not hurt to try each one of these flags. However, as a precaution, please back up you SDUF drive content before trying any of these flags.

/* Collect the flags */
	while (*++p && *p != ',') {
		switch (TOLOWER(*p)) {
		case 'a':
			f |= US_FL_SANE_SENSE;
			break;
		case 'b':
			f |= US_FL_BAD_SENSE;
			break;
		case 'c':
			f |= US_FL_FIX_CAPACITY;
			break;
		case 'd':
			f |= US_FL_NO_READ_DISC_INFO;
			break;
		case 'e':
			f |= US_FL_NO_READ_CAPACITY_16;
			break;
		case 'f':
			f |= US_FL_NO_REPORT_OPCODES;
			break;
		case 'h':
			f |= US_FL_CAPACITY_HEURISTICS;
			break;
		case 'i':
			f |= US_FL_IGNORE_DEVICE;
			break;
		case 'l':
			f |= US_FL_NOT_LOCKABLE;
			break;
		case 'm':
			f |= US_FL_MAX_SECTORS_64;
			break;
		case 'n':
			f |= US_FL_INITIAL_READ10;
			break;
		case 'o':
			f |= US_FL_CAPACITY_OK;
			break;
		case 'p':
			f |= US_FL_WRITE_CACHE;
			break;
		case 'r':
			f |= US_FL_IGNORE_RESIDUE;
			break;
		case 's':
			f |= US_FL_SINGLE_LUN;
			break;
		case 't':
			f |= US_FL_NO_ATA_1X;
			break;
		case 'u':
			f |= US_FL_IGNORE_UAS;
			break;
		case 'w':
			f |= US_FL_NO_WP_DETECT;
			break;
		/* Ignore unrecognized flag characters */
		}

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Sorry for the silence. I needed the USB serial for some work on other devices, and was away from the Pogoplugs.

@LeggoMyEggo
I use/have used a multitude of flash drives but have no allegiance to any one model. Mainly because in today's fast pace and volatile market place, things come, change and go much too rapidly.
That said, I have good success using USB 3.0 drives, even if the device only supports USB 2.0 (usually get higher throughput).
Also, in general I try to stick with Kingston, Patriot, PNY, SanDisk. BUT that led me to the SDUF. So, YMMV.


In my further investigations, I found this thread about this very issue, on SanDisk forums:
http://forums.sandisk.com/t5/All-SanDisk-USB-Flash-Drives/can-t-boot-a-Mint-Cin-17-1-live-Sandisk-Ultra-Fit-3-0-32GB/td-p/338326


I upgraded U-Boot to latest, installed 4.0 Kirkwood kernel. But, as expected, no improvements.

Out of curiosity, I installed Arch Linux ARM on another Pogo E02. Did not work with the SDUF.
And to my surprise, it changed the partition layout. Oh well, I intend on flashing OpenWRT as rescue system anyway. But that's another thread.

Side note, I have also tried more live distros on the SDUF. Manjaro (Arch based) and Fedora do boot properly.

I have also found a trick, really a temporary work-around, to be able to boot from the SDUF, 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. This works for Bodhi Debian also, BUT obviously only if you have access to the Pogoplug when rebooting it (i.e. not good for remote/far away devices).

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

@Bodhi: do you still think it's not udev, module, or initramfs related?
Could it have to do with the order in which the modules are loaded/probed?
Is there an easy way to reset the USB port in order to force enumeration again, as soon as the kernel is done booting?
3rd answer: https://askubuntu.com/questions/645/how-do-you-reset-a-usb-device-from-the-command-line


Any feedback appreciated.

TIA
Pepar



Edited 1 time(s). Last edit at 06/05/2015 04:12PM by pepar.

pepar,

> Out of curiosity, I installed Arch Linux ARM on
> another Pogo E02. Did not work with the SDUF.

I'd expect Arch's behavior is the same as Debian's.

> And to my surprise, it changed the partition
> layout.

You can change it back. In theory, no harm done. However, TEN has discovered that Arch installation might have made your other MTD partitions useless for stock Pogo OS.

> I have also found a trick, really a temporary
> work-around, to be able to boot from the SDUF,
> 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. This works for Bodhi Debian also,
> BUT obviously only if you have access to the
> Pogoplug when rebooting it (i.e. not good for
> remote/far away devices).
>
> So the real question is, what procedure do theses
> live distros use to successfully detect the SDUF?

I think it is because different hardware is used, so different timing. And live distro rootfs mounting process usually is different from fixed installation.

>
> @Bodhi: do you still think it's not udev, module,
> or initramfs related?

I don't think so. Consider this: Arch does not use initramfs, so all drivers were compiled into the kernel. That proved the loading order is not a factor. Besides, my built kernel also includes all USB drivers in the kernel istself (not as modules).

> Is there an easy way to reset the USB port in
> order to force enumeration again, as soon as the
> kernel is done booting?

I would try those quirks already implemented in the kernel code first. If none of them works, then try reseting the SDUF as below.

Try this in serial console first. If this works then set it permanently with fw_setenv after booted into Debian:

setenv bootm_sduf 'usb stop; usb start;  bootm 0x800000 0x1100000'
setenv usb_boot 'mw 0x800000 0 1; ext2load usb $usb_device 0x800000 /boot/uImage; if ext2load usb $usb_device 0x1100000 /boot/uInitrd; then run bootm_sduf; else bootm 0x800000; fi'

and then

boot

Note that the above has work around for Debian, not Arch.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I've experienced this too with the CV43 series of SanDisk USB drives. At first thought it was a dud but on further analysis I also was getting the "unable to be enumerated" issue that Bodhi gets.

There's a hardware quirk in this USB stick and I'm not sure what it is, which is a nusciance as they're well priced and supurbly compact. The lower price though does make me wonder what they've left out.

To add another data point to the Sandisk Ultra Fit 3.0 drives issue.

If anyone has trouble using this drive, try to plug it in a Belkin USB 2.0 hub. It seems to work really well, perhaps it will test the theory of the drive timing problem that pepar and some of us has experienced.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 07/16/2015 05:12AM by bodhi.

I recently purchased some more 16GB USB 3.0 Ultra Fit drives as they were cheap. Not only are the new drives smaller in capacity (14.9GB vs. 16.0GB) they DO NOT boot reliably in my E02 whereas the older UF's worked in my E02 without issue. It should be noted the newer UF's present no issues to my Pro V3 so there must be some issue unique to the Kirkwoods that causes booting issues.

My apologies for questioning the OP about the legitimacy of his issue, I should have known better than to assume my earlier experience was applicable to current drives.

Leggo,

I have no problem booting the Sandisk Ultra Fit 16GB with my Dockstar and Pogo Pro. These were bought recently on sale from NewEgg. The boot time improvement was great, and price is now low enought, comparing to my old Sandisk Cruzer Fit. So I plan to use it on other boxes too.

I don't have the 32GB so can't coment about that.

Here is the info for the 16GB UltraFit on the Dockstar:

Bus 001 Device 003: ID 0781:5583 SanDisk Corp. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0781 SanDisk Corp.
  idProduct          0x5583 
  bcdDevice            1.00
  iManufacturer           1 SanDisk
  iProduct                2 Ultra Fit
  iSerial                 3 4C530xxxxxxxxxxxxx
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              224mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 12/13/2015 04:44PM by bodhi.