Some authentication problem while making bootable USB using rufus - windows

In windows 10, I'm trying to install ubuntu with USB. For making bootable USB, I'm using rufus.
However, there occurs an authentication problem even though I logged in Windows with an administrator account.
Here's the log from rufus.
Will reuse 'ldlinux.sys' and 'ldlinux.bss' from './rufus_files/rufus_files/syslinux-6.03/20171017/' for Syslinux installation
Format operation started
Requesting disk access...
Opened \\.\PHYSICALDRIVE1 for exclusive write access
Requesting lock...
ABORTED: Cannot use an image that is located on the target drive!
\\?\Volume{d0782feb-cabc-11e8-b19e-806e6f6e6963}\ was already mounted as D:\
Re-mounted volume as 'D:' after error
Found USB 2.0 device 'Generic Flash Disk USB Device' (058F:6387)
1 device found
Disk type: Removable, Disk size: 8 GB, Sector size: 512 bytes
Cylinders: 979, Tracks per cylinder: 255, Sectors per track: 63
Partition type: MBR, NB Partitions: 1
Disk ID: 0x1F76D35D
Drive has an unknown Master Boot Record
Partition 1:
Type: NTFS (0x07)
Size: 7.5 GB (8048869376 bytes)
Start Sector: 8192, Boot: No
Found USB 2.0 device 'Generic Flash Disk USB Device' (058F:6387)
1 device found
Disk type: Removable, Disk size: 8 GB, Sector size: 512 bytes
Cylinders: 979, Tracks per cylinder: 255, Sectors per track: 63
Partition type: MBR, NB Partitions: 1
Disk ID: 0x1F76D35D
Drive has an unknown Master Boot Record
Partition 1:
Type: NTFS (0x07)
Size: 7.5 GB (8048869376 bytes)
Start Sector: 8192, Boot: No
It seems like there's some problem during locking.
How can I solve this?

ABORTED: Cannot use an image that is located on the target drive!
The line above means that you are trying to write the drive on which your ISO resides. This is the equivalent to sawing the branch you are sitting on!
Of course, Rufus cannot erase a drive if the image you want to apply resides on that drive.
Please remember that Rufus always repartitions and reformats a drive, so you cannot use anything from that drive, especially not an ISO.
The solution: Move your .iso file somewhere else that isn't the USB drive you are trying to use with Rufus.

after formatting your USB and installing windows, you have one problem after formatting your USB!
USB can't detect in mp3 player, mobile phones, and car.
solve problem =>
open Rufus
choose "MBR partition scheme for BIOS or UEFI" in the partition scheme.
unchoose "create a bootable disk usage"
unchoose "Create extended label and icon files"
click "START" for formatting your USB.

Related

u-boot from Micro SD on A13 board

I am trying to restore an Allwinner A13 based OEM board to working condition, because the original SD card died and there is currently no way to get an original backup image.
Only thing I have so far is the linux rootfs and a partition table it wants to use (The original sizes and filesystems are too unknown to me, so I used what i deemed purposeful).
I have created the partition table, put the rootfs into its partition and set up the toolchain to compile the u-boot + spl.
The board itself only has one Micro SD slot, and this card contains the u-boot + SPL on its first megabyte after the partition table.
The spl and u-boot layout I use:
sector (512b) start size usage
---------------------------------------
0-15 (16) 0kb 8kb MBR+GPT
16-79 (64) 8kb 32kb SPL
80-2047 (1968) 40kb 984kb u-boot
2048 (----) 1024kb (----) partitions
The partition table:
1 MBR 512MB FAT "mmcblk0p1" drive for recovery firmware dumps
2 MBR 512MB FAT "mmcblk0p2" boot volume. perhaps for u-boot environment
3 MBR GPT Container
4 GPT
5 GPT
6 GPT 2048MB ext2 "mmcblk0p6" rootfs
7 GPT 4096MB ext2 "mmcblk0p7" file system for user data
8 GPT 1024MB ext2 "mmcblk0p8" squash image and/or backup are stored here
The rootfs partition contains a folder named boot with these files inside, so I assume the SPL / u-boot eventually wants to boot from there:
/boot/script.bin 32KB
/boot/devicetree.dtb 38KB
/boot/uImage 5200KB
The SPL dies with the following error message on the serial (it doesn't even find the u-boot, the result is the same with only the SPL part dd-ed on the card):
U-Boot SPL 2020.07-rc4-STT-LMT-00022-gbe79009f3b (Jun 12 2020 - 23:40:45 +0000)
DRAM: 256 MiB
CPU: 1008000000Hz, AXI/AHB/APB: 3/2/2
Trying to boot from MMC2
MMC Device 1 not found
spl: could not find mmc device 1. error: -19
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
How can I successfully have this boot the os on the rootfs?

Need to check disk space on /dev/disk2

So, I have a raspberry pie 3 B. I wanted to know how much space is used so I plugged the micro sd card in my mac and opened the terminal.
When I ran the command:
df -h /dev/disk2
I got:
df: /dev/disk2: Raw devices not supported
What should I do now?
PS: I don't want to plug the RPI in.
You'd indeed need to mount the disk first, like Ferrybig said.
Note: It could be, since it's for the RPI, that you SD card is formatted with one of the EXT file system variants. To access those under MacOS, you'll need something like FUSE (free, but I have never used) or Paragon's ExtFS (commercial, I've used it quite often). Some SD cards for the RPI are FAT32 formatted - those should work just fine under MacOS.
Easiest way to mount a volume, if you don't want to mess too much with the commandline parameters, is by opening Disk Utlity. Find the disk/partition you'd like to mount, right click it and select "Mount". This works for "known" file system types.
Now after the disk has been mounted, type "mount" in terminal to see where it's mounted. It will show several lines, one of them could be (as an example):
/dev/disk2s1 on /Volumes/Untitled (ntfs, local, nodev, nosuid, read-only, noowners)
(there may be more that start with "/dev/disk2sX")
df- h /Volumes/Untitled will now show the disk space info, for example:
Filesystem Size Used Avail Capacity iused ifree %iused Mounted on
/dev/disk2s1 15Gi 57Mi 15Gi 1% 19 15239289 0% /Volumes/Untitled
If your disk2 has multiple partitions, then you'd need to repeat the steps for all disks that start with "/dev/disk2sX" (where X is a number).

How to detect a bootable NTFS filesystem?

A hard disk has 4 primary (MBR) partitions, all formatted as NTFS. Only one of them contains a bootable operating system (Windows XP, Windows Vista, Windows 7, Windows 8 or Windows 10). How does my bootloader program figure out which filesystem is bootable? Is it possible just by reading the boot sector (i.e. first 512 bytes) of the filesystem?
The active bit in the partition table has been lost.
Checking that byte 0 is 0xeb or 0xe9 and byte 510 is 0x55 and byte 511 is 0xAA is not enough, because even non-bootable NTFS filesystems created by the mkfs.ntfs tool on Linux pass this test, and the expected and required output for this case is non-bootable.
If my program is able to list the files in the root directory of the NTFS filesystem, which files or directories should I be looking for (NTLDR)?
If all my program has is the first 40960 bytes of the filesystem, can it still decide if the partition is bootable? (Preferably with as simple logic as possible.)
Is this correct: if files \BOOTMGR or \NTLDR exist on the NTFS filesystem, then it's (probably) bootable.
According to my best understanding, the simplest way to detect whether an NTFS filesystem contains a bootable Windows is checking that any of the files BOOTMGR or NTLDR exists in the root directory, because one of these files will be loaded by the boot code.
The NTFS boot sector (i.e. first 512 bytes of the filesystem) doesn't contain definitive information about bootability, because it can be exactly the same for bootable and nonbootable filesystems.
Some more info about Windows booting (with the role of the files BOOTMGR and NTLDR):
https://sites.google.com/site/h2obsession/ibm-pc-at/windows/boot-process/phase-5-ntldr-or-bootmgr
http://thestarman.pcministry.com/asm/mbr/BOOTMGR_Loader_Sectors.htm
It's also worth looking at the source code of os-prober. In os-probes/mounted/x86/20microsoft it's indeed looking for files BOOTMGR and NTLDR (both lowercase). It also has some additional checks, like for BOOTMGR it checks the file boot/bcd and for NTLDR it checks the file ntdetect.com and boot.ini.

How to fix bad dd img write to sdcard

I am trying to write 2016-05-10-raspbian-jessie.img (an image) to my SanDisk Ultra 4GB (Class? 4) SDCARD using my MacBook Pro (running OS X) for my Raspberry Pi.
When I run the dd cmd it gives some errors:
Matts-MacBook-Pro:dev Matt$ sudo dd bs=1m if=~/Downloads/2016-05-10-raspbian-jessie.img of=/dev/rdisk2
dd: /dev/rdisk2: short write on character device
dd: /dev/rdisk2: Input/output error
3782+0 records in
3781+1 records out
3965190144 bytes transferred in 635.507654 secs (6239406 bytes/sec)
I actually get the files on the SDcard but when I boot the Raspberry Pi, I get a kernel panic:
Unable to mount root filessystem on unknown block
An old forum post recommends:
adding a forcefsck to the end of cmdline.txt on the SDCard.
using fsck: sudo fsck -fy /dev/disk2, but I just get back the usage text: usage: fsck -fdnypq -l number
What is the best way to do this in OS X? My MBP is my only working SDCard reader, I can't get the commands that "should" work to work in fsck. It'd even better if you know what the cause is.
How big is the image file, and what's the actual size of the SD card? That looks like it might have run out of space on the disk, since "3965190144 bytes transferred" is 3.965 GB, which is pretty close to the nominal 4GB capacity of the card.
Note: when checking sizes there's a potential for confusion between true gigabytes (GB = 1,000,000,000 bytes) and gibibytes (GiB = 1,073,741,824 bytes) which are sometimes called gigabytes. Disk sizes are generally given in true GB, but RAM is generally given in GiB, and software tools for showing sizes are often inconsistent. When in doubt, look at the actual number of bytes. In OS X, you can get the exact disk size with e.g. diskutil info /dev/disk2.

How to WriteFile to a PhysicalDrive (Windows 7) without getting ERROR_ACCESS_DENIED?

I'm trying to write a test pattern to every sector of a formatted USB drive. There is one logical drive (e.g. h:). This volume is FAT-formatted and contains data to be overwritten. Also, I want to overwrite the whole physical drive. The program is running with elevated user rights.
First I did the following:
// from the drive letter "h:" I get the physical disk number using
// IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS => "\\.\PhysicalDrive2"
hDevice = ::CreateFile( "\\.\PhysicalDrive2", GENERIC_READ|GENERIC_WRITE,
FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL );
// get the number of available sectors with IOCTL_DISK_GET_DRIVE_GEOMETRY_EX
// => ulNumberOfSectors
// now I try to write some sectors, e.g. 2 (I want to use a higher value):
WriteFile( hDevice, abBuffer, 2*512, &byteswritten, NULL );
The call to WriteFile fails with ERROR_ACCESS_DENIED.
If I write one sector, it works.
When I overwrite the first sector and plug the device out and in again, Windows wants to format it. In this situation my code with 2048 sectors at once works without ERROR_ACCESS_DENIED.
I also unmounted the volume as described in CodeProject: WriteFile on Physical Drives with Windows 7 but this didn't change anything. Obviously the volume is unmounted because it's no longer visible in Windows Explorer.
I want to write more than a single sector due to perfomance reasons. I'm also afraid that other problems in the field might occur because I don't fully understand ths problem.
Any suggestions?
I didn't have problems with different WriteFile() sizes, but I did solve the
WriteFile(): Access is denied <ERROR_ACCESS_DENIED/5> to
'\.\physicaldriveX
devices (usually USB HDD/SSD) in Windows 7 running as Administrator (elevated rights) as follows:
Computer Management -> Disk Management:
Volume (H: in your case) -> right-click -> Delete Volume
Disk (Disk 2 in your case) -> right-click -> Off-line
Disk (Disk 2 in your case) -> right-click -> On-line
After that, I'm able to write to '\.\physicaldriveX' with no problem.
I think the Win7 locks (unlike previous Windows releases) the physical device as long as there is any file system on the device to avoid consistency problems.
You cannot directly access sectors of a drive which are owned by a mounted filesystem.
See Changes to the file system and to the storage stack to restrict direct disk access and direct volume access
The documentation for FSCTL_DISMOUNT_VOLUME describes the following sequence for overwriting a filesystem:
Open a volume.
Lock the volume.
Format the volume.
Dismount the volume.
Unlock the volume.
Close the volume handle.
Your pattern-writing operation would be in step 3 instead of formatting.
Another method is to use clean to delete all the partitions (and ALL DATA) on the disk:
C:\> diskpart
Diskpart> list disk
Diskpart> select disk N (where N is your disk number)
Diskpart> clean
Diskpart> exit

Resources