Question Toshiba laptop fails to boot after using a caddy to hold a HD in the optical drawer

[Flying Scotsman]

This is my first post, a Happy New Year to all.

We thought it would be useful to use a caddy to hold the old HD in the optical drawer in order to organise transfer of data to a larger HD in my Grandson's laptop: a Toshiba Satellite Pro C660-21D originally shipped with Windows7.

A "Secure Boot" switch is not seen within BIOS, seen as version 1.8, but the symptoms seem to me consistent with Toshiba not wanting to boot from a non-secure drive arrangement.

The caddy was described as: 2nd SATA HDD SSD Hard Drive Bay Caddy for 9.5mm laptop optical drive.
When I asked the ebay supplier for help their reply included "the compatibility of this brand (Toshiba) is poor". I have since seen the same product advertised as "Drive Enclosure Box Case For DELL E6540 E6440 Optibay" - so I should probably never have used it!

At the time we were running Debian 10, the transfer of data was successful. Problems arose when the caddy was removed.

The laptop is almost impossible to boot from cold.

Power on ok, I assume POST fails, there is no confirming Beep.
HD sounds as if it is powered up, I think I can hear fan and HD separately. We have now taken to keeping a Grub boot CD in the optical drive.
The CD (when present) is heard being checked. 49 times out of 50, the display does not light up.
Generally after 15 seconds, there is a burst of full speed fan and everything powers down.

I read that if I Force stop the machine by a long press of the power button this might change things. Rarely is there a long enough window to allow such a long press. When successful, there is a 10% chance that the next power up will light the display and we can access BIOS or Boot menu and we are away!

In Debian:
ls /dev/sd* reveals a ghost /dev/sdb !
lsblk shows HD and partitions correctly.

Udev makes an association like this:

udevadm info /dev/sdb
P: /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/host6/target6:0:0/6:0:0:0/block/sdb
N: sdb
L: 0
S: disk/by-id/usb-Generic-_Multi-Card_20090516388200000-0:0
S: disk/by-path/pci-0000:00:1a.0-usb-0:1.3:1.0-scsi-0:0:0:0
E: DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/host6/target6:0:0/6:0:0:0/block/sdb
E: DEVNAME=/dev/sdb
E: DEVTYPE=disk
E: MAJOR=8
E: MINOR=16
E: SUBSYSTEM=block
E: USEC_INITIALIZED=14284279
E: ID_VENDOR=Generic-
E: ID_VENDOR_ENC=Generic-
E: ID_VENDOR_ID=0bda
E: ID_MODEL=Multi-Card
E: ID_MODEL_ENC=Multi-Card\x20\x20\x20\x20\x20\x20
E: ID_MODEL_ID=0138
E: ID_REVISION=1.00
E: ID_SERIAL=Generic-_Multi-Card_20090516388200000-0:0
E: ID_SERIAL_SHORT=20090516388200000
E: ID_TYPE=disk
E: ID_INSTANCE=0:0
E: ID_BUS=usb
E: ID_USB_INTERFACES=:080650:
E: ID_USB_INTERFACE_NUM=00
E: ID_USB_DRIVER=ums-realtek
E: ID_PATH=pci-0000:00:1a.0-usb-0:1.3:1.0-scsi-0:0:0:0
E: ID_PATH_TAG=pci-0000_00_1a_0-usb-0_1_3_1_0-scsi-0_0_0_0
E: DEVLINKS=/dev/disk/by-id/usb-Generic-_Multi-Card_20090516388200000-0:0 /dev/disk/by-path/pci-0000:00:1a.0-usb-0:1.3:1.0-scsi-0:0:0:0
E: TAGS=:systemd:

However udev refreshes every 50 seconds to point out the error.
The above taken running the HD install which originally encountered the caddy.

On a newly created Debian installed HD, the udev error is different with "No ID" associated with /dev/sdb, still refreshing every 50 seconds.

To try to clear a hard drive of these errors I have used Darik's Boot and Nuke and this reveals another "unknown" drive on the machine.

I took yet another HD and installed Windows 10.

Booting seems slightly more difficult on Windows, (perhaps the CD boot disk is not checked or found!) so the opportunity to boot the HD is reduced.

Windows Device manager sees the ghost drive like this:

<QueryNode><Name LanguageNeutralValue="Device Manager - D:\">Device Manager - D:\</Name>
<QueryList>
<Query Id="0" Path="Microsoft-Windows-Kernel-PnP/Configuration">
<Select Path="Microsoft-Windows-Kernel-PnP/Configuration">*[System/Provider[@Name='Microsoft-Windows-Kernel-PnP'] and EventData/Data[@Name='DeviceInstanceID']='SWD\WPDBUSENUM\_??_USBSTOR#DISK&amp;VEN_GENERIC-&amp;PROD_MULTI-CARD&amp;REV_1.00#20090516388200000&amp;0#{53F56307-B6BF-11D0-94F2-00A0C91EFB8B}']</Select>
<Select Path="System">[System/Provider[@Name='Microsoft-Windows-UserPnp'] and UserData//DeviceInstanceID='SWD\WPDBUSENUM\_??_USBSTOR#DISK&amp;VEN_GENERIC-&amp;PROD_MULTI-CARD&amp;REV_1.00#20090516388200000&amp;0#{53F56307-B6BF-11D0-94F2-00A0C91EFB8B}']</Select>
</Query>

I have not yet tried to re-flash the BIOS. Could this ghost have got "burned in" there?

Or any clues at all to what I have missed in about 3 months searching!


Any clues at all to what I have missed in about 3 months searching!

 

[Ralston18]

Not sure (full disclosure) that I am correctly following all that you have done.

Therefore, compelled to ask: what about clearing CMOS?

Reference:

https://itstillworks.com/12370532/how-to-reset-cmos-on-a-toshiba-satellite

I found other similar links. Just use search criteria as necessary to filter the results as appropriate.

 

[Flying Scotsman]

Hi @Ralston18, thank you for the speedy answer, and for starting with the simple things! That was a nice link. I reset CMOS, have booted into BIOS to confirm the reset, but the ability to boot in less than 20-50 attempts is unchanged.

Previously, I spent most of my time chasing the problem at a software level, I had done really nothing at a hardware level and have very little experience at looking for this sort of fault. Thanks again.

 

[ex_bubblehead]

Is the device listed in /etc/fstab ? Sounds like there's a rogue entry there.

 

[Flying Scotsman]

Negative!

As a new example (partly to myself!), right now, I have booted a USB thumbdrive, (with a squash fs as it happens), machine with an empty hard drive.

nano /etc/fstab shows we are on an overlay; (+ only 1 tmpfs /tmp ... )

ls /dev/sd* ->
/dev/sda /dev/sdb /dev/sdb1 /dev/sdb2 /dev/sdc

# where sda is an empty HD; sdb is the thumbdrive; sdc is the ghost!

@ex_bubblehead thanks for the suggestion! I had shortened all my notes before posting here! I had previously spent much time looking for this sort of solution, so perhaps I can enlarge on the Darick's Boot and Nuke episode.

I had 2 hard drives exposed directly to the caddy, I was sure they were "infected". Having tried several variations of formatting the drives, I ran Boot and Nuke. A second " unknown device" was found. That still fitted with my expectations, there was a hidden partition on the HD. Ran Boot and Nuke for 36 hours. Attempt to reparation the drive, problem still exists. Delete the partition table, "random out" the whole drive with dd if=/dev/random of=/dev/sda


Notice, this to the whole drive, not just the partitions! Set a new partition table, run Boot and Nuke, exactly the same message is seen, Boot and Nuke detects an "unknown device"

So now I seem to be asserting that the error is "on the laptop" where I know of no location which could store this error.

 

[Flying Scotsman]

I thought that I had better provide an update, as I have subscribed the owner of the laptop into this thread.

The more I look at my question I realise that this ghost (gleaned from the combined Debian/Windows view) is:

A SCSI disk with a SATA type connection.
Device: USB
Vendor: Generic
Product: Multi-Card

This data has been written to BIOS, but in a format that cannot be handled by methods of 2011 vintage. Flashing the BIOS must be the way to go! The Existing BIOS is: Phoenix Securecore Tiano Setup 1.8

Initial searches revealed I would need Windows or a Windows Boot Disk to flash BIOS. I also saw warnings unwise to WinFlash BIOS from running Windows - Windows Boot disc floppy was preferred. Roger on that!

My best enquiries led to

https://itstillworks.com/update-bios-toshiba-laptop-6760716.html
led to https://support.dynabook.com/
led to https://uk.dynabook.com/support/bios/
newest "Win2.0" is dated 13/06/2012
named bios-20120613151531.zip, inside which an .exe.

I am not really a Windows user. This laptop was bought "end of life" for use with Debian. I only installed Windows 10 to see how it dealt with the OP issue. Windows 10 is not what I call stable, for instance the keyboard switches off and can only be recovered with 10 second press of Shift key, when the machine is left unattended for a while, it goes down (assumed to sleep) but it winds up powering down, and is not readily recovered.

In trying to resolve a poor "Setup wizard" experience, where I saw that "Microsoft Defender SmartScreen" is involved, before Windows10 has launched, I spoke to a nice man, Carl, at Microsoft, who explained in the nicest possible way that the machine was "end of life" and perhaps I should install Windows 7, which the machine was designed for.

Thanks, Carl, but Windows 7 is also "End of life" so I have found this a bit of a non-runner.

Onwards and Upwards; on Windows10 I try to run the BIOS Win2.0_installer.exe - I use the "Testing for compatibility" mode, I get a machine crash with:

Stop code: PAGE FAULT IN NONPAGED AREA
What failed: WinFlash64.sys

What I read about that indicates that perhaps I should not be running a (2012) Win2.0_installer.exe in 64bit Windows 10.

Again, if someone can see what I am missing, I would love to hear.