Fedora-14-Live-multi.iso is too large (5.2 gigabytes) for a normal DVD with capacity of 4.7 gigabytes or so. Aha! It must be intended for a USB flash drive with capacity of 8GB or greater...
[root@ryniker ryniker]# cmd/livecd-iso-to-disk --format --reset-mbr --overlay-size-mb 1024 --home-size-mb 1024 --unencrypted-home fedora/F14/Fedora-14-Live-multi.iso /dev/sdh1 Verifying image... /home/ryniker/fedora/F14/Fedora-14-Live-multi.iso: Could not get pvd data Unable to read the disc checksum from the primary volume descriptor. This probably means the disc was created without adding the checksum.Are you SURE you want to continue? Press Enter to continue or ctrl-c to abort
WARNING: THIS WILL DESTROY ANY DATA ON /dev/sdh!!! Press Enter to continue or ctrl-c to abort
Waiting for devices to settle... mkdosfs 3.0.1 (23 Nov 2008) ERROR: /home/ryniker/fedora/F14/Fedora-14-Live-multi.iso does not appear to be a Live image or DVD installer. Cleaning up to exit... [root@ryniker ryniker]#
Nope. (Leap-before-you-look strategy fails in this case.) What do we have here...
[root@ryniker ryniker]# mount -o loop,ro fedora/F14/Fedora-14-Live-multi.iso x [root@ryniker ryniker]# ls -l x total 8 drwxrwxr-x. 3 ryn ryn 2048 Oct 19 03:34 boot -r--r--r--. 1 ryn ryn 2048 Oct 19 04:37 boot.catalog drwxrwxr-x. 6 ryn ryn 2048 Oct 19 04:00 i686 drwxrwxr-x. 6 ryn ryn 2048 Oct 19 04:26 x86_64 [root@ryniker ryniker]# ls -l x/i686 total 8 dr-xr-xr-x. 5 root root 2048 Oct 13 03:31 Desktop dr-xr-xr-x. 5 root root 2048 Oct 13 03:46 KDE dr-xr-xr-x. 5 root root 2048 Oct 13 04:34 LXDE dr-xr-xr-x. 5 root root 2048 Oct 13 04:47 XFCE [root@ryniker ryniker]#
Data from file x/boot.catalog 0 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | | 10 00 00 00 00 00 00 00 00 00 00 00 00 AA 55 55 AA | UU | 20 88 00 00 00 00 00 04 00 47 00 00 00 00 00 00 00 | G | 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | | . . .
7E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | | 7F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | |
My guess is a work-in-progress, but also possible is I do not understand the actual objective and consequently have tried to misuse this data.
I thought the notion was to construct a single DVD that would boot in either i686 or x86_64 machines, then allow the user to select his preference from four appearance choices.
Jóhann, do you have more information, perhaps a reference to something that documents the goal of this mega-dvd effort?
Richard Ryniker wrote:
do you have more information, perhaps a reference to something that documents the goal of this mega-dvd effort?
You might find this thread[1], created two days ago, interesting.
[1] http://lists.fedoraproject.org/pipermail/test/2010-October/095021.html
On Thu, 2010-10-28 at 08:46 -0500, Michael Cronenworth wrote:
Richard Ryniker wrote:
do you have more information, perhaps a reference to something that documents the goal of this mega-dvd effort?
You might find this thread[1], created two days ago, interesting.
[1] http://lists.fedoraproject.org/pipermail/test/2010-October/095021.html
I've submitted an RFE to Bugzilla to have this new complex iso format supported by livecd-iso-to-disk. See BZ 648343. While few systems have optical drives that support dual-layer discs, most can now be booted from an 8GB USB thumb drive.
--Doc Savage Fairview Heights, IL
On Thu, 2010-10-28 at 08:32 -0400, Richard Ryniker wrote:
Fedora-14-Live-multi.iso is too large (5.2 gigabytes) for a normal DVD with capacity of 4.7 gigabytes or so. Aha! It must be intended for a USB flash drive with capacity of 8GB or greater...
[root@ryniker ryniker]# cmd/livecd-iso-to-disk --format --reset-mbr --overlay-size-mb 1024 --home-size-mb 1024 --unencrypted-home fedora/F14/Fedora-14-Live-multi.iso /dev/sdh1 Verifying image... /home/ryniker/fedora/F14/Fedora-14-Live-multi.iso: Could not get pvd data Unable to read the disc checksum from the primary volume descriptor. This probably means the disc was created without adding the checksum.Are you SURE you want to continue? Press Enter to continue or ctrl-c to abort
WARNING: THIS WILL DESTROY ANY DATA ON /dev/sdh!!! Press Enter to continue or ctrl-c to abort
Waiting for devices to settle... mkdosfs 3.0.1 (23 Nov 2008) ERROR: /home/ryniker/fedora/F14/Fedora-14-Live-multi.iso does not appear to be a Live image or DVD installer. Cleaning up to exit... [root@ryniker ryniker]#
[snip]
Richard,
I burned this oversized iso image to an 8.5GB DVD+R(DL) disc, then used it to successfully boot a 64-bit laptop with a BluRay drive. It displays a grub menu with (I think) sixteen separate entries.
Like you, I'm running into trouble with livecd-iso-to-disk. I'm seeing a couple of different problems:
# livecd-iso-to-disk --format --reset-mbr /home/doc/Downloads/Fedora-14-Live-multi.iso /dev/sdc Verifying image... /home/doc/Downloads/Fedora-14-Live-multi.iso: Could not get pvd data Unable to read the disc checksum from the primary volume descriptor. This probably means the disc was created without adding the checksum.Are you SURE you want to continue? Press Enter to continue or ctrl-c to abort
WARNING: THIS WILL DESTROY ANY DATA ON /dev/sdc!!! Press Enter to continue or ctrl-c to abort
Warning: The resulting partition is not properly aligned for best performance. Waiting for devices to settle... mkdosfs 3.0.9 (31 Jan 2010) mount: you must specify the filesystem type Cleaning up to exit... umount: /media/cdtmp.6Ci76u: not mounted
This is on a fully-updated 32-bit F13 system, attempting to write the image to an 8GB USB drive formatted to FAT-32.
--Doc Savage Fairview Heights, IL
On Sun, Oct 31, 2010 at 12:14:07AM -0500, Robert G. (Doc) Savage wrote:
Like you, I'm running into trouble with livecd-iso-to-disk. I'm seeing a couple of different problems:
Waiting for devices to settle... mkdosfs 3.0.9 (31 Jan 2010) mount: you must specify the filesystem type Cleaning up to exit... umount: /media/cdtmp.6Ci76u: not mounted
This is on a fully-updated 32-bit F13 system, attempting to write the image to an 8GB USB drive formatted to FAT-32.
Doesn't FAT32 have a 4 GB limit on file size?
On Sun, 2010-10-31 at 01:50 -0400, Scott Robbins wrote:
On Sun, Oct 31, 2010 at 12:14:07AM -0500, Robert G. (Doc) Savage wrote:
Like you, I'm running into trouble with livecd-iso-to-disk. I'm seeing a couple of different problems:
Waiting for devices to settle... mkdosfs 3.0.9 (31 Jan 2010) mount: you must specify the filesystem type Cleaning up to exit... umount: /media/cdtmp.6Ci76u: not mounted
This is on a fully-updated 32-bit F13 system, attempting to write the image to an 8GB USB drive formatted to FAT-32.
Doesn't FAT32 have a 4 GB limit on file size?
Scott,
It may, but that's moot. l-i-t-d does that formatting, and it's not a user option. l-i-t-d should also specify a filesystem type for mount, but it's not doing that right either.
--Doc Savage Fairview Heights, IL
On Sun, Oct 31, 2010 at 05:03:30 -0500, "Robert G. (Doc) Savage" dsavage@peaknet.net wrote:
It may, but that's moot. l-i-t-d does that formatting, and it's not a user option. l-i-t-d should also specify a filesystem type for mount, but it's not doing that right either.
Normally you don't need to specify a file system for a mount. Mount can detect what type it should be, and use the correct handler. When you get that message usually something is messed up with the filesystem.
On Sun, 2010-10-31 at 12:48 -0500, Bruno Wolff III wrote:
On Sun, Oct 31, 2010 at 05:03:30 -0500, "Robert G. (Doc) Savage" dsavage@peaknet.net wrote:
It may, but that's moot. l-i-t-d does that formatting, and it's not a user option. l-i-t-d should also specify a filesystem type for mount, but it's not doing that right either.
Normally you don't need to specify a file system for a mount. Mount can detect what type it should be, and use the correct handler. When you get that message usually something is messed up with the filesystem.
Bruno,
I think I found at least part of the problem here. The Downloads directory in my home folder is bind mounted to an NFS filesystem on an RHEL5 server. For some reason the iso file is being severely truncated by that NFS filesystem:
Here's the original file in a 1.1TB ext3 filesystem:
Red Hat Enterprise Linux Server release 5.5 (Tikanga) Sunday - October 31, 2010 17:16:56 CDT [doc@lion] /pub/fedora/linux/releases/14/Live $ ls -l total 5463812 -rw------- 1 doc doc 950 Oct 21 09:17 Fedora-14-Live-multi-CHECKSUM -rw------- 1 doc doc 5589458944 Oct 21 10:06 Fedora-14-Live-multi.iso drwxrwxr-x 2 doc doc 4096 Oct 26 20:02 i386 drwxrwxr-x 2 doc doc 4096 Oct 26 20:02 x86_64
Here's the NFS-exported version as seen on the F13 system, the one running l-i-t-d:
Fedora release 13 (Goddard) Sunday - October 31, 2010 16:55:17 CDT [doc@tiger] /net/lion/pub/fedora/linux/releases/14/Live $ ls -l total 5463812 -rw------- 1 doc doc 950 Oct 21 09:17 Fedora-14-Live-multi-CHECKSUM -rw------- 1 doc doc 1294491648 Oct 21 10:06 Fedora-14-Live-multi.iso drwxrwxr-x 2 doc doc 4096 Oct 26 20:02 i386 drwxrwxr-x 2 doc doc 4096 Oct 26 20:02 x86_64
Curiously, the difference in file sizes is precisely 4GB. Is this a bug, or normal behavior for NFS?
--Doc Savage Fairview Heights, IL
On Sun, Oct 31, 2010 at 16:33, Robert G. (Doc) Savage dsavage@peaknet.net wrote:
Bruno,
I think I found at least part of the problem here. The Downloads directory in my home folder is bind mounted to an NFS filesystem on an RHEL5 server. For some reason the iso file is being severely truncated by that NFS filesystem:
Here's the original file in a 1.1TB ext3 filesystem:
Red Hat Enterprise Linux Server release 5.5 (Tikanga) Sunday - October 31, 2010 17:16:56 CDT [doc@lion] /pub/fedora/linux/releases/14/Live $ ls -l total 5463812 -rw------- 1 doc doc 950 Oct 21 09:17 Fedora-14-Live-multi-CHECKSUM -rw------- 1 doc doc 5589458944 Oct 21 10:06 Fedora-14-Live-multi.iso drwxrwxr-x 2 doc doc 4096 Oct 26 20:02 i386 drwxrwxr-x 2 doc doc 4096 Oct 26 20:02 x86_64
Here's the NFS-exported version as seen on the F13 system, the one running l-i-t-d:
Fedora release 13 (Goddard) Sunday - October 31, 2010 16:55:17 CDT [doc@tiger] /net/lion/pub/fedora/linux/releases/14/Live $ ls -l total 5463812 -rw------- 1 doc doc 950 Oct 21 09:17 Fedora-14-Live-multi-CHECKSUM -rw------- 1 doc doc 1294491648 Oct 21 10:06 Fedora-14-Live-multi.iso drwxrwxr-x 2 doc doc 4096 Oct 26 20:02 i386 drwxrwxr-x 2 doc doc 4096 Oct 26 20:02 x86_64
Curiously, the difference in file sizes is precisely 4GB. Is this a bug, or normal behavior for NFS?
Possibly a bug, depends on if the RHEL server is 64 bit or not, and you are using NFSv3 (and in TCP). It supposedly works in UDP but I have had problems myself with large files like that.
--Doc Savage Fairview Heights, IL
On Sun, 2010-10-31 at 19:03 -0600, Stephen John Smoogen wrote:
On Sun, Oct 31, 2010 at 16:33, Robert G. (Doc) Savage dsavage@peaknet.net wrote:
Bruno,
I think I found at least part of the problem here. The Downloads directory in my home folder is bind mounted to an NFS filesystem on an RHEL5 server. For some reason the iso file is being severely truncated by that NFS filesystem:
Here's the original file in a 1.1TB ext3 filesystem:
Red Hat Enterprise Linux Server release 5.5 (Tikanga) Sunday - October 31, 2010 17:16:56 CDT [doc@lion] /pub/fedora/linux/releases/14/Live $ ls -l total 5463812 -rw------- 1 doc doc 950 Oct 21 09:17 Fedora-14-Live-multi-CHECKSUM -rw------- 1 doc doc 5589458944 Oct 21 10:06 Fedora-14-Live-multi.iso drwxrwxr-x 2 doc doc 4096 Oct 26 20:02 i386 drwxrwxr-x 2 doc doc 4096 Oct 26 20:02 x86_64Here's the NFS-exported version as seen on the F13 system, the one running l-i-t-d:
Fedora release 13 (Goddard) Sunday - October 31, 2010 16:55:17 CDT [doc@tiger] /net/lion/pub/fedora/linux/releases/14/Live $ ls -l total 5463812 -rw------- 1 doc doc 950 Oct 21 09:17 Fedora-14-Live-multi-CHECKSUM -rw------- 1 doc doc 1294491648 Oct 21 10:06 Fedora-14-Live-multi.iso drwxrwxr-x 2 doc doc 4096 Oct 26 20:02 i386 drwxrwxr-x 2 doc doc 4096 Oct 26 20:02 x86_64Curiously, the difference in file sizes is precisely 4GB. Is this a bug, or normal behavior for NFS?
Possibly a bug, depends on if the RHEL server is 64 bit or not, and you are using NFSv3 (and in TCP). It supposedly works in UDP but I have had problems myself with large files like that.
Stephen,
64-bit NFSv3 on the RHEL5 server. Using 64-bit NFSv4 and autofs on the F13 side. The latter makes things easy, but completely obscures my ability to troubleshoot. ("You don't need to know those things...")
--Doc Savage Fairview Heights, IL
I used an early F14 version of livecd-iso-to-disk, which may explain some different behavior. There is one significant difference in how the script is invoked: in the F13 version, the device argument can (must?) be the base device, such as the /dev/sdc you used where you likely have a /dev/sdc1 partition allocated for a VFAT filesystem; in the F14 version of livecd-iso-to-disk, the device argument must be the explicit designation for the partition to use, as /dev/sdh1 in my case.
This seems a useful change, because one might have several partitions for diverse purposes, especially with the larger flash drives that are presently available.
We probably should use the latest-and-greatest livecd-iso-to-disk script from git in order to avoid stumbles over issues already fixed.
http://git.fedorahosted.org/git/?p=livecd
I gather some recent activity has addressed issues with ext (instead of FAT) partitions; that is something I should like to try again.
I think there remains some question about whether livecd-iso-to-disk is even intended to write this mega-DVD to a USB flash drive. It would be nice to know this is supposed to work before we spend much effort to try it.
On Sun, Oct 31, 2010 at 14:16:28 -0400, Richard Ryniker ryniker@alum.mit.edu wrote:
I used an early F14 version of livecd-iso-to-disk, which may explain some different behavior. There is one significant difference in how the script is invoked: in the F13 version, the device argument can (must?) be the base device, such as the /dev/sdc you used where you likely have a /dev/sdc1 partition allocated for a VFAT filesystem; in the F14 version of livecd-iso-to-disk, the device argument must be the explicit designation for the partition to use, as /dev/sdh1 in my case.
Both methods are supposed to work. They format the device differently. When no partition name is used the device is supposed to look like a giant floppy.
-
Bruno Wolff III -
Michael Cronenworth -
Richard Ryniker -
Robert G. (Doc) Savage -
Scott Robbins -
Stephen John Smoogen