Linux Mint Forums

Posted: **Thu Oct 10, 2019 12:34 pm**

deepakdeshp wrote: ⤴Thu Oct 10, 2019 12:32 pm

Disk /dev/sdc: 28.9 GiB, 31016878080 bytes, 60579840 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: 0x09bebfcf

Device     Boot   Start     End Sectors  Size Id Type
/dev/sdc1  *          0 3855295 3855296  1.9G  0 Empty
/dev/sdc2       3843044 3847715    4672  2.3M ef EFI (FAT-12/16/32)

Right. And that sdc does not boot for you?

Posted: **Thu Oct 10, 2019 1:16 pm**

Okay, have to be out of here. Shall assume the answer to the above question to be "yes, it does"; would like to reiterate that, then, nothing here has anything to with you first partitioning/formatting the stick yourself.

Posted: **Thu Oct 10, 2019 1:51 pm**

I thought Linux Mint tool (USB image writer) by default only create MBR USB Media. Now even creating such partioning style (MBR/dos) you can boot USB Mint´ s Live in UEFI mode (it was not possible before). Glad to know it, but it does not work with Clonezilla live.

I have never tried cat, dd... but once you have created your GPT USB drive with a FAT 32 partition using gparted or gnome-disk (Disks), you'd better try with Unetbootin or Multisystem (they are not in LM 19.X repositories) . They will work with the Clonezilla Live.

Posted: **Thu Oct 10, 2019 2:35 pm**

JOPETA wrote: ⤴Thu Oct 10, 2019 1:51 pm I thought Linux Mint tool (USB image writer) by default only create MBR USB Media.

No, and that's the point I have been trying to get across some ten times in the above. USB Image Writer does not create any type of partitioning. A "device" is a blank canvas. Any partitioning that device may end up with after writing an image was part of the image; simple bytes in no other sense than any other byte in the image.

In the context of Mint Live/Installer USB images, i.e., images that are (to be) written to the device as is, this is to say that any pre-existing partitioning of the device is irrelevant; is lost when writing the image anyway. This is moreover if I look at the CloneZilla docs no different for its images either: https://clonezilla.org/clonezilla-live.php.

That is: this discussion makes not a single shred of sense and all that anyone should take away from it is that "partitions" live at the same level as their own content as far as "a device" or an image of one is concerned. That there's nothing special about partitioning or formatting; that either is nothing other than writing certain bytes to certain positions on a device, in no other way than for "plain data".

If the point is now not clear though, it will never be so I'll stop stressing (over) it...

Posted: **Thu Oct 10, 2019 3:07 pm**

rene wrote: ⤴Thu Oct 10, 2019 2:35 pm If the point is now not clear though, it will never be so I'll stop stressing (over) it...

Should listen to myself, but thought I'd as a final contribution simply in fact download and look at the CloneZilla images, especially after I saw the documentation did in fact say odd things for USB. It's as said though. I downloaded clonezilla-live-2.6.3-7-amd64.iso, wrote it to a USB stick with Mint's "USB Image Writer" and rebooted from it.

The table on the CloneZilla image/stick is MBR and consists of

Code: Select all

$ sudo fdisk -l /dev/sdc
Disk /dev/sdc: 3,8 GiB, 4009754624 bytes, 7831552 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: 0x1fa35c4b

Device     Boot Start    End Sectors  Size Id Type
/dev/sdc1  *       64 565247  565184  276M 17 Hidden HPFS/NTFS

Certainly a UEFI system will need to boot it in Legacy or CSM mode -- but again, nothing other than simply writing the image to a device is relevant here also for the CloneZilla images.

Posted: **Thu Oct 10, 2019 3:19 pm**

Can somebody do a small thing?
Format a stick as gpt. Create only one single fat32 partition. Write the Clonezilla or Mint 19 images to it by right clicking the iso and write the image. Try booting it in csm or uefi. In my case neither booted. Or is this the expected result?
I am retiring for the night now.

Posted: **Thu Oct 10, 2019 3:34 pm**

There is one possibility. That his system identified the stick as GPT from the backup GPT at the end of the device --- an area that wasn't overwritten by the image simply due to the image being smaller than the device --- and then failed to boot from the in both cases actual MBR table.

That would be incredibly odd and certainly a UEFI system I have here does nothing of the sort -- but Deepak can test this theory by zeroing out the backup GPT at the end of the USB stick manually:

Code: Select all

sudo dd if=/dev/zero of=/dev/sdz seek=$(($(sudo blockdev --getsz /dev/sdz) - 34)) count=34

with the proper /dev/sdz. If it then DOES boot, well, lovely, yet another UEFI-firmware "oddity".

Posted: **Thu Oct 10, 2019 3:36 pm**

deepakdeshp wrote: ⤴Thu Oct 10, 2019 3:19 pm Can somebody do a small thing?
Format a stick as gpt. Create only one single fat32 partition. Write the Clonezilla or Mint 19 images to it by right clicking the iso and write the image. Try booting it in csm or uefi. In my case neither booted. Or is this the expected result?
I am retiring for the night now.

Screenshots for before and after. Booted in both CSM and UEFI depending on firmware settings.

Screenshot at 2019-10-10 14-24-43.png

Posted: **Thu Oct 10, 2019 3:52 pm**

athi wrote: ⤴Thu Oct 10, 2019 3:36 pm
deepakdeshp wrote: ⤴Thu Oct 10, 2019 3:19 pm Can somebody do a small thing?
Format a stick as gpt. Create only one single fat32 partition. Write the Clonezilla or Mint 19 images to it by right clicking the iso and write the image. Try booting it in csm or uefi. In my case neither booted. Or is this the expected result?
I am retiring for the night now.
Screenshots for before and after. Booted in both CSM and UEFI depending on firmware settings.
Screenshot at 2019-10-10 14-24-43.png
Screenshot at 2019-10-10 14-24-43.png

@Athi,
Thank you. If you are able to boot both Clonezilla or Mint 19 in either csm or UEFi, then I have to say that my HP laptop, with latest BIOS, is quirky in some way. I really spent hours trying to boot from a USB and it refused to do so with the above mentioned procedure.

Posted: **Thu Oct 10, 2019 3:55 pm**

Should have been more clear, that is with Mate 19.2 ISO and not Clonezilla.

Posted: **Thu Oct 10, 2019 3:59 pm**

You can try the above zeroing out of the backup GPT to at least see if indeed that is your system's issue. Or just zero the complete device before writing the image to it.

Posted: **Fri Oct 11, 2019 4:00 am**

rene wrote: ⤴Thu Oct 10, 2019 3:59 pm You can try the above zeroing out of the backup GPT to at least see if indeed that is your system's issue. Or just zero the complete device before writing the image to it.

Will that command be

Code: Select all

sudo sgdisk --clear /dev/sdb

?

Posted: **Fri Oct 11, 2019 4:51 am**

Err, no, the actual command I gave above:

Code: Select all

sudo dd if=/dev/zero of=/dev/sdz seek=$(($(sudo blockdev --getsz /dev/sdz) - 34)) count=34

(posted here with /dev/sdz rather than /dev/sdb because I don't want anyone to idly copy & paste commands that are (a little) dangerous to a normal disk without thinking about it)

What is does is zero out the last 34 sectors of your /dev/sdb, i.e., the backup of the GPT at the end of the disk. See... when you partitioned the USB-stick using GPT format, this caused the GPT datastructures to be written to both the first and last 34 sectors of the stick, latter as backup of former. As I stressed a number of times above, when you then wrote the Linux Mint or CloneZilla image to the stick you overwrote certainly those first 34 sector again, so in an essential sense the GPT partitioning can not have anything to do with the symptom you observed. Trying to think of how it still could in a non-essential, bug sense I had the notion that even after you having written the image over the main GPT, your BIOS could look at the end of the disk and still find the backup GPT and gotten confused, since writing the image to the device wouldn't have also overwritten that, the image being smaller than the device.

Mind you, it's a bit of a theoretical notion, since a regular MBR repartitioning wouldn't normally clear out the backup GPT automatically either (well, maybe through GParted it will) and certainly a UEFI system here does not take any notion of a backup GPT without a main one present, but I'm trying to compensate for you likely not being delusional as to the symptom at least. It's the only thing I can think of that makes some remote sense...

So, what you'd do is GPT-partition the stick, format its single partition or not as to liking, and write the image to the stick. At that point you'd first confirm that the so created stick does not boot for you, as you have been saying. Then, you'd run the above on it, i.e., do nothing other than zero out the last 34 sectors of the stick, and retry if it will then boot. If yes, we're looking at a UEFI bug/oddity (not going to check the full UEFI standard to decide on the proper term) of your specific system.

If, as expected, no... then I'm for now out of ideas as to how you could be seeing that which you say you are

Posted: **Fri Oct 11, 2019 9:01 am**

Note:-
Sorry for the long post, its an exact account of what I did

rene wrote: ⤴Fri Oct 11, 2019 4:51 am Err, no, the actual command I gave above:
Code: Select all
sudo dd if=/dev/zero of=/dev/sdz seek=$(($(sudo blockdev --getsz /dev/sdz) - 34)) count=34

Sorry I missed that post. I tried as per your advise. Here is what I did.
I took the Clonezilla stick .Booted with the already created stick to make sure it boots.
Made a gpt partition table. Didnt make any partition like FAT32 etc. To test the theory that making a partition does not matter.
Wrote the iso by right clicking the iso and choosing write option.
Tried to boot from the stick. As expected , it did not boot.
Ran the dd command and wrote zeros to the ending partition table .
Output of dd command

Code: Select all

sudo dd if=/dev/zero of=/dev/sdb seek=$(($(sudo blockdev --getsz /dev/sdb) - 34)) count=34
34+0 records in
34+0 records out
17408 bytes (17 kB, 17 KiB) copied, 0.000302773 s, 57.5 MB/s

Tried to boot from the stick , but it did not boot.
I made an msdos partition table. Didnt make any partition like FAT32 etc.
Wrote the iso to the stick.
Couldnt boot from the stick.
Tried to make a FAT32 partition. Wasnt successful.
Tried to make gpt partition type. Wasnt successful. I was asked to reboot.
Rebooted. (Later found that reboot wasnt required, only pulling out the stick and inserting would do.)
Made msdos partition table.
Created single FAT32 partition.
Wrote the iso to the stick.
Tried with all 3 USB ports.Unable to boot from stick.
Made msdos partition table.
Created single FAT32 partition.
Wrote the iso to the stick. In the writer used option to power off the stick. No success.
Earlier I was successful with Kernel 5.0.21 , I tried above procedure with kernel 5.3.x.
I tried with kernel 5.0.21 yet unsuccessful. I am not sure what to do now feeling lost due to the inconsistent behaviour.
Please let me know if I should do anything else. I really spent countless hours for this as booting from the stick is a very important part of system maintenance. Clonezilla backups and restores, installing the system from iso etc arent possible without this option.

Posted: **Fri Oct 11, 2019 9:36 am**

Okay, so we're now at you not being able to create a bootable CloneZilla USB stick in any manner, it seems. Let us verify that you can create a bootable Linux Mint Live/Installer USB. I.e., don't bother with any partitioning or formatting, just immediately write a Linux Mint ISO to the stick. That shoudl be able to boot both in Legacy/CSM and UEFI. Does it?

I.e., are we not just talking about a flaky USB stick causing the inconsistencies here?

Posted: **Fri Oct 11, 2019 12:31 pm**

rene wrote: ⤴Fri Oct 11, 2019 9:36 am Okay, so we're now at you not being able to create a bootable CloneZilla USB stick in any manner, it seems. Let us verify that you can create a bootable Linux Mint Live/Installer USB. I.e., don't bother with any partitioning or formatting, just immediately write a Linux Mint ISO to the stick. That shoudl be able to boot both in Legacy/CSM and UEFI. Does it?

I.e., are we not just talking about a flaky USB stick causing the inconsistencies here?

The Mint iso booted right away without making any partition etc using the same stick. So stick was ruled out. I had tuxboot installed, I used it to burn the iso and it works!! Thank yo so much, without your help it wouldn't be possible.

Posted: **Fri Oct 11, 2019 12:54 pm**

Well, okay, I guess. A UEFI system here had no issue booting the CloneZilla Live stick created simply as a direct image write and if I'm not now mistaken, earlier you had it boot without tuxboot as well... but if you're happy, then I'm happy

Posted: **Fri Oct 11, 2019 12:59 pm**

rene wrote: ⤴Fri Oct 11, 2019 12:54 pm Well, okay, I guess. A UEFI system here had no issue booting the CloneZilla Live stick created simply as a direct image write and if I'm not now mistaken, earlier you had it boot without tuxboot as well... but if you're happy, then I'm happy

I tested it 3 times with tuxboot always successful. Without tuxboot it was a pain. I am very happy and you made me so. An important problem is solved,☺.

Posted: **Fri Oct 11, 2019 1:07 pm**

I'm a little uneasy taking credit there; it wasn't me who suggested tuxboot. But hey, congratulations

Posted: **Fri Oct 11, 2019 4:56 pm**

rene wrote: ⤴Fri Oct 11, 2019 1:07 pm I'm a little uneasy taking credit there; it wasn't me who suggested tuxboot. But hey, congratulations

You are being modest.

You proved that there was no problem with the Mint live usb.

Linux Mint Forums

(SOLVED) booting clonezilla from usb mystery

Re: Booting from usb mystery

Re: Booting from usb mystery

Re: Booting from usb mystery

Re: Booting from usb mystery

Re: Booting from usb mystery

Re: Booting from usb mystery

Re: Booting from usb mystery

Re: Booting from usb mystery

Re: Booting from usb mystery

Re: Booting from usb mystery

Re: Booting from usb mystery

Re: Booting from usb mystery

Re: Booting from usb mystery

Re: Booting from usb mystery

Re: Booting from usb mystery

Re: Booting from usb mystery

Re: (SOLVED) booting clonezilla from usb mystery

Re: (SOLVED) booting clonezilla from usb mystery

Re: (SOLVED) booting clonezilla from usb mystery

Re: (SOLVED) booting clonezilla from usb mystery