Bug#740504: Please Confirm This Information if you are Dead or Alive.
*Confirm This Information.* *It is totally against the ethics and civil service code of conduct in accordance with oath of secrecy for me to do this but I wish to do this on personal capacity believing you will not betray me but will surely come back to reward me for my sincerity, honesty and for my great effort made to secure a successful conclusion of this transaction in your favor. Please confirm if truly the bank has communicated you regarding payment of your overdue fund.* *However, I wish to inform you that your Attorney. Has presented a woman submitting her name claiming that you were death and to be your next of kin, her details and banking particular was among the list certified for payments,see below and confirm for the account she submitted for transfer of your fund Valued at US$9.600 Million United States Dollars.* *Beneficiary: Ms.Ronnette James* *Bank Name: The Commerce Bank* *Bank Address: 1072, Richmond av.* *Staten Island, New York* *Account Number: 4121097896,* *Routing No:003-051-200,* *Swift Code: CBNAUS33* *I have inquired deeper to come to the conclusion that she and few powerful individuals are behind this dastardly act without due notices to you, As it stands now,you will certainly encounter enormous problems to convince the International Remittance Department that you have not been served with required number of direct notices. You are therefore advised to submit your approval, as the bank will certainly not be held responsible for paying into a wrong account, It will serve you well if you would quickly get back to me.so that I can issue instruction for re-verification on your payment file towards Online Transfer of your fund (US$9.600 Million United States Dollars) to you.* *Please we need to hear from you before the transfer take place to confirmed if you are death for real or they are trying to remove you from the inheritance approved funds.* *Thanks for your co-operations.* *Sincerely,* *MR.Cordiez Tagba* *SECRETARIAT GENERAL* *FOREIGN REMITTANCE DEPT.* *BANQUE ATLANTIQUE TOGO* *Security and Finance Company,* *Email;hon.cordiezta...@aol.com * *Direct line:+228 98596621.* *NOTE: IF YOU RECEIVED THIS MESSAGE IN YOUR SPAM/BULK FOLDER, THAT IS BECAUSE OF THE RESTRICTIONS IMPLEMENTED BY YOUR INTERNET SERVICE PROVIDER*
Bug#740504: cdimage.debian.org: Released ISO images have invalid GPT tables
Hi,
Chris Bainbridge:
I still can't create a partition, which was the original aim. Is it
supposed to work?
I succeeded with gdisk on my oldstable test machine (help texts and
clueless actions of mine not shown):
--
$ dd if=debian-testing-amd64-netinst.iso of=/dev/sdb bs=2048
$ /bin/gdisk /dev/sdb
GPT fdisk (gdisk) version 0.8.1
Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: present
Found valid MBR and GPT. Which do you want to use?
1 - MBR
2 - GPT
3 - Create blank GPT
Your answer: 2
Using GPT and creating fresh protective MBR.
Command (? for help): p
Disk /dev/sdb: 3915776 sectors, 1.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 2A2942FB-D14C-4710-A41F-DECF92DA20FE
Partition table holds up to 208 entries
First usable sector is 64, last usable sector is 446410
Partitions will be aligned on 4-sector boundaries
Total free space is 3 sectors (1.5 KiB)
Number Start (sector)End (sector) Size Code Name
235724403 416.0 KiB 0700 ISOHybrid1
Command (? for help): x
Expert command (? for help): e
Relocating backup data structures to the end of the disk
Expert command (? for help): m
Command (? for help): p
Disk /dev/sdb: 3915776 sectors, 1.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 2A2942FB-D14C-4710-A41F-DECF92DA20FE
Partition table holds up to 208 entries
First usable sector is 64, last usable sector is 3915712
Partitions will be aligned on 4-sector boundaries
Total free space is 3469305 sectors (1.7 GiB)
Number Start (sector)End (sector) Size Code Name
235724403 416.0 KiB 0700 ISOHybrid1
Command (? for help): n
Partition number (1-208, default 1): 3
First sector (446408-3915712, default = 446408) or {+-}size{KMGTP}:
Last sector (446408-3915712, default = 3915712) or {+-}size{KMGTP}:
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300):
Changed type of partition to 'Linux filesystem'
Command (? for help): p
Disk /dev/sdb: 3915776 sectors, 1.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 2A2942FB-D14C-4710-A41F-DECF92DA20FE
Partition table holds up to 208 entries
First usable sector is 64, last usable sector is 3915712
Partitions will be aligned on 4-sector boundaries
Total free space is 0 sectors (0 bytes)
Number Start (sector)End (sector) Size Code Name
235724403 416.0 KiB 0700 ISOHybrid1
3 446408 3915712 1.7 GiB 8300 Linux filesystem
Command (? for help): w
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!
Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT).
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
The operation has completed successfully.
$ /sbin/gdisk /dev/sdb
GPT fdisk (gdisk) version 0.8.1
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help): p
Disk /dev/sdb: 3915776 sectors, 1.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 2A2942FB-D14C-4710-A41F-DECF92DA20FE
Partition table holds up to 208 entries
First usable sector is 64, last usable sector is 3915712
Partitions will be aligned on 4-sector boundaries
Total free space is 0 sectors (0 bytes)
Number Start (sector)End (sector) Size Code Name
235724403 416.0 KiB 0700 ISOHybrid1
3 446408 3915712 1.7 GiB 8300 Linux filesystem
Command (? for help): q
--
The overwritten MBR might be needed for booting, if the firmware
does not boot via GPT.
In this case, use an MBR partition editor. In worst case one has
to kill the GPT first:
# Kill main GPT header block imported with the ISO image
$ dd if=/dev/zero bs=512 count=1 conv=notrunc seek=1 of=/dev/sdb
The backup GPT of the ISO will not be recognized as soon as the
main GPT is gone. But there may be an old backup GPT at the end
of the stick.
# Kill old backup GPT at the end of the stick (coarsely: 1900 MB to end)
$ dd if=/dev/zero bs=1M seek=1900 of=/dev/sdb
Now the stick should be recognized as MBR only.
(gdisk will spoil the MBR then. But fdisk should work.)
--
I see two non-standard aspects in the original GPT, caused by the
fact that debian-cd produces images rather than formatting disks,
and by the fact that isohybrid is quite a hack.
The partition editor must be able to adjust the GPT to a larger disk.
Further the GPT which get produced according to isohybrid
prescriptions bear partition 1 with an undigestible start block 0.
This is probably why GPT partition 1 does not show up in gdisk.
So
Bug#740504: cdimage.debian.org: Released ISO images have invalid GPT tables
On 8 April 2014 18:14, Steve McIntyre st...@einval.com wrote: Other folks: could you please test the output of the next daily builds and verify these work better for you? I still can't create a partition, which was the original aim. Is it supposed to work? If it is not possible to produce an image that can have a partition added, that should be mentioned in the Debian Manual (at the moment the manual suggests that the user create an extra partition on the image in order to add any required firmware files). # /dev/sdb is a USB drive I wrote the image to with dd # parted /dev/sdb GNU Parted 2.3 Using /dev/sdb Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p Error: The backup GPT table is not at the end of the disk, as it should be. This might mean that another operating system believes the disk is smaller. Fix, by moving the backup to the end (and removing the old backup)? Fix/Ignore/Cancel? Ignore Warning: Not all of the space available to /dev/sdb appears to be used, you can fix the GPT to use all of the space (an extra 14905344 blocks) or continue with the current setting? Fix/Ignore? Ignore Error: Unable to satisfy all constraints on the partition. (parted) # parted debian-testing-amd64-netinst.iso GNU Parted 2.3 Using /home/chrb/Downloads/debian-testing-amd64-netinst.iso Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Error: Unable to satisfy all constraints on the partition. (parted) # parted /dev/sdb GNU Parted 2.3 Using /dev/sdb Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p Error: The backup GPT table is not at the end of the disk, as it should be. This might mean that another operating system believes the disk is smaller. Fix, by moving the backup to the end (and removing the old backup)? Fix/Ignore/Cancel? Fix Warning: Not all of the space available to /dev/sdb appears to be used, you can fix the GPT to use all of the space (an extra 14905344 blocks) or continue with the current setting? Fix/Ignore? Fix Error: Unable to satisfy all constraints on the partition. (parted) p Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used. OK/Cancel? OK Warning: Not all of the space available to /dev/sdb appears to be used, you can fix the GPT to use all of the space (an extra 14905344 blocks) or continue with the current setting? Fix/Ignore? Fix Error: Unable to satisfy all constraints on the partition. (parted) # gparted debian-testing-amd64-netinst.iso [create partition table in gui] No partition table found on device debian-testing-amd64-netinst.iso A partition table is required before partitions can be added. To create a new partition table choose the menu item: Device -- Create Partition Table. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740504: cdimage.debian.org: Released ISO images have invalid GPT tables
Hi, the GPT header CRC of http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso looks ok now for me and for gdisk of oldstable (which formerly complained about amd64 ISOs). Now it says: GPT fdisk (gdisk) version 0.8.1 Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: present Found valid MBR and GPT. Which do you want to use? (I wonder why it does not recognize the APM in the ISO. Well, the combination of MBR, GPT, and APM is quite a dirty hack.) Today i got a report about younger fdisk and gdisk with GRUB2-style MBR and GPT. Both programs hate the ISO. I will have to find out what might be wrong there. ISOLINUX style and GRUB2 style differ: ISOLINUX wants nested mountable partitions. GRUB2 wants disjoint partitions. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740504: cdimage.debian.org: Released ISO images have invalid GPT tables
Hi, my newest bug about gdisk hating an ISO with GPT and MBR is not affecting debian-cd. (Further it is not GRUB2 specific.) I can reproduce the user's symptoms with gdisk 0.8.1 and can work around them by explicitely disabling multi-session emulation when producing the ISO. This disabling is default with mkisofs emulation. Today's debian-testing-amd64-netinst.iso shows no such symptoms and thus should be ok at least for gdisk. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740504: cdimage.debian.org: Released ISO images have invalid GPT tables
On Mon, Apr 07, 2014 at 03:55:44PM +0200, Thomas Schmitt wrote: Hi, the bug in question is supposed to have existed in upstream until 1.3.4? No. It was introduced by 1.2.4 and fixed by 1.3.0. So the version in Debian testing should be ok. It's just that xorriso-1.3.6.pl01 is the newest upstream release, which i would of course like to see in Debian testing. The bug seems not to hamper booting. But it keeps partition editors from recognizing the GPT. gdisk for example says: Found invalid GPT and valid MBR; converting MBR to GPT format. The bug is/was that the CRC number of the GPT header block was computed from all 512 bytes, rather than from the 92 bytes which actually bear information. The fix is tested since a year. At two occurences in libisofs/system_area.c, the number 512 needs to be replaced by 92: - crc = iso_crc32_gpt((unsigned char *) buf, 512, 0); + crc = iso_crc32_gpt((unsigned char *) buf, 92, 0); See http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/revision/1071/libisofs/system_area.c If Debian decides to e.g. fix xorriso-1.2.6 on the debian-cd production machine, then it would be helpful to also update the timestamp in xorriso/xorriso_timestamp.h to e.g. #define Xorriso_timestamP 2014.04.07.133000 in order to indicate the fixed program version in the Preprarer Id of the emerging ISO images. Done. Apologies for the delay in getting to this, I've been totally swamped with other stuff. New version of xorriso built and installed on pettersson (the CD build machine) with #define Xorriso_timestamP 2014.04.08.18 Please shout if you want me to change to another newer version, e.g. for the hppa changes that you've been talking about elsewhere. Other folks: could you please test the output of the next daily builds and verify these work better for you? -- Steve McIntyre, Cambridge, UK.st...@einval.com I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell. -- Linus Torvalds -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740504:
Correct me if I got this wrong, but the bug in question is supposed to have existed in upstream until 1.3.4? I built several ISOs of our Ubuntu Privacy Remix live project using upstream xorriso 1.3.0 and 1.3.1 So far I have not seen any UEFI test machine which failed booting from USB drive prepared with these ISOs. Just to be sure, I will do again with 1.3.6 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740504: cdimage.debian.org: Released ISO images have invalid GPT tables
Hi, the bug in question is supposed to have existed in upstream until 1.3.4? No. It was introduced by 1.2.4 and fixed by 1.3.0. So the version in Debian testing should be ok. It's just that xorriso-1.3.6.pl01 is the newest upstream release, which i would of course like to see in Debian testing. The bug seems not to hamper booting. But it keeps partition editors from recognizing the GPT. gdisk for example says: Found invalid GPT and valid MBR; converting MBR to GPT format. The bug is/was that the CRC number of the GPT header block was computed from all 512 bytes, rather than from the 92 bytes which actually bear information. The fix is tested since a year. At two occurences in libisofs/system_area.c, the number 512 needs to be replaced by 92: - crc = iso_crc32_gpt((unsigned char *) buf, 512, 0); + crc = iso_crc32_gpt((unsigned char *) buf, 92, 0); See http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/revision/1071/libisofs/system_area.c If Debian decides to e.g. fix xorriso-1.2.6 on the debian-cd production machine, then it would be helpful to also update the timestamp in xorriso/xorriso_timestamp.h to e.g. #define Xorriso_timestamP 2014.04.07.133000 in order to indicate the fixed program version in the Preprarer Id of the emerging ISO images. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740504:
I am also a bit curious to know how the information regarding which versions of software were used to create the .ISO . It seems this info. is embedded in the .iso generated but there doesn't seem to be any answers. Mount the iso image, the file /.disk/mkisofs has the exact xorriso command line used to generate the image. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740504:
Mount the iso image, the file /.disk/mkisofs has the exact xorriso command line used to generate the image. Apologies for the dupe info, I now see that Thomas already posted this detail. btw the Ubuntu images have the same issue - Launchpad bug https://bugs.launchpad.net/debian/+bug/1298912 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740504:
Hi, it is embarrassing to see the own bugs mummified since a full year. You should rather enjoy the fresh and juicy bugs of version 1.3.6.pl01. Funnily nobody complains that the wrong GPT header checksum would prevent booting from USB stick via EFI. Doesn't (U)EFI check ? Do all tested machines boot via the EFI partition entry in the MBR partition table ? The Debian amd64 ISO is full of hints and direction signs. The EFI boot image (a FAT filesystem) is even advertised by an Apple Partition Map entry as HFS+ partition. So one can hardly tell which route was taken by the firmware. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740504: Any update on having an upgraded xorriso so we don't have GPT failures ?
Hi, because debian-cd also records the arguments of its xorriso run, it should be not too hard to repack it with a newer xorriso, which produces better GPT. E.g. xorriso-1.3.2 from Debian Sid. You will need to copy the MBR from the original ISO dd if=debian-7.3.0-amd64-netinst.iso bs=512 count=1 \ of=my_old_debian.mbr and to mount it mount debian-7.3.0-amd64-netinst.iso /mnt The originally used arguments are stored in the ISO filesystem as file /.disk/mkisofs Omitting the Jigdo options, this would be for Debian 7.3 amd64: xorriso -as mkisofs \ -r -V 'Debian 7.3.0 amd64 1' \ -o my_new_debian.iso \ -J \ -isohybrid-mbr my_old_debian.mbr \ -joliet-long -cache-inodes \ -b isolinux/isolinux.bin \ -c isolinux/boot.cat \ -no-emul-boot -boot-load-size 4 -boot-info-table \ -eltorito-alt-boot \ -e boot/grub/efi.img -no-emul-boot -isohybrid-gpt-basdat \ -isohybrid-apm-hfsplus \ --sort-weight 2 isolinux/isolinux.bin \ --sort-weight 2 boot/grub/efi.img \ /mnt It is important to keep the original Volume Id, as told by xorriso -pvd_info, by mediainfo, or alike. This id is used to mount the ISO at boot time, afaik. I attributed --sort-weight to both boot images, in order to push them to low block addresses. Beginning with xorriso-1.3.4 this is done by default. (I am tempted to omit option -isohybrid-apm-hfsplus which is intended for marking HFS+ enhanced ISOs. But on the other hand: Who knows what an Apple Mac wants to see ?) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740504: Any update on having an upgraded xorriso so we don't have GPT failures ?
Hi all, Just saw this bug. I am supposed to get a few desktop machines which would have the newer GPT (GUID Partition Table) rather than MBR. I am also a bit curious to know how the information regarding which versions of software were used to create the .ISO . It seems this info. is embedded in the .iso generated but there doesn't seem to be any answers. At least according to the mail shared on the mailing list :- https://www.mail-archive.com/debian-cd@lists.debian.org/msg21403.html I did look at the FAQ about debian-CD but was unable to come up with any answers for the same. https://www.debian.org/CD/faq/ I have seen that sometimes the CD/DVD burning tool does give some info. I also looked at mediainfo for e.g. if it will give any more info. but didn't get anywhere. $ mediainfo debian-7.4.0-amd64-DVD-1.iso General Complete name: debian-7.4.0-amd64-DVD-1.iso Format : ISO 9660 File size: 3.68 GiB Looking forward to know more. -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com 065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740504: Any update on having an upgraded xorriso so we don't have GPT failures ?
Hi, I am also a bit curious to know how the information regarding which versions of software were used to create the .ISO . It seems this info. is embedded in the .iso generated xorriso by default writes its version info into the Preparer Id field of the ISO Primary Volume Descriptor (superblock). The text can be retrieved by xorriso -indev debian-7.3.0-amd64-netinst.iso -pvd_info \ 21 | grep '^Preparer Id' which yields Preparer Id : XORRISO-1.2.6 2013.01.08.103001, LIBISOBURN-1.2.6, LIBISOFS-1.2.6, LIBBURN-1.2.6 or (with some garbage around it) by dd if=debian-7.3.0-amd64-netinst.iso bs=2048 skip=16 count=1 \ | strings | fgrep XORRISO $ mediainfo debian-7.4.0-amd64-DVD-1.iso Program isoinfo would tell. isoinfo -i debian-7.3.0-amd64-netinst.iso -d yields among others Data preparer id: XORRISO-1.2.6 2013.01.08.103001, LIBISOBURN-1.2.6, LIBISOFS-1.2.6, LIBBURN-1.2.6 Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740504: cdimage.debian.org: Released ISO images have invalid GPT tables
Package: cdimage.debian.org Severity: important Dear Maintainer, The GPT checksum of debian-7.4.0-amd64-netinst.iso (and other wheezy and testing images) is incorrect due to a bug in the Xorriso build tool used on the build system (confirmed by author of build tool). Reported on mailing list but no response received: https://www.mail-archive.com/debian-cd@lists.debian.org/msg21403.html I am not sure what the impact of this is (hypothetically, some EFI systems could refuse to boot the ISO). It does mean that it is not possible to add extra partitions to the image (which the documentation states can be done for firmware files). Thomas Schmitt (author of xorriso) confirmed that: The problem described there affects versions 1.2.6 and 1.2.8. debian-7.3.0-amd64-netinst.iso indeed bears as preparer id XORRISO-1.2.6 2013.01.08.103001, LIBISOBURN-1.2.6, LIBISOFS-1.2.6, LIBBURN-1.2.6 It _should_ be fixed in xorriso-1.3.2 as in Debian testing and in the current upstream release 1.3.4. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
