Rufus Won 39;t Detect Sd Card

[Nicodemo Aidara]

Im facing an issue that is quite familiar with this one but I can't really find out a solution, I've tried diskpart and clean command and also clean and create partition primary but all can't work (screenshot below)

I'll explain how my USB got broken, first I've downloaded Centos everything iso (8GB) and also Rufus and later I plug my 16GB USB and let Rufus burn (not sure does Rufus burn or extract) the everything iso into it, about half to 2/3 of the process I got an error syslinux not exist or something like that and the whole process stops.

Later my USB can't be read/list on file manager, I've opened the disk manager (also the screenshot below) it got listed there, but with no storage, and can't run clean or create partition primary command.

As what Rufus' developer said here, it's because Rufus take some kind of config file out and didn't put it back if the process if terminated half-way, but the method he provides, can't work since the USB isn't even listed on Rufus.

If Disk Manager says "No media", it means that your flash drive is probably dead. What usually happens is that flash drive manufacturers use the same controller chips as the ones you would find on a card reader (e.g. SD card reader) in flash drives, even if the flash memory cannot be removed.

Then, when the flash memory dies, or some hardware issue occurs, the controller detects that it can no longer write to the flash memory and falls back to one of the default behaviour of a card reader, which is to declare that the "flash media" is no longer present, which is what Windows also reports as a result, as per your screenshot.

Unfortunately, since this is indicative of bad flash memory, you probably won't be able to reformat your drive. You may try your luck at locating manufacturer-specific low level restoration tools (but these tools are usually kept private and not made available to the general public) to see if you can reset the internal flash drive controller into "re-mounting" the flash, but you have to bear in mind that you most probably have bad flash memory on this drive, therefore, once you write to one of the bad flash blocks, you'll probably run into the same issue again or get data corruption.

You may also try your hand at reformatting your drive in a different OS if you have one (e.g. Linux), just in case, but by the looks of it, since it seems your flash memory is defective, you're probably better off using a new flash drive.

I had a similar problem: Rufus threw an error while formatting a (large, 128 GB) USB pendrive, even before buring/extracting the ISO (in my case, a Windows 10 ISO).chkdsk was not helpful, because it kept saying the drive was in RAW format. Windows did not recognize it either.

Just for future reference: I think the problem was caused by Windows Defender that blocked Rufus' access to the USB folders (it's the Controller Folder Access functionality). I had to include Rufus in the trusted apps.It may also help to format the drive the usual way, and then use Rufus to write on it.

If you can see the drive in this pc, open disk management and at the bottom part you will see your disk that is unlocated(identify it by the capacity). Then right click and choose the first option(i dont know that would be "shrink volume" or "extend volume" but the option will be at the top) enter your full volume of usb then follow the progress.

This is how I managed to install Windows 10 on my 250gb expansion card whilst having Manjaro installed on my SSD. I can boot into Windows by inserting the expansion card into my laptop and booting it.

Load the ISO into rufus by clicking select and then selecting the ISO with file explorer. If you downloaded an ISO it should just get loaded in once finished, if not select it from the place you chose to store it.

I recommend these settings, although you might want to turn off accessing local disk. I just turn it on so I can use and see the steam library / files on my linux install. Could also be handy if your computer hard crashes and you end up in an unrecoverable state to format your disks like you would do in a linux live enviroment.

However, when booting from the SD card with Windows 95, it just hangs at the very start, before even getting to the "Starting Windows 95..." message. (It doesn't say "missing operating system", but just hangs on a blank screen.)

The laptop, or very close model of it, was sold with an 800 MB drive, so we have to assume that the laptop properly supports disks larger than 504 MiB, i.e. disks with hardware geometry which has more cylinders than the limit of 1024 cylinders, 16 heads, and 63 sectors per cylinder.

As you said, the SD card with the IDE adapter has geometry of 3807 cylinders, 16 heads and 63 sectors per cylinder as detected by BIOS, which is about 1873 MiB. But DOS can't access such geometry, as maximum standard BIOS interface has a limit of 1024 cylinders.

To use these larger hard drives with more than 1024 cylinders, BIOS has to perform geometry translation from the actual unusable physical geometry to usable logical geometry. In this case, the cylinder count is most likely divided by four, and head count is respectively multiplied by four, so via BIOS, the DOS would most likely see a geometry of 951 cylinders, 64 heads, and 63 sectors per track. The resulting usable size would be slightly less, about 1872 MiB.

If you made a roughly 500 MB image with logical and physical geometry of 1014/16/63 and used dd to write it to card, then when you plug that to a DOS computer, DOS will understand that the SD card is a disk that has a 1014/16/63 logical geometry, while BIOS is actually presenting the disk a 951/64/63 logical geometry, and thus chaos and corruption will ensue. After the last logical head what DOS thinks it has, DOS increments the cylinder, but then logically, heads 17-64 presented by BIOS are skipped, and another problem is that DOS thinks it can use cylinders up to 1014 but physically there is only 951 heads so near the end of the disk DOS will try to access beyond the end of the SD card. It could work if the image is small enough to fit into 951/16/63 geometry, however due to the geometry translation, it will use the whole 2GB card sparsely, and it will only work in that system.

So even an image much smaller than the whole SD card, you must create it in a virtual machine by using an identical logical geometry which the SD card is presented via the IDE adapter and BIOS in the target system. It might be 951/64/63, but it might also be something different depending on the target system BIOS.

For best results, zero out the SD card by using dd, plug it in the target system, and by using a DOS or Windows boot floppy, partition the drive and format the partition in the target system, so it will end up being partitioned and formatted with the correct logical geometry and correct size for that specific geometry translation of the BIOS. It even accounts for other quirks of the BIOS does, like reducing the cylinder count by some amount to allow for a landing zone or something similar.

As a side note which relates to older systems, as the BIOS detects the hard drive, it is possible that it can read and print out the physical geometry reported by the drive correctly as having more than 1024 cylinders, but it may not be able to perform physical to logical geometry translation and thus only work with old physical limitations of 1024/16/63 giving you approximately a 504 MiB drive, or in the worst case, 735/16/63 if the 3807 is simply used as a 10-bit value.

I took one of the disk images with Windows 95 installed on it, and examined it with a hex editor. I noticed that when the Windows installer program initially sets up the system files on the C: drive, it puts IO.SYS rather "far" into the filesystem, actually more than 100 MB inward.

What I tried then was to perform a clean format of the disk, and boot from a Windows 95 startup floppy disk. After booting the startup disk, I simply ran sys c: to transfer the bare essential system files to the C drive. This ensured that IO.SYS is close to the beginning of the filesystem. This booted successfully to a bare Windows 95 C: prompt!

The good news is that this mismatched geometry is used primarily for booting. After the DOS kernel is loaded into memory, it performs partition discovery and queries the BIOS for the geometry of each hard disk, thus obtaining the actual logical geometry. Internally, DOS uses linear block addressing and only transforms LBA sector numbers into CHS when interfacing with the BIOS. Luckily enough, the sectors-per-track value agrees between physical and logical geometries, which means that data fitting within the first cylinder (of both geometries) is going to be read correctly. This agrees with the symptoms disappearing when the contents of IO.SYS are placed earlier on the disk: as long as the coordinates of the boot sector and IO.SYS data agree, the problem is not going to be noticeable.

I routinely use DOSBox to create DOS disk images on my modern Linux machine and transfer those images (using 'dd') to various, diverse, MS-DOS compatible computers. This works fine as there are no real differences in virgin/vanilla MS-DOS installations between the various hardware.

Windows 9x is different. It utilizes "sophisticated" hardware detection during the installation and installs drivers that are specific to the detected hardware to enough of a degree that installations are different between different hardware. These images are not readily transferable between machines or from emulator to real hardware.

What I do myself for Windows 9x is, after installing MS-DOS, just copy all the Win9x installer files over to a directory on my media. Then, I run the Windows 9x SETUP on the actual hardware where I intend to use the media. This gives me the correct driver configuration to boot Windows 9x, and also allows continued boot into DOS through a custom startup menu.

I'm trying to install Windows (tried and failed both 10 and 11) on a Lenovo IdeaPad 3 15ITL6. Neither Windows installer recognises any storage drives. I've tried both with and without Intel VMD enabled in BIOS, to no avail.

3a8082e126