Re: have a mate-desktop CD
Reply in-line :-
On 17/03/2018, Thomas Schmitt <firstname.lastname@example.org> wrote:
> shirish wrote:
Sorry for not getting back earlier but as you had changed the thread
headline, I was unable to figure out that you had answered.
> Just to be sure that no regression confuses us here, i downloaded that
> ISO and let xorriso analyse its boot equipment:
> xorriso -indev debian-buster-DI-alpha2-amd64-xfce-CD-1.iso \
> -report_el_torito plain -report_system_area plain
> El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
> El Torito boot img : 1 BIOS y none 0x0000 0x00 4 2011
> El Torito boot img : 2 UEFI y none 0x0000 0x00 832 1803
> So it can boot from DVD via BIOS and via EFI firmware.
> System area summary: MBR isohybrid cyl-align-on GPT APM
> The presence of word "isohybrid" in this line indicates that it can boot
> from USB stick via BIOS. The x86 program code in the Master Boot Record
> will transfer program execution to the El Torito boot image for BIOS.
> MBR partition table: N Status Type Start Blocks
> MBR partition : 1 0x80 0x00 0 1327104
> MBR partition : 2 0x00 0xef 7212 832
> The presence of an MBR partition of type 0xef indicates that it can boot
> from USB stick via EFI firmware. The partition table entry marks a range
> in the ISO image where a FAT filesystem exists with file
> which EFI will execute as x86 EFI program.
> (32-bit x86 EFI expects and runs /EFI/BOOT/BOOTIA32.EFI.)
> So yes, this ISO should boot after being put plainly onto an USB stick
> and then offered to BIOS or EFI as boot device.
> After booting, /dev/sdX and /dev/sdX1 are both mountable as the ISO 9660
> filesystem with nearly all the beef. /dev/sdX2 should be mountable as
> FAT filesystem with just the two directories and the one file BOOTX64.EFI.
> ("X" is the device number which depends on the presence of other devices.)
>> I will definitely try rufus in dd mode but as of buy the sticks, make
>> sure they are genuine
> I'd make that quality check on a GNU/Linux system, where one can rely
> that dd does no things that are smarter than wanted:
> dd if=debian-buster-DI-alpha2-amd64-xfce-CD-1.iso bs=1M of=/dev/sdX
> Use script check_debian_iso to verify that all written bytes are
> correctly readable.
> Then overwite the USB stick with zeros
> dd if=/dev/zero bs=1M count=650 of=/dev/sdX
> in order to erase the successfully copied ISO.
> This verified and then wiped USB stick would be a reliable test bed for
> Rufus et.al.
> If you finally have success, please provide a short description which
> menus or buttons of Rufus need to be used for getting it into DD mode.
> Have a nice day :)
I had been a bit busy at my end and at the same time didn't really
have the time
to go and get a usb stick for playing around. Most of the usb sticks
or the other which I don't want to remove/discard the contents even by
backing up as
usb sticks tend to be 'moody' especially since Triple-level cells are finicky
In response For the previous question, I tried both the ways, first
the 'DD mode' athough
was a bit circumspect as had heard (hearsay) that the unix dd has some
memory leak but that's outside the main story.
FWIW, I had run the binary in 'DD mode' and when it gave up with some
error I couldn't figure out, I tried out usb mode and even there was
out of luck.
Again FWIW, I do have a loaned .iso image to test out the issue. I
probably would be able to play with it probably on the week-end or
later. I would try to get as much details as possible to see if the
issue still persists and if yes, would also CC Pete (the developer of
Rufus) so maybe he can help out as well.
Again, sorry for not answering earlier.
Shirish Agarwal शिरीष अग्रवाल
My quotes in this email licensed under CC 3.0
EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8