Announcement

Collapse
No announcement yet.

Building a Kubuntu live USB installer using dd

Collapse
This topic is closed.
X
X
Collapse
 
  • Page of 1
  • Filter
  • Time
  • Show
Clear All
new posts
Previous template Next
    #1

    Building a Kubuntu live USB installer using dd

    Building a Kubuntu live USB installer using dd

    UPDATE (9-8-2015)
    Written as a stand-alone how-to, with references and notes, see:

    Building a Kubuntu live USB flash drive installer using dd
    https://www.kubuntuforums.net/showthread.php?43221-GRUB-2-A-Guide-for-Users&p=378712#post378712

    ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]

    The original post and discussion follows here -->

    Building a Kubuntu live USB installer using dd.
    (UFD = USB Flash Drive)

    https://www.kubuntuforums.net/showth...l=1#post370675

    Guess I should put this in here:
    CAUTION. See Posts #7 & #8 of the above link about using the dd command.
    Specifically:
    sudo dd if=/path/to/iso of=/dev/sdX bs=16M
    You must specify the sdX VERY carefully or you could damage/destroy the data on one of your drives. sdX should be the correct device notation for the flash drive you are using to build your Live Kubuntu USB flash drive.

    OK, then, continuing here ...

    SteveRiley
    Actually, you don't even need to create the partitions, those are contained within the image. I verified this just now. Simply dd the ISO directly to the device node ...
    Out of curiosity, I checked this. It seems correct, kind of amazingly.

    I looked at three cases.
    Prior to issuing the above dd command,
    (1) There is NOTHING on the flash drive.
    or,
    (2) There is a valid MBR partition on the flash drive (in GParted: msdos).
    or,
    (3) There is a valid GPT partition scheme on the flash drive.

    In all three cases, the following statement builds a bootable, live USB Kubuntu/installer (which, of course, I tested each time) (Note: my flash drive is seen as /dev/sdb in my system):

    Code:
     sudo dd if=kubuntu-14.04.2-desktop-amd64.iso of=/dev/sdb bs=16M
 65+1 records in
 65+1 records out
 1093238784 bytes (1.1 GB) copied, 149.653 s, 7.3 MB/s
    However, GParted and fdisk and gdisk reported different, unclear, and/or confusing things about the partition table on the flash drive.

    For example, after running the dd command to copy the iso file, checking the flash drive in GParted, I get this message:
    /dev/sdb contains GPT signatures, indicating that it has a GPT table. However, it does not have a valid fake msdos partition table, as it should. Perhaps it was corrupted -- possibly by a program that doesn't understand GPT partition tables. Or perhaps you deleted the GPT table, and are now using an msdos partition table. Is this a GPT partition table?
    In another test, I created (and checked) a valid GPT on the flash drive, and then installed by dd the file kubuntu-14.04.2-desktop-amd64.iso to the flash drive (and tested that the Live Kubuntu flash drive worked), and got this from gdisk and from GParted:

    Code:
      sudo gdisk -l /dev/sdb
 GPT fdisk (gdisk) version 0.8.8
  
 Partition table scan:
   MBR: MBR only
   BSD: not present
   APM: not present
   GPT: not present
 
  
 ***************************************************************
 Found invalid GPT and valid MBR; converting MBR to GPT format
 in memory.  
 ***************************************************************
  
 Disk /dev/sdb: 2135232 sectors, 1.0 GiB
 Logical sector size: 512 bytes
 Disk identifier (GUID): FC5CA7E4-BC4E-4700-9445-48A22D65FFA8
 Partition table holds up to 128 entries
 First usable sector is 34, last usable sector is 2135198
 Partitions will be aligned on 4-sector boundaries
 Total free space is 2130493 sectors (1.0 GiB)
  
 Number  Start (sector)    End (sector)  Size       Code  Name
    2         2040756         2045427   2.3 MiB     EF00  EFI System

    And in GParted, I got this:

    Partition: unallocated with warning !
    Filesystem: unallocated
    Size: 1.02 GiB
    Used: --
    Unused: --
    Flag: (blank)

    On another similar test, I got this message from GParted:
    ... GPT partition table appears to be corrupt, using the backup GPT.
    GParted note:
    I tried the GParted from my installed Kubuntu 14.04:
    GParted 0.18.0;
    and I tried a Live GParted CD (for 64-bit, UEFI):
    gparted-live-0.21.0-1-amd64 .iso


    Summary

    In my experience, the dd statement
    sudo dd if=kubuntu-14.04.2-desktop-amd64.iso of=/dev/sdb bs=16M
    does build the live UFD Kubuntu installer regardless of what (partition arrangement) is on the flash drive previously (nothing, or an MBR, or a GPT).
    But GParted seems confused by what the image is on the flash drive.

    Any ideas how to get more info (on what exactly is on the flash drive) from some disk utility, perhaps a command line utility?
    Last edited by Qqmike; Sep 08, 2015, 03:57 PM.
    An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski
    Tags: None
    • Top
    • Bottom
    #2
    Yeah, it's unusual.

    There are two partitions. The small EFI system partition allows the drive to boot a machine in UEFI mode. But it's definitely not a GPT drive:
    Code:
    steve@t520:~$ [B]sudo fdisk -l /dev/sdc[/B]

Disk /dev/sdc: 1.9 GiB, 2002780160 bytes, 3911680 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x145a0686

Device     Boot Start     End Sectors  Size Id Type
/dev/sdc1  *        0 2082815 2082816 1017M  0 Empty
/dev/sdc2       17896   22567    4672  2.3M ef EFI (FAT-12/16/32)
    The large partition is actually a Joliet file system with the El Torito boot extension. Tools like fdisk and gdisk don't understand these. But blkid does:

    Code:
    steve@t520:~$ [B]sudo blkid -p /dev/sdc[/B]
/dev/sdc: UUID="2014-04-16-17-44-38-00" BOOT_SYSTEM_ID="EL TORITO SPECIFICATION" VERSION="Joliet Extension" LABEL="Kubuntu 14.04 LTS amd64" TYPE="iso9660" USAGE="filesystem" PTUUID="145a0686" PTTYPE="dos"

steve@t520:~$ [B]sudo blkid -p /dev/sdc1[/B]
/dev/sdc1: UUID="2014-04-16-17-44-38-00" BOOT_SYSTEM_ID="EL TORITO SPECIFICATION" VERSION="Joliet Extension" LABEL="Kubuntu 14.04 LTS amd64" TYPE="iso9660" USAGE="filesystem" PTUUID="145a0686" PTTYPE="dos" PART_ENTRY_SCHEME="dos" PART_ENTRY_UUID="145a0686-01" PART_ENTRY_TYPE="0x0" PART_ENTRY_FLAGS="0x80" PART_ENTRY_NUMBER="1" PART_ENTRY_OFFSET="0" PART_ENTRY_SIZE="2082816" PART_ENTRY_DISK="8:32"

steve@t520:~$ [B]sudo blkid -p /dev/sdc2[/B]
/dev/sdc2: SEC_TYPE="msdos" UUID="20E8-7ECD" VERSION="FAT12" TYPE="vfat" USAGE="filesystem" PART_ENTRY_SCHEME="dos" PART_ENTRY_UUID="145a0686-02" PART_ENTRY_TYPE="0xef" PART_ENTRY_NUMBER="2" PART_ENTRY_OFFSET="17896" PART_ENTRY_SIZE="4672" PART_ENTRY_DISK="8:32"
    • Top
    • Bottom

    Comment

      #3
      Code:
       mike@mike-desktop:~$ sudo fdisk -l /dev/sdb
 [sudo] password for mike:  
  
 WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.

 Disk /dev/sdb: 15.6 GB, 15552479232 bytes
 255 heads, 63 sectors/track, 1890 cylinders, total 30375936 sectors
 Units = sectors of 1 * 512 = 512 bytes
 Sector size (logical/physical): 512 bytes / 512 bytes
 I/O size (minimum/optimal): 512 bytes / 512 bytes
 Disk identifier: 0x609e9a78
  
    Device Boot      Start         End      Blocks   Id  System
 /dev/sdb1   *           0     2135231     1067616    0  Empty
 /dev/sdb2         2040756     2045427        2336   [COLOR=#ff0000]ef  EFI (FAT-12/16/32)[/COLOR]
      Code:
       mike@mike-desktop:~$ sudo blkid -p /dev/sdb
 /dev/sdb: LABEL="Kubuntu 14.04.2 LTS amd64" TYPE="iso9660" USAGE="filesystem" PTTYPE="dos"  
  
 mike@mike-desktop:~$ sudo blkid -p /dev/sdb1
 /dev/sdb1: LABEL="Kubuntu 14.04.2 LTS amd64" TYPE="iso9660" USAGE="filesystem" PTTYPE="dos" PART_ENTRY_SCHEME="dos" PART_ENTRY_TYPE="0x0" PART_ENTRY_FLAGS="0x80" PART_ENTRY_NUMBER="1" PART_ENTRY_OFFSET="0" PART_ENTRY_SIZE="2135232" PART_ENTRY_DISK="8:16"  

 mike@mike-desktop:~$ sudo blkid -p /dev/sdb2
 /dev/sdb2: SEC_TYPE="msdos" UUID="3006-9304" VERSION="FAT12" TYPE="vfat" USAGE="filesystem" PART_ENTRY_SCHEME="dos" PART_ENTRY_TYPE="0xef" PART_ENTRY_NUMBER="2" PART_ENTRY_OFFSET="2040756" PART_ENTRY_SIZE="4672" PART_ENTRY_DISK="8:16"
      Output looks similar to yours for the first and second partitions; I'll have to check it carefully later.
      (ISO 9660 ... https://www.google.com/search?client...utf-8&oe=utf-8 ...)

      As for my output to
      sudo fdisk -l /dev/sdb
      I'm not surprised or upset ... My results still hold. This output is an artifact of sorts. I should have zeroed-out my entire flash drive after each experiment. When I did the experiment that required I start with a GPT, that put all sorts of GPT bits and pieces around that flash drive, like the backup partition table at the end of the flash drive. Thus, gdisk is trying to repair it, I think:

      Code:
       mike@mike-desktop:~$ sudo gdisk -l /dev/sdb  
 [sudo] password for mike:  
 GPT fdisk (gdisk) version 0.8.8
  
 Caution: invalid main GPT header, but valid backup; regenerating main header
 from backup!
  
 Caution! After loading partitions, the CRC doesn't check out!
 Warning! Main partition table CRC mismatch! Loaded backup partition table
 instead of main partition table!
  
 Warning! One or more CRCs don't match. You should repair the disk!
  
 Partition table scan:
   MBR: MBR only
   BSD: not present
   APM: not present
   GPT: damaged
  
 Found valid MBR and corrupt GPT. Which do you want to use? (Using the
 GPT MAY permit recovery of GPT data.)
  1 - MBR
  2 - GPT
  3 - Create blank GPT
  
 Your answer: 2   [COLOR=#ff0000]<--what the heck, why not?[/COLOR]
 Disk /dev/sdb: 30375936 sectors, 14.5 GiB
 Logical sector size: 512 bytes
 Disk identifier (GUID): BB9F5671-7E26-4A5F-ACB8-624BEE9318A1
 Partition table holds up to 128 entries
 First usable sector is 34, last usable sector is 30375902
 Partitions will be aligned on 2048-sector boundaries
 Total free space is 30375869 sectors (14.5 GiB)
 
 Number  Start (sector)    End (sector)  Size       Code  Name
      (Btw, that didn't fix it, but who cares ... the experiment's results hold; my damaged various partition scheme(s) is another separate matter. The flash drive works fine.)
      An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski
      • Top
      • Bottom

      Comment

        #4
        Note: I edited Post #1 to include a caution about using the dd command correctly (or you could damage/destroy your data on one of your disks).
        An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski
        • Top
        • Bottom

        Comment

          #5
          I am certainly no expert but I have a little experience of anomalies in the way gparted, fdisk and gdisk see a thumb drive.
          I have been trying to get to the bottom of this and being a non expert I've been stumbling around in the dark.
          I have read that Linux formatting of thumb drives and sd memory, such as found in cameras, creates changes that only formatting in the camera, or in Windows can correct.
          From what I have read, Linux formatting reorganizes the geometry of the thumb drives and SD memory, which means that the CHS values are changed from their original values, creating some sort of a mismatch.
          I have been formatting thumb drives in Linux for years without being aware of this.
          I'm quite open to being told this is all rubbish, but I have seen for myself that CHS values get altered and it does go some way to explaining strange reports after a Linux format.
          By the way, the fact that this occurs does not always mean that the media is necessarily unusable, though sometimes it can be.
          CHS in disk geometry is the count of cylinder-head-sector on a disk and is generally considered to be of no concern to Linux users, but does perhaps influence the way these disks perform.
          Last edited by bobbicat; Apr 20, 2015, 11:29 PM.
          • Top
          • Bottom

          Comment

            #6
            That's not the issue here. Here, the iso image (bit for bit) comes as a (well-known) filesystem (on the target thumb drive) that requires other tools (like blkid) to read.

            Your issue is another, more general one, I am not aware of--no problems here formatting UFDs and using them interchangeably on Linux and Windows. Things like CHS are no longer relevant, the focus nowadays being logical not physical. And so on. Perhaps another thread to explore this with people who know more?
            An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski
            • Top
            • Bottom

            Comment

              #7
              bobbicat, one more thing. You may be noticing the seemingly bad things happening in my posts. That's my fault: I did 3 experiments but got sloppy and left artifacts laying around all over the place (literally, from protective MBR to a back-up partition table at the every end of the flash drive). Those are not really "bad" results happening, they are kind of irrelevant and controllable. I should have used dd to simply zero-out the flash drive after each case I looked at. Issue is moot. The iso's filesystem, dd-ed bit-by-bit to the flash drive, overrode all of it and works great to control the booting of the flash drive.
              An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski
              • Top
              • Bottom

              Comment

                #8
                just a side note on this ,,,,,,,I just remade a live-USB of 15.04-relece(not beta) and using the "startup disk creator" in a 15.04 install I got a non working startup disk (should have rote down the error but something like "not a com32 img" over and over ) ,,,,,,,using dd worked like a charm however ,,,,,now to reinstall over the 15.04 install that started life as a beta and got ,,,,,hummm strange after adding the ppa:kubuntu-ppa/beta to get the new plasma ver.

                the 14.10 upgraded with the "do-relece-upgrade -d " is working ok still

                VINNY
                i7 4core HT 8MB L3 2.9GHz
                16GB RAM
                Nvidia GTX 860M 4GB RAM 1152 cuda cores
                • Top
                • Bottom

                Comment

                  #9
                  Vinny, yeah, the dd method of building a bootable, live USB flash drive seems like the way to go, pretty slick imo.

                  And one could experiment with dcfldd "enhanced version of dd for forensics and security" -- man dcfldd (or info dcfldd for complete manual, after you install it). I used to use it, but haven't for some time, I used it the other day and it seemed fine, seemed fast (but how? as it is basically dd).
                  An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski
                  • Top
                  • Bottom

                  Comment

                    #10
                    UPDATE (9-8-2015)
                    Written as a stand-alone how-to, with references and notes, see:

                    Building a Kubuntu live USB flash drive installer using dd
                    https://www.kubuntuforums.net/showth...712#post378712
                    An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski
                    • Top
                    • Bottom

                    Comment

                    Previous template Next
                    Working...
                    X