Hi all,
I have 8G -CF cards that I have been putting linux on. Everything was working fine till yesterday when I got a new batch of CF cards.
The size has changed. The original CF card was 7637M (255 heads/63 sectors/928 cylinders) The new CF card is 8019M (255 heads/63 sectors/974 cylinders)
I would have thought putting the smaller image file onto the larger CF card would be ok. However its not. centos boots but there are journal issues and everything is mounted read-only.
Any ideas why this doesnt work or how I can keep my smaller image and "succecssfully" put it on the larger CF card?
I simply do "dd if=cf.img of=/dev/sde" to copy the images to CF.
Thanks,
Jerry
At Tue, 30 Nov 2010 09:46:03 -0500 CentOS mailing list centos@centos.org wrote:
Hi all,
I have 8G -CF cards that I have been putting linux on. Everything was working fine till yesterday when I got a new batch of CF cards.
The size has changed. The original CF card was 7637M (255 heads/63 sectors/928 cylinders) The new CF card is 8019M (255 heads/63 sectors/974 cylinders)
I would have thought putting the smaller image file onto the larger CF card would be ok. However its not. centos boots but there are journal issues and everything is mounted read-only.
Any ideas why this doesnt work or how I can keep my smaller image and "succecssfully" put it on the larger CF card?
I simply do "dd if=cf.img of=/dev/sde" to copy the images to CF.
ARG!!! Don't do this! You really, really don't want to dd a raw disk image (including mbr/partition table) to a *different* geometry disk -- it does not matter what the 'disk' tech is (IDE. SCSI, SATA, SSD, etc.).
Partition the new disk with fdisk (or something like that), then use mkfs to make the file systems than use dump/restore to move the file systems. Finally use grub-install (or lilo) to install the boot loader.
Thanks,
Jerry _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
The size has changed. The original CF card was 7637M (255 heads/63 sectors/928 cylinders) The new CF card is 8019M (255 heads/63 sectors/974 cylinders)
I simply do "dd if=cf.img of=/dev/sde" to copy the images to CF.
ARG!!! Don't do this! You really, really don't want to dd a raw disk image (including mbr/partition table) to a *different* geometry disk -- it does not matter what the 'disk' tech is (IDE. SCSI, SATA, SSD, etc.).
Even if the two disks have the same manufacturer and manufacturer part number, different firmware revisions can fail to boot after
dd if=/dev/spinpoint.partnumber.fwrev1 of=/dev/spinpoint.partnumber.fwrev2
Been there, done that, got bit where the sun doesn't shine.
Partition the new disk with fdisk (or something like that), then use mkfs to make the file systems than use dump/restore to move the file systems. Finally use grub-install (or lilo) to install the boot loader.
+1 sfdisk -d /dev/olddisk > /product/partition.layout dump (whatever)
...years later...
sfdisk /dev/newdisk < /product/partition.layout restore (whatever) grub-install (magic tbd) # SHIP IT ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
On 11/30/2010 12:10 PM, Brunner, Brian T. wrote:
The size has changed. The original CF card was 7637M (255 heads/63 sectors/928 cylinders) The new CF card is 8019M (255 heads/63 sectors/974 cylinders)
I simply do "dd if=cf.img of=/dev/sde" to copy the images to CF.
ARG!!! Don't do this! You really, really don't want to dd a raw disk image (including mbr/partition table) to a *different* geometry disk -- it does not matter what the 'disk' tech is (IDE. SCSI, SATA, SSD, etc.).
Even if the two disks have the same manufacturer and manufacturer part number, different firmware revisions can fail to boot after
dd if=/dev/spinpoint.partnumber.fwrev1 of=/dev/spinpoint.partnumber.fwrev2
Been there, done that, got bit where the sun doesn't shine.
Partition the new disk with fdisk (or something like that), then use mkfs to make the file systems than use dump/restore to move the file systems. Finally use grub-install (or lilo) to install the boot loader.
+1 sfdisk -d /dev/olddisk> /product/partition.layout dump (whatever)
...years later...
sfdisk /dev/newdisk< /product/partition.layout restore (whatever) grub-install (magic tbd) # SHIP IT
I'm not positive, but I'd expect clonezilla to get this right - and probably be able to expand the partition after the copy for you. Plus it will save time compared to dd by not needing to copy unused disk blocks and it can save a compressed image on a file server for repeated cloning.
-- Les Mikesell lesmikesesll@gmail.com
At Tue, 30 Nov 2010 12:26:04 -0600 CentOS mailing list centos@centos.org wrote:
On 11/30/2010 12:10 PM, Brunner, Brian T. wrote:
The size has changed. The original CF card was 7637M (255 heads/63 sectors/928 cylinders) The new CF card is 8019M (255 heads/63 sectors/974 cylinders)
I simply do "dd if=cf.img of=/dev/sde" to copy the images to CF.
ARG!!! Don't do this! You really, really don't want to dd a raw disk image (including mbr/partition table) to a *different* geometry disk -- it does not matter what the 'disk' tech is (IDE. SCSI, SATA, SSD, etc.).
Even if the two disks have the same manufacturer and manufacturer part number, different firmware revisions can fail to boot after
dd if=/dev/spinpoint.partnumber.fwrev1 of=/dev/spinpoint.partnumber.fwrev2
Been there, done that, got bit where the sun doesn't shine.
Partition the new disk with fdisk (or something like that), then use mkfs to make the file systems than use dump/restore to move the file systems. Finally use grub-install (or lilo) to install the boot loader.
+1 sfdisk -d /dev/olddisk> /product/partition.layout dump (whatever)
...years later...
sfdisk /dev/newdisk< /product/partition.layout restore (whatever) grub-install (magic tbd) # SHIP IT
I'm not positive, but I'd expect clonezilla to get this right - and probably be able to expand the partition after the copy for you. Plus it will save time compared to dd by not needing to copy unused disk blocks and it can save a compressed image on a file server for repeated cloning.
Right. clonezilla is much more than dd. I would suspect that clonezilla is a bundling of sfdisk, dump/restore, and grub-install, or something link that.
-- Les Mikesell lesmikesesll@gmail.com
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 11/30/2010 1:13 PM, Robert Heller wrote:
At Tue, 30 Nov 2010 12:26:04 -0600 CentOS mailing listcentos@centos.org wrote:
On 11/30/2010 12:10 PM, Brunner, Brian T. wrote:
The size has changed. The original CF card was 7637M (255 heads/63 sectors/928 cylinders) The new CF card is 8019M (255 heads/63 sectors/974 cylinders)
I simply do "dd if=cf.img of=/dev/sde" to copy the images to CF.
ARG!!! Don't do this! You really, really don't want to dd a raw disk image (including mbr/partition table) to a *different* geometry disk -- it does not matter what the 'disk' tech is (IDE. SCSI, SATA, SSD, etc.).
Even if the two disks have the same manufacturer and manufacturer part number, different firmware revisions can fail to boot after
dd if=/dev/spinpoint.partnumber.fwrev1 of=/dev/spinpoint.partnumber.fwrev2
Been there, done that, got bit where the sun doesn't shine.
Partition the new disk with fdisk (or something like that), then use mkfs to make the file systems than use dump/restore to move the file systems. Finally use grub-install (or lilo) to install the boot loader.
+1 sfdisk -d /dev/olddisk> /product/partition.layout dump (whatever)
...years later...
sfdisk /dev/newdisk< /product/partition.layout restore (whatever) grub-install (magic tbd) # SHIP IT
I'm not positive, but I'd expect clonezilla to get this right - and probably be able to expand the partition after the copy for you. Plus it will save time compared to dd by not needing to copy unused disk blocks and it can save a compressed image on a file server for repeated cloning.
Right. clonezilla is much more than dd. I would suspect that clonezilla is a bundling of sfdisk, dump/restore, and grub-install, or something link that.
Yes, dd is a worst-case fallback if it doesn't recognize the filesystem, and even then it would do each partition separately. Normally it would use partimage, partclone, or ntfsclone, automatically deciding which is best. I don't think it ever uses dump or tar, but it would be kind of nice is someone added those as a restore approach inside the wrapper that does the partitioning and setup for quick bare-metal restores from live backups.
On Tuesday, November 30, 2010 02:13:17 pm Robert Heller wrote:
Right. clonezilla is much more than dd. I would suspect that clonezilla is a bundling of sfdisk, dump/restore, and grub-install, or something link that.
According to the clonezilla website, dd is one of the supported methods: "Based on Partclone (default), Partimage (optional), ntfsclone (optional), or dd to image or clone a partition. However, Clonezilla, containing some other programs, can save and restore not only partitions, but also a whole disk. "
I have yet to have a dd clone go awry; not that it can't happen, but in years of doing this sort of thing, on multiple different Unix-type OS's (and real AT&T Unix) I have yet to have issues there.
But that reminds me that I need to get a newer clonezilla live anyway....
On Tuesday, November 30, 2010 01:10:14 pm Brunner, Brian T. wrote:
Even if the two disks have the same manufacturer and manufacturer part number, different firmware revisions can fail to boot after dd if=/dev/spinpoint.partnumber.fwrev1 of=/dev/spinpoint.partnumber.fwrev2
Been there, done that, got bit where the sun doesn't shine.
Care to share specifics? This would be interesting information.
On Tuesday, November 30, 2010 01:10:14 pm Brunner, Brian T. wrote:
Even if the two disks have the same manufacturer and manufacturer part number, different firmware revisions can fail to
boot after
dd if=/dev/spinpoint.partnumber.fwrev1
of=/dev/spinpoint.partnumber.fwrev2
Been there, done that, got bit where the sun doesn't shine.
Care to share specifics? This would be interesting information.
1: a few years back 2: we qualified Hitachi TravelStar lap-top drives (IIRC 20GB) and 3: tried to do our old method of copying a master to the multiple "programmed parts" using a disk duplicator machine (CDC Disk Duplicator, Pro Model) and found that 4: differing FW versions were incompatible (non-bootable), but the file system looked identical/perfect if the drives were mounted on a system that booted elsewhere (eg linux rescue).
We found out the two groups of drives had 1 of 2 different FW versions.
dd if=/dev/spinpoint.partnumber.fwrev1 of=/dev/spinpoint.partnumber.fwrev1 booted, dd if=/dev/spinpoint.partnumber.fwrev2 of=/dev/spinpoint.partnumber.fwrev2 booted; dd of fw1 to fw2, or of fw2 to fw1, did not boot.
We since shifted to another drive brand and size; IIRC the old one is no longer in production; www.pricewatch.com does not list the drive as I recall it. If closer details are /needed/ by anybody, I can go bother the techs to look them up. ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
On Tuesday, November 30, 2010 09:46:03 am Jerry Geis wrote:
However its not. centos boots but there are journal issues and everything is mounted read-only.
Can you get log snippets showing why the journal had issues?
Any ideas why this doesnt work or how I can keep my smaller image and "succecssfully" put it on the larger CF card?
I simply do "dd if=cf.img of=/dev/sde" to copy the images to CF.
I've done this before with regular disk drives (going from a 200G to a 500G SATA in this laptop I'm using right now; I used dd to copy, then I booted just fine. I then rebooted with a liveCD and did the partition moving/enlargement that I needed to do.
Geometry issues used to be bears, but in the days of LBA (and with SCSI drives) there really isn't a 'geometry' to speak of at the OS or partition level. The 'geometry' you quoted has the standard 255 heads and 63 sectors pseudo-geometry for both devices, and even in the days of real chs geometry issues those issues revolved around the number of heads and the number of sectors per track rather than the number of cylinders on the volume.
The dd way of copying to CF is pretty standard these days, and works almost all the time. But this is all speculation without seeing what is causing the filesystem to go read-only.
-
Brunner, Brian T. -
Jerry Geis -
Lamar Owen -
Les Mikesell -
Robert Heller