Search Results

Search found 3 results on 1 pages for 'hometoast'.

Page 1/1 | 1 

  • DVD-ROM disappeared under Windows-7

    - by hometoast
    Windows-7 (build 7100) has forgotten about and refused to recognize that I have an optical drive attached. Linux LiveCD sees it (sees it and it boots from it), so it's isolated to the Windows installation. I do have VirtualCloneDrive installed. But I know I had access to the optical drive after the installation of that. Only recently did I try to rip an iso image for mounting in a VM. I do not see the device under device manager (Start,Run,"devmgmt.msc"). I really do not want to do a fresh install. What are my next steps?

    Read the article

  • How to create partition when growing raid5 with mdadm.

    - by hometoast
    I have 4 drives, 2x640GB, and 2x1TB drives. My array is made up of the four 640GB partitions and the beginning of each drive. I want to replace both 640GB with 1TB drives. I understand I need to 1) fail a disk 2) replace with new 3) partition 4) add disk to array My question is, when I create the new partition on the new 1TB drive, do I create a 1TB "Raid Auto Detect" partition? Or do I create another 640GB partition and grow it later? Or perhaps the same question could be worded: after I replace the drives how to I grow the 640GB raid partitions to fill the rest of the 1TB drive? fdisk info: Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0xe3d0900f Device Boot Start End Blocks Id System /dev/sdb1 1 77825 625129281 fd Linux raid autodetect /dev/sdb2 77826 121601 351630720 83 Linux Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0xc0b23adf Device Boot Start End Blocks Id System /dev/sdc1 1 77825 625129281 fd Linux raid autodetect /dev/sdc2 77826 121601 351630720 83 Linux Disk /dev/sdd: 640.1 GB, 640135028736 bytes 255 heads, 63 sectors/track, 77825 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x582c8b94 Device Boot Start End Blocks Id System /dev/sdd1 1 77825 625129281 fd Linux raid autodetect Disk /dev/sde: 640.1 GB, 640135028736 bytes 255 heads, 63 sectors/track, 77825 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0xbc33313a Device Boot Start End Blocks Id System /dev/sde1 1 77825 625129281 fd Linux raid autodetect Disk /dev/md0: 1920.4 GB, 1920396951552 bytes 2 heads, 4 sectors/track, 468846912 cylinders Units = cylinders of 8 * 512 = 4096 bytes Disk identifier: 0x00000000

    Read the article

  • How can I trace NTFS and Share Permissions to see why I can (or can't) write a file

    - by hometoast
    I'm trying to track down WHY I can write in a folder that, by my best estimation, I should not be able to write. The folder is shared with "Everyone" has "Full Control", with the files being more restrictive. My best guess is there's some sort of sub-group membership that's allowing me to write, but the nesting of groups that exists in our Active Directory is pretty extensive. Is there a tool, that will tell me which of the ACL entries allowed or disallowed my writing a file in a folder? The Effective Permissions dialog is marginally helpful, but what I need is something like a "NTFS ACL Trace Tool", if such a thing exists.

    Read the article

1