This is a Fedora arm problem, but probably more experience with dd and sd cards here...
SO I boot my Cubieboard2 from microSD. I grabbed 8 16GB cards from the bin at the MicroCenter checkout counter. They work fine for building F21 arm boots, but I am getting far enough into the process that if I do something wrong, I don't want to go all the way back to the beginning. I rather clone the card, play around, and soforth. So I tried using:
sudo dd if=/dev/sdb of=/dev/sdc bs=4096 conv=notrunc,noerror; sync
the target sd card has been previously use. The copy fails in use as follows:
Mounting Configuration File System... [ OK ] Mounted Configuration File System. [ OK ] Found device /dev/disk/by-uuid/1dc878de-92d2-4a66-b352-f055a32473b9. [ OK ] Started dracut initqueue hook. [ OK ] Started Show Plymouth Boot Screen. [ OK ] Reached target Paths. [ OK ] Reached target Basic System. Starting dracut pre-mount hook... [ OK ] Reached target Remote File Systems (Pre). [ OK ] Reached target Remote File Systems. Starting File System Check on /dev/disk/by-uuid/1dc8...f055a32473b9... [ 13.911063] systemd-fsck[368]: _/: The filesystem size (according to the superblock) is 3587707 blocks [ OK ] Started dracut pre-mount hook. [ 13.919598] systemd-fsck[368]: The physical size of the device is 3548795 blocks [ 13.937109] systemd-fsck[368]: Either the superblock or the partition table is likely to be corrupt! [ 13.944962] systemd-fsck[368]: _/: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. [ 13.950853] systemd-fsck[368]: (i.e., without -a or -p options) [ OK ] Started File System Check on /dev/disk/by-uuid/1dc87...2-f055a32473b9. Mounting /sysroot... [ 14.483857] random: nonblocking pool is initialized [ 14.571964] EXT4-fs (mmcblk0p3): bad geometry: block count 3587707 exceeds size of device (3548795 blocks) [FAILED] Failed to mount /sysroot. See 'systemctl status sysroot.mount' for details. [DEPEND] Dependency failed for Initrd Root File System. [DEPEND] Dependency failed for Reload Configuration from the Real Root. [ OK ] Stopped dracut pre-pivot and cleanup hook. [ OK ] Stopped target Initrd Default Target. [ OK ] Stopped dracut mount hook. [ OK ] Reached target Initrd File Systems. [ OK ] Stopped target Basic System. [ OK ] Stopped target System Initialization. Starting Emergency Shel Generating "/run/initramfs/rdsosreport.txt"
Entering emergency mode. Exit the shell to continue. Type "journalctl" to view system logs. You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot after mounting them and attach it to a bug report.
:/#
=======================================================
I put the card back in my build system and looked at it with Gparted which shows the whole drive as unallocated, even though the system successfully mounted /boot (but not /).
So the question is: HOw better can I clone the card? SDFormatter in Windows is one suggestion, but I don't want to have to jump over to the family XP system.
thanks
Install liveusb-creator-3.12.0-1.fc20.noarch.rpm
and create a launch icon for it on the desktop (if you like) and launch it from there. It will prompt you for the source of the ISO file and will ask you for the destination, if there is more than one usb drive target.
I have used it without fail !!!
On Tue, Aug 5, 2014 at 9:44 PM, Robert Moskowitz rgm@htt-consult.com wrote:
This is a Fedora arm problem, but probably more experience with dd and sd cards here...
SO I boot my Cubieboard2 from microSD. I grabbed 8 16GB cards from the bin at the MicroCenter checkout counter. They work fine for building F21 arm boots, but I am getting far enough into the process that if I do something wrong, I don't want to go all the way back to the beginning. I rather clone the card, play around, and soforth. So I tried using:
sudo dd if=/dev/sdb of=/dev/sdc bs=4096 conv=notrunc,noerror; sync
the target sd card has been previously use. The copy fails in use as follows:
Mounting Configuration File System...[ OK ] Mounted Configuration File System. [ OK ] Found device /dev/disk/by-uuid/1dc878de-92d2-4a66-b352-f055a32473b9. [ OK ] Started dracut initqueue hook. [ OK ] Started Show Plymouth Boot Screen. [ OK ] Reached target Paths. [ OK ] Reached target Basic System. Starting dracut pre-mount hook... [ OK ] Reached target Remote File Systems (Pre). [ OK ] Reached target Remote File Systems. Starting File System Check on /dev/disk/by-uuid/1dc8...f055a32473b9... [ 13.911063] systemd-fsck[368]: _/: The filesystem size (according to the superblock) is 3587707 blocks [ OK ] Started dracut pre-mount hook. [ 13.919598] systemd-fsck[368]: The physical size of the device is 3548795 blocks [ 13.937109] systemd-fsck[368]: Either the superblock or the partition table is likely to be corrupt! [ 13.944962] systemd-fsck[368]: _/: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. [ 13.950853] systemd-fsck[368]: (i.e., without -a or -p options) [ OK ] Started File System Check on /dev/disk/by-uuid/1dc87...2-f055a32473b9. Mounting /sysroot... [ 14.483857] random: nonblocking pool is initialized [ 14.571964] EXT4-fs (mmcblk0p3): bad geometry: block count 3587707 exceeds size of device (3548795 blocks) [FAILED] Failed to mount /sysroot. See 'systemctl status sysroot.mount' for details. [DEPEND] Dependency failed for Initrd Root File System. [DEPEND] Dependency failed for Reload Configuration from the Real Root. [ OK ] Stopped dracut pre-pivot and cleanup hook. [ OK ] Stopped target Initrd Default Target. [ OK ] Stopped dracut mount hook. [ OK ] Reached target Initrd File Systems. [ OK ] Stopped target Basic System. [ OK ] Stopped target System Initialization. Starting Emergency Shel Generating "/run/initramfs/rdsosreport.txt"
Entering emergency mode. Exit the shell to continue. Type "journalctl" to view system logs. You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot after mounting them and attach it to a bug report.
:/#
=======================================================
I put the card back in my build system and looked at it with Gparted which shows the whole drive as unallocated, even though the system successfully mounted /boot (but not /).
So the question is: HOw better can I clone the card? SDFormatter in Windows is one suggestion, but I don't want to have to jump over to the family XP system.
thanks
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On 08/05/2014 11:50 PM, JD wrote:
Install liveusb-creator-3.12.0-1.fc20.noarch.rpm
and create a launch icon for it on the desktop (if you like) and launch it from there. It will prompt you for the source of the ISO file and will ask you for the destination, if there is more than one usb drive target.
I have used it without fail !!!
Great, but I do not have an ISO file. I laboriously built the card starting with a xzcat through configuring stuff after the 1st boot. So I guess the first step is how to make an ISO of the existing drive...
On Tue, Aug 5, 2014 at 9:44 PM, Robert Moskowitz rgm@htt-consult.com wrote:
This is a Fedora arm problem, but probably more experience with dd and sd cards here...
SO I boot my Cubieboard2 from microSD. I grabbed 8 16GB cards from the bin at the MicroCenter checkout counter. They work fine for building F21 arm boots, but I am getting far enough into the process that if I do something wrong, I don't want to go all the way back to the beginning. I rather clone the card, play around, and soforth. So I tried using:
sudo dd if=/dev/sdb of=/dev/sdc bs=4096 conv=notrunc,noerror; sync
the target sd card has been previously use. The copy fails in use as follows:
Mounting Configuration File System...[ OK ] Mounted Configuration File System. [ OK ] Found device /dev/disk/by-uuid/1dc878de-92d2-4a66-b352-f055a32473b9. [ OK ] Started dracut initqueue hook. [ OK ] Started Show Plymouth Boot Screen. [ OK ] Reached target Paths. [ OK ] Reached target Basic System. Starting dracut pre-mount hook... [ OK ] Reached target Remote File Systems (Pre). [ OK ] Reached target Remote File Systems. Starting File System Check on /dev/disk/by-uuid/1dc8...f055a32473b9... [ 13.911063] systemd-fsck[368]: _/: The filesystem size (according to the superblock) is 3587707 blocks [ OK ] Started dracut pre-mount hook. [ 13.919598] systemd-fsck[368]: The physical size of the device is 3548795 blocks [ 13.937109] systemd-fsck[368]: Either the superblock or the partition table is likely to be corrupt! [ 13.944962] systemd-fsck[368]: _/: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. [ 13.950853] systemd-fsck[368]: (i.e., without -a or -p options) [ OK ] Started File System Check on /dev/disk/by-uuid/1dc87...2-f055a32473b9. Mounting /sysroot... [ 14.483857] random: nonblocking pool is initialized [ 14.571964] EXT4-fs (mmcblk0p3): bad geometry: block count 3587707 exceeds size of device (3548795 blocks) [FAILED] Failed to mount /sysroot. See 'systemctl status sysroot.mount' for details. [DEPEND] Dependency failed for Initrd Root File System. [DEPEND] Dependency failed for Reload Configuration from the Real Root. [ OK ] Stopped dracut pre-pivot and cleanup hook. [ OK ] Stopped target Initrd Default Target. [ OK ] Stopped dracut mount hook. [ OK ] Reached target Initrd File Systems. [ OK ] Stopped target Basic System. [ OK ] Stopped target System Initialization. Starting Emergency Shel Generating "/run/initramfs/rdsosreport.txt"
Entering emergency mode. Exit the shell to continue. Type "journalctl" to view system logs. You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot after mounting them and attach it to a bug report.
:/#
=======================================================
I put the card back in my build system and looked at it with Gparted which shows the whole drive as unallocated, even though the system successfully mounted /boot (but not /).
So the question is: HOw better can I clone the card? SDFormatter in Windows is one suggestion, but I don't want to have to jump over to the family XP system.
thanks
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On Tue, Aug 5, 2014 at 10:14 PM, Robert Moskowitz rgm@htt-consult.com wrote:
On 08/05/2014 11:50 PM, JD wrote:
Install liveusb-creator-3.12.0-1.fc20.noarch.rpm
and create a launch icon for it on the desktop (if you like) and launch it from there. It will prompt you for the source of the ISO file and will ask you for the destination, if there is more than one usb drive target.
I have used it without fail !!!
Great, but I do not have an ISO file. I laboriously built the card starting with a xzcat through configuring stuff after the 1st boot. So I guess the first step is how to make an ISO of the existing drive...
Fine. Visit
http://mirrors.kernel.org/fedora/releases/20/Images/armhfp/
and download the compressed image you prefer, and when liveusb asks you for the file, point it to the one you downloaded. Since I do not have ARM, I have never used these images.
Good luck.
On 08/06/2014 12:26 AM, JD wrote:
On Tue, Aug 5, 2014 at 10:14 PM, Robert Moskowitz rgm@htt-consult.com wrote:
On 08/05/2014 11:50 PM, JD wrote:
Install liveusb-creator-3.12.0-1.fc20.noarch.rpm
and create a launch icon for it on the desktop (if you like) and launch it from there. It will prompt you for the source of the ISO file and will ask you for the destination, if there is more than one usb drive target.
I have used it without fail !!!
Great, but I do not have an ISO file. I laboriously built the card starting with a xzcat through configuring stuff after the 1st boot. So I guess the first step is how to make an ISO of the existing drive...
Fine. Visit
http://mirrors.kernel.org/fedora/releases/20/Images/armhfp/
and download the compressed image you prefer, and when liveusb asks you for the file, point it to the one you downloaded. Since I do not have ARM, I have never used these images.
You are missing a key point here. I already downloaded the F21 image from
http://koji.fedoraproject.org/koji/tasks?state=all&view=tree&method=...
I then build the first SD. Do first boot, get through the 'things that work'. NOW I want to clone the card so I can test the things that I have not figured out yet and can easily go back to a clean point with out going all the way back to the downloaded image and all the steps involved to get to my 'clean point'.
So I have a working SD that has LOTS of changes from the image. This is what I want to clone.
Hi,
In my case, most of the time for ARM images I use as root(be careful!):
more /dev/sdb > /dev/sdc # I use sdb as source and sdc as destination sync
It makes an exact copy and you don't have to care about options.
Best regards, Alexis.
Le 06/08/2014 05:44, Robert Moskowitz a écrit :
This is a Fedora arm problem, but probably more experience with dd and sd cards here...
SO I boot my Cubieboard2 from microSD. I grabbed 8 16GB cards from the bin at the MicroCenter checkout counter. They work fine for building F21 arm boots, but I am getting far enough into the process that if I do something wrong, I don't want to go all the way back to the beginning. I rather clone the card, play around, and soforth. So I tried using:
sudo dd if=/dev/sdb of=/dev/sdc bs=4096 conv=notrunc,noerror; sync
the target sd card has been previously use. The copy fails in use as follows:
Mounting Configuration File System...[ OK ] Mounted Configuration File System. [ OK ] Found device /dev/disk/by-uuid/1dc878de-92d2-4a66-b352-f055a32473b9. [ OK ] Started dracut initqueue hook. [ OK ] Started Show Plymouth Boot Screen. [ OK ] Reached target Paths. [ OK ] Reached target Basic System. Starting dracut pre-mount hook... [ OK ] Reached target Remote File Systems (Pre). [ OK ] Reached target Remote File Systems. Starting File System Check on /dev/disk/by-uuid/1dc8...f055a32473b9... [ 13.911063] systemd-fsck[368]: _/: The filesystem size (according to the superblock) is 3587707 blocks [ OK ] Started dracut pre-mount hook. [ 13.919598] systemd-fsck[368]: The physical size of the device is 3548795 blocks [ 13.937109] systemd-fsck[368]: Either the superblock or the partition table is likely to be corrupt! [ 13.944962] systemd-fsck[368]: _/: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. [ 13.950853] systemd-fsck[368]: (i.e., without -a or -p options) [ OK ] Started File System Check on /dev/disk/by-uuid/1dc87...2-f055a32473b9. Mounting /sysroot... [ 14.483857] random: nonblocking pool is initialized [ 14.571964] EXT4-fs (mmcblk0p3): bad geometry: block count 3587707 exceeds size of device (3548795 blocks) [FAILED] Failed to mount /sysroot. See 'systemctl status sysroot.mount' for details. [DEPEND] Dependency failed for Initrd Root File System. [DEPEND] Dependency failed for Reload Configuration from the Real Root. [ OK ] Stopped dracut pre-pivot and cleanup hook. [ OK ] Stopped target Initrd Default Target. [ OK ] Stopped dracut mount hook. [ OK ] Reached target Initrd File Systems. [ OK ] Stopped target Basic System. [ OK ] Stopped target System Initialization. Starting Emergency Shel Generating "/run/initramfs/rdsosreport.txt"
Entering emergency mode. Exit the shell to continue. Type "journalctl" to view system logs. You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot after mounting them and attach it to a bug report.
:/#
=======================================================
I put the card back in my build system and looked at it with Gparted which shows the whole drive as unallocated, even though the system successfully mounted /boot (but not /).
So the question is: HOw better can I clone the card? SDFormatter in Windows is one suggestion, but I don't want to have to jump over to the family XP system.
thanks
On 08/06/2014 04:26 AM, Alexis Jeandet wrote:
Hi,
In my case, most of the time for ARM images I use as root(be careful!):
more /dev/sdb > /dev/sdc # I use sdb as source and sdc as destination sync
It makes an exact copy and you don't have to care about options.
I am assuming that I unmount the drives first.
On 08/06/2014 04:26 AM, Alexis Jeandet wrote:
Hi,
In my case, most of the time for ARM images I use as root(be careful!):
more /dev/sdb > /dev/sdc # I use sdb as source and sdc as destination sync
It makes an exact copy and you don't have to care about options.
Using fdisk and parted, I can see my problem, and this won't work. The target card IS smaller than the source. But I can 'fix' that if there is a partition resize command where I can specify the end block in the resize. No reason I cannot shrink sdb3 to what will fit on the target card.
Best regards, Alexis.
Le 06/08/2014 05:44, Robert Moskowitz a écrit :
This is a Fedora arm problem, but probably more experience with dd and sd cards here...
SO I boot my Cubieboard2 from microSD. I grabbed 8 16GB cards from the bin at the MicroCenter checkout counter. They work fine for building F21 arm boots, but I am getting far enough into the process that if I do something wrong, I don't want to go all the way back to the beginning. I rather clone the card, play around, and soforth. So I tried using:
sudo dd if=/dev/sdb of=/dev/sdc bs=4096 conv=notrunc,noerror; sync
the target sd card has been previously use. The copy fails in use as follows:
Mounting Configuration File System...[ OK ] Mounted Configuration File System. [ OK ] Found device /dev/disk/by-uuid/1dc878de-92d2-4a66-b352-f055a32473b9. [ OK ] Started dracut initqueue hook. [ OK ] Started Show Plymouth Boot Screen. [ OK ] Reached target Paths. [ OK ] Reached target Basic System. Starting dracut pre-mount hook... [ OK ] Reached target Remote File Systems (Pre). [ OK ] Reached target Remote File Systems. Starting File System Check on /dev/disk/by-uuid/1dc8...f055a32473b9... [ 13.911063] systemd-fsck[368]: _/: The filesystem size (according to the superblock) is 3587707 blocks [ OK ] Started dracut pre-mount hook. [ 13.919598] systemd-fsck[368]: The physical size of the device is 3548795 blocks [ 13.937109] systemd-fsck[368]: Either the superblock or the partition table is likely to be corrupt! [ 13.944962] systemd-fsck[368]: _/: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. [ 13.950853] systemd-fsck[368]: (i.e., without -a or -p options) [ OK ] Started File System Check on /dev/disk/by-uuid/1dc87...2-f055a32473b9. Mounting /sysroot... [ 14.483857] random: nonblocking pool is initialized [ 14.571964] EXT4-fs (mmcblk0p3): bad geometry: block count 3587707 exceeds size of device (3548795 blocks) [FAILED] Failed to mount /sysroot. See 'systemctl status sysroot.mount' for details. [DEPEND] Dependency failed for Initrd Root File System. [DEPEND] Dependency failed for Reload Configuration from the Real Root. [ OK ] Stopped dracut pre-pivot and cleanup hook. [ OK ] Stopped target Initrd Default Target. [ OK ] Stopped dracut mount hook. [ OK ] Reached target Initrd File Systems. [ OK ] Stopped target Basic System. [ OK ] Stopped target System Initialization. Starting Emergency Shel Generating "/run/initramfs/rdsosreport.txt"
Entering emergency mode. Exit the shell to continue. Type "journalctl" to view system logs. You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot after mounting them and attach it to a bug report.
:/#
=======================================================
I put the card back in my build system and looked at it with Gparted which shows the whole drive as unallocated, even though the system successfully mounted /boot (but not /).
So the question is: HOw better can I clone the card? SDFormatter in Windows is one suggestion, but I don't want to have to jump over to the family XP system.
thanks
Allegedly, on or about 06 August 2014, Robert Moskowitz sent:
Using fdisk and parted, I can see my problem, and this won't work. The target card IS smaller than the source. But I can 'fix' that if there is a partition resize command where I can specify the end block in the resize. No reason I cannot shrink sdb3 to what will fit on the target card.
Just wondering about a simplistic solution: Partition the card, the original one, so that you don't use the whole card, by default. Then, when you clone the working partition of your template card, it's always going to be a bit smaller than your target copies.
On 08/06/2014 09:36 PM, Tim wrote:
Allegedly, on or about 06 August 2014, Robert Moskowitz sent:
Using fdisk and parted, I can see my problem, and this won't work. The target card IS smaller than the source. But I can 'fix' that if there is a partition resize command where I can specify the end block in the resize. No reason I cannot shrink sdb3 to what will fit on the target card.
Just wondering about a simplistic solution: Partition the card, the original one, so that you don't use the whole card, by default. Then, when you clone the working partition of your template card, it's always going to be a bit smaller than your target copies.
that is where I am heading. For this stage of testing, I really don't need no 14Gb for storage.
I have learned a bit during this.
On Tue, 2014-08-05 at 23:44 -0400, Robert Moskowitz wrote:
Starting File System Check on/dev/disk/by-uuid/1dc8...f055a32473b9... [ 13.911063] systemd-fsck[368]: _/: The filesystem size (according to the superblock) is 3587707 blocks [ OK ] Started dracut pre-mount hook. [ 13.919598] systemd-fsck[368]: The physical size of the device is 3548795 blocks [ 13.937109] systemd-fsck[368]: Either the superblock or the partition table is likely to be corrupt! [ 13.944962] systemd-fsck[368]: _/: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
are the cards exactly the same size? It looks as if the card you copiued to is smaller than the one you copied from... What does fdisk -l report for disk size for the "old" and "new" cards? /Louis
On 08/06/2014 05:26 AM, Louis Lagendijk wrote:
On Tue, 2014-08-05 at 23:44 -0400, Robert Moskowitz wrote:
Starting File System Check on/dev/disk/by-uuid/1dc8...f055a32473b9... [ 13.911063] systemd-fsck[368]: _/: The filesystem size (according to the superblock) is 3587707 blocks [ OK ] Started dracut pre-mount hook. [ 13.919598] systemd-fsck[368]: The physical size of the device is 3548795 blocks [ 13.937109] systemd-fsck[368]: Either the superblock or the partition table is likely to be corrupt! [ 13.944962] systemd-fsck[368]: _/: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
are the cards exactly the same size? It looks as if the card you copiued to is smaller than the one you copied from... What does fdisk -l report for disk size for the "old" and "new" cards?
IT DOES look like that. I will try the fdisk. I suspect that although they are marketed as 16GB, they vary due to manufacturing quality by a block or so.
Robert Moskowitz rgm@htt-consult.com writes:
I suspect that although they are marketed as 16GB, they vary due to manufacturing quality by a block or so.
The other thing to consider if it is a bargain bin drive is that the drive might be a counterfeit with mismarked capacity. http://www.ebay.com/gds/All-About-Fake-Flash-Drives-2013-/10000000177553258/...
-wolfgang
On 08/06/2014 09:58 AM, Wolfgang S. Rupprecht wrote:
Robert Moskowitz rgm@htt-consult.com writes:
I suspect that although they are marketed as 16GB, they vary due to manufacturing quality by a block or so.
The other thing to consider if it is a bargain bin drive is that the drive might be a counterfeit with mismarked capacity. http://www.ebay.com/gds/All-About-Fake-Flash-Drives-2013-/10000000177553258/...
These are not sold under any name. They are 'blank' packaged.
So I figured that whatever that whatever is 'wrong' with them in perhaps malware, would get blown away by Linux. I once DID buy a usb drive from an online store that had a hidden partition with some strange looking stuff....
Robert Moskowitz rgm@htt-consult.com writes:
On 08/06/2014 09:58 AM, Wolfgang S. Rupprecht wrote:
Robert Moskowitz rgm@htt-consult.com writes:
I suspect that although they are marketed as 16GB, they vary due to manufacturing quality by a block or so.
The other thing to consider if it is a bargain bin drive is that the drive might be a counterfeit with mismarked capacity. http://www.ebay.com/gds/All-About-Fake-Flash-Drives-2013-/10000000177553258/...
These are not sold under any name. They are 'blank' packaged.
So I figured that whatever that whatever is 'wrong' with them in perhaps malware, would get blown away by Linux. I once DID buy a usb drive from an online store that had a hidden partition with some strange looking stuff....
The above URL uses counterfeit to mean drives are sold as large capacity drives that really don't have large flash chips inside. The upstream sellers buy small drives and reprogram the controllers to advertise a larger size that the drive really can't deliver.
-wolfgang
On 08/06/2014 03:55 PM, Wolfgang S. Rupprecht wrote:
Robert Moskowitz rgm@htt-consult.com writes:
On 08/06/2014 09:58 AM, Wolfgang S. Rupprecht wrote:
Robert Moskowitz rgm@htt-consult.com writes:
I suspect that although they are marketed as 16GB, they vary due to manufacturing quality by a block or so.
The other thing to consider if it is a bargain bin drive is that the drive might be a counterfeit with mismarked capacity. http://www.ebay.com/gds/All-About-Fake-Flash-Drives-2013-/10000000177553258/...
These are not sold under any name. They are 'blank' packaged.
So I figured that whatever that whatever is 'wrong' with them in perhaps malware, would get blown away by Linux. I once DID buy a usb drive from an online store that had a hidden partition with some strange looking stuff....
The above URL uses counterfeit to mean drives are sold as large capacity drives that really don't have large flash chips inside. The upstream sellers buy small drives and reprogram the controllers to advertise a larger size that the drive really can't deliver.
Well these are marketed as 16Gb. parted is showing one to be 15.6Gb. And I have put over 8Gb on a couple of them. I think if MicroCenter was seriously mismarketing them, their customers would be complaining in droves. Being off by .4Gb would not be noticed and as in my cases tossed off as low quality that needed to mark parts of it as not to be used and thus the smaller size.
# parted /dev/sdb print Model: Generic- Multi-Card (scsi) Disk /dev/sdb: 15.6GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags:
Number Start End Size Type File system Flags 1 1000kB 513MB 512MB primary ext3 2 513MB 1025MB 512MB primary linux-swap(v1) 3 1025MB 15.6GB 14.5GB primary ext4
Robert Moskowitz rgm@htt-consult.com writes:
On 08/06/2014 03:55 PM, Wolfgang S. Rupprecht wrote:
Robert Moskowitz rgm@htt-consult.com writes:
On 08/06/2014 09:58 AM, Wolfgang S. Rupprecht wrote:
Robert Moskowitz rgm@htt-consult.com writes:
I suspect that although they are marketed as 16GB, they vary due to manufacturing quality by a block or so.
The other thing to consider if it is a bargain bin drive is that the drive might be a counterfeit with mismarked capacity. http://www.ebay.com/gds/All-About-Fake-Flash-Drives-2013-/10000000177553258/...
These are not sold under any name. They are 'blank' packaged.
So I figured that whatever that whatever is 'wrong' with them in perhaps malware, would get blown away by Linux. I once DID buy a usb drive from an online store that had a hidden partition with some strange looking stuff....
The above URL uses counterfeit to mean drives are sold as large capacity drives that really don't have large flash chips inside. The upstream sellers buy small drives and reprogram the controllers to advertise a larger size that the drive really can't deliver.
Well these are marketed as 16Gb. parted is showing one to be 15.6Gb. And I have put over 8Gb on a couple of them. I think if MicroCenter was seriously mismarketing them, their customers would be complaining in droves. Being off by .4Gb would not be noticed and as in my cases tossed off as low quality that needed to mark parts of it as not to be used and thus the smaller size.
# parted /dev/sdb print Model: Generic- Multi-Card (scsi) Disk /dev/sdb: 15.6GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags:
Number Start End Size Type File system Flags 1 1000kB 513MB 512MB primary ext3 2 513MB 1025MB 512MB primary linux-swap(v1) 3 1025MB 15.6GB 14.5GB primary ext4
You do realize that whatever parted is showing is whatever the USB's controller is telling it? If you have having problems writing the full drive's worth of information (as your previous message indicated) my first sanity check would be to write the full *raw* drive with unique data and see if the expected data was still there on read.
I got a DVD recorded with a Sony DVD player. When I try to make a copy 1:1 using k3b I get the error that seems no available space in temporary folder!!! Temporary folder seems to be /tmp/kde-antonio/sony_dvd_recorder_volume and available space is detected as 1.9GB while project space is 4.2 GB
I tried also with Brasero but copy was incomplete and I wasted a new DVD.
Forgot to say that recorded files on original DVD are ok. (DVD is played fine). Anyway I can't do a copy of Video files on my PC as permits don't allow it.
On 08/07/14 14:03, antonio montagnani wrote:
I got a DVD recorded with a Sony DVD player. When I try to make a copy 1:1 using k3b I get the error that seems no available space in temporary folder!!! Temporary folder seems to be /tmp/kde-antonio/sony_dvd_recorder_volume and available space is detected as 1.9GB while project space is 4.2 GB
I tried also with Brasero but copy was incomplete and I wasted a new DVD.
Forgot to say that recorded files on original DVD are ok. (DVD is played fine). Anyway I can't do a copy of Video files on my PC as permits don't allow it.
Why don't you change the k3b settings to use a different "Default Temporary Directory"?
On 08/07/2014 02:03 AM, antonio montagnani wrote:
I got a DVD recorded with a Sony DVD player. When I try to make a copy 1:1 using k3b I get the error that seems no available space in temporary folder!!! Temporary folder seems to be /tmp/kde-antonio/sony_dvd_recorder_volume and available space is detected as 1.9GB while project space is 4.2 GB
I tried also with Brasero but copy was incomplete and I wasted a new DVD.
Forgot to say that recorded files on original DVD are ok. (DVD is played fine). Anyway I can't do a copy of Video files on my PC as permits don't allow it.
This is not an answer, but a question: Is there a bit-by-bit copy program that will copy _anything_ exactly, including encoding. so that Antonio's last comment becomes moot?
--doug
On 08/06/2014 11:31 PM, Doug wrote:
This is not an answer, but a question: Is there a bit-by-bit copy program that will copy _anything_ exactly, including encoding. so that Antonio's last comment becomes moot?
You should be able to do that with dd.
Joe Zeff ha scritto / said the following il giorno/on 07/08/2014 08:34:
On 08/06/2014 11:31 PM, Doug wrote:
This is not an answer, but a question: Is there a bit-by-bit copy program that will copy _anything_ exactly, including encoding. so that Antonio's last comment becomes moot?
You should be able to do that with dd.
of course I solved as suggested changing the image folder....but in my opinion for a new Linux user it should not happen to have to change any k3b setting as it should work immediately or to have to use dd. Please note that this is a fresh Fedora 20 installation and it is the first time that I wanted to make a DVD copy on this machine (it didn't happen for example in F18 or F19 on another machine) Tnx to all
On 08/07/14 15:11, antonio montagnani wrote:
Joe Zeff ha scritto / said the following il giorno/on 07/08/2014 08:34:
On 08/06/2014 11:31 PM, Doug wrote:
This is not an answer, but a question: Is there a bit-by-bit copy program that will copy _anything_ exactly, including encoding. so that Antonio's last comment becomes moot?
You should be able to do that with dd.
of course I solved as suggested changing the image folder....but in my opinion for a new Linux user it should not happen to have to change any k3b setting as it should work immediately or to have to use dd. Please note that this is a fresh Fedora 20 installation and it is the first time that I wanted to make a DVD copy on this machine (it didn't happen for example in F18 or F19 on another machine) Tnx to all
The "reason" it happened was probably due to changes which means /tmp is now mounted as tmpfs.
http://fedoraproject.org/wiki/Features/tmp-on-tmpfs
You may want to consider writing a bugzilla asking to change the defaults of k3b to use /var/tmp.
On 07Aug2014 15:15, ed greshko ed.greshko@greshko.com wrote:
On 08/07/14 15:11, antonio montagnani wrote:
Joe Zeff ha scritto / said the following il giorno/on 07/08/2014 08:34:
On 08/06/2014 11:31 PM, Doug wrote:
This is not an answer, but a question: Is there a bit-by-bit copy program that will copy _anything_ exactly, including encoding. so that Antonio's last comment becomes moot?
You should be able to do that with dd.
of course I solved as suggested changing the image folder....but in my opinion for a new Linux user it should not happen to have to change any k3b setting as it should work immediately or to have to use dd. Please note that this is a fresh Fedora 20 installation and it is the first time that I wanted to make a DVD copy on this machine (it didn't happen for example in F18 or F19 on another machine) Tnx to all
The "reason" it happened was probably due to changes which means /tmp is now mounted as tmpfs.
http://fedoraproject.org/wiki/Features/tmp-on-tmpfs
You may want to consider writing a bugzilla asking to change the defaults of k3b to use /var/tmp.
Or you could just ask k3b to use a different temp directory.
Many programs will honour the $TMPDIR environment variable, which I personally tend to set to $HOME/tmp.
I do not know if k3b pays it any attention, but you can try:
$ mkdir $HOME/tmp $ TMPDIR=$HOME/tmp k3b
Regarding /tmp as tmpfs being "idiocy", many platform do this. Solaris used to years and years ago. It makes /tmp really fast. And really, /tmp is for small stuff and is meant to be cleaned out regularly.
No matter how big it is, some tasks will exceed what /tmp offers. Take control: use a temp dir of your own for big stuff. DVDs are still big.
Cheers, Cameron Simpson cs@zip.com.au
The English-speaking world may be divided into those who neither know nor care what a split infinitive is, those who don't know, but care very much, those who know and approve, those who know and condemn, and those who know and distinguish. - H. W. Fowler
On 08/07/2014 12:11 AM, antonio montagnani issued this missive:
Joe Zeff ha scritto / said the following il giorno/on 07/08/2014 08:34:
On 08/06/2014 11:31 PM, Doug wrote:
This is not an answer, but a question: Is there a bit-by-bit copy program that will copy _anything_ exactly, including encoding. so that Antonio's last comment becomes moot?
You should be able to do that with dd.
of course I solved as suggested changing the image folder....but in my opinion for a new Linux user it should not happen to have to change any k3b setting as it should work immediately or to have to use dd. Please note that this is a fresh Fedora 20 installation and it is the first time that I wanted to make a DVD copy on this machine (it didn't happen for example in F18 or F19 on another machine)
This is because of the (in my opinion) extremely idiotic switch from a real, disk-based /tmp directory to a contrived tmpfs filesystem mounted at /tmp. They didn't bother telling you they were going to do this unless you read the release notes carefully, they just did it.
The system, by default, sucks up 50% of your RAM to commit to this harebrained concept of using a memory-based /tmp. So, your /tmp is only 50% of the size of your RAM, and half your RAM is committed to this moronic concept. I don't want half my RAM used for this.
The excuse offered by the creators of this lunacy is to the effect that "applications are supposed to use /var/tmp instead." The vast majority don't. End of story. This tmpfs-on-/tmp stuff has broken far more applications than I care to count.
The fix is to "systemctl mask tmp.mount" and reboot your system. This will leave /tmp pointing at your hard disk. I've done it on all my systems. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Polygon: A dead parrot (With apologies to John Cleese) - ----------------------------------------------------------------------
On 08/07/2014 02:52 PM, Rick Stevens wrote:
The fix is to "systemctl mask tmp.mount" and reboot your system. This will leave /tmp pointing at your hard disk. I've done it on all my systems.
I tried that... before
# df -h Filesystem Size Used Avail Use% Mounted on /dev/sdb1 20G 13G 5.6G 70% / devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 38M 3.9G 1% /dev/shm tmpfs 3.9G 1.3M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup tmpfs 3.9G 11M 3.9G 1% /tmp /dev/sda6 147G 70G 70G 51% /home2 /dev/sda7 919G 301G 572G 35% /backups /dev/sdb7 870G 567G 304G 66% /extra /dev/sdb4 145G 63G 75G 46% /home /dev/sdb3 778G 497G 242G 68% /media/my_data
after rebooting: df -h Filesystem Size Used Avail Use% Mounted on /dev/sdb1 20G 13G 5.6G 70% / devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 76K 3.9G 1% /dev/shm tmpfs 3.9G 9.3M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/sda6 147G 70G 70G 51% /home2 /dev/sda7 919G 301G 572G 35% /backups /dev/sdb4 145G 63G 75G 46% /home /dev/sdb7 870G 567G 304G 66% /extra /dev/sdb3 778G 497G 242G 68% /media/my_data
so it went from 4 to 3 tmpfs processes?? or is it just the lack of the tmpfs process /tmp ??
On 08/07/2014 12:32 PM, Paul Cartwright issued this missive:
On 08/07/2014 02:52 PM, Rick Stevens wrote:
The fix is to "systemctl mask tmp.mount" and reboot your system. This will leave /tmp pointing at your hard disk. I've done it on all my systems.
I tried that... before
# df -h Filesystem Size Used Avail Use% Mounted on /dev/sdb1 20G 13G 5.6G 70% / devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 38M 3.9G 1% /dev/shm tmpfs 3.9G 1.3M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup tmpfs 3.9G 11M 3.9G 1% /tmp /dev/sda6 147G 70G 70G 51% /home2 /dev/sda7 919G 301G 572G 35% /backups /dev/sdb7 870G 567G 304G 66% /extra /dev/sdb4 145G 63G 75G 46% /home /dev/sdb3 778G 497G 242G 68% /media/my_data
after rebooting: df -h Filesystem Size Used Avail Use% Mounted on /dev/sdb1 20G 13G 5.6G 70% / devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 76K 3.9G 1% /dev/shm tmpfs 3.9G 9.3M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/sda6 147G 70G 70G 51% /home2 /dev/sda7 919G 301G 572G 35% /backups /dev/sdb4 145G 63G 75G 46% /home /dev/sdb7 870G 567G 304G 66% /extra /dev/sdb3 778G 497G 242G 68% /media/my_data
so it went from 4 to 3 tmpfs processes?? or is it just the lack of the tmpfs process /tmp ??
First, /tmp starts out as just a directory on the root filesystem ("/").
Before your reboot, the system created a tmpfs filesystem and mounted it at /tmp. Therefore it's listed as a separate filesystem in "df" (because there IS a separate filesystem of type "tmpfs" mounted there) and it's 3.9G in size (meaning you probably have 8G of RAM).
After your reboot, /tmp remains just a directory on your / filesystem. It won't display as a separate filesystem (because nothing's mounted there) and your / filesystem is 20G with 5.6G free at the moment.
This new layout (with 5.6G free) would have been enough to create the ISO image in /tmp, whereas with the tmpfs crap, /tmp was only 3.9G and half your RAM was sucked up by that. Now you have all 8G of RAM available. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - To err is human. To forgive, a large sum of money is needed. - ----------------------------------------------------------------------
On 08/07/2014 03:59 PM, Rick Stevens wrote:
so it went from 4 to 3 tmpfs processes?? or is it just the lack of the tmpfs process /tmp ??
First, /tmp starts out as just a directory on the root filesystem ("/").
Before your reboot, the system created a tmpfs filesystem and mounted it at /tmp. Therefore it's listed as a separate filesystem in "df" (because there IS a separate filesystem of type "tmpfs" mounted there) and it's 3.9G in size (meaning you probably have 8G of RAM).
After your reboot, /tmp remains just a directory on your / filesystem. It won't display as a separate filesystem (because nothing's mounted there) and your / filesystem is 20G with 5.6G free at the moment.
This new layout (with 5.6G free) would have been enough to create the ISO image in /tmp, whereas with the tmpfs crap, /tmp was only 3.9G and half your RAM was sucked up by that. Now you have all 8G of RAM available.
thank you! makes sense..
On Wed, 2014-08-06 at 23:34 -0700, Joe Zeff wrote:
On 08/06/2014 11:31 PM, Doug wrote:
This is not an answer, but a question: Is there a bit-by-bit copy program that will copy _anything_ exactly, including encoding. so that Antonio's last comment becomes moot?
You should be able to do that with dd.
Up to a point. Commercial DVDs still won't work as the copy protection schemes tend to use "illegal" (out-of-spec) formatting which look to the driver like errors. At least it was that way last time I looked (a few years ago admittedly).
poc
On 08/07/2014 02:34 AM, Joe Zeff wrote:
On 08/06/2014 11:31 PM, Doug wrote:
This is not an answer, but a question: Is there a bit-by-bit copy program that will copy _anything_ exactly, including encoding. so that Antonio's last comment becomes moot?
You should be able to do that with dd.
You can burn a DVD with dd?
On Thu, 7 Aug 2014, Doug wrote:
On 08/07/2014 02:34 AM, Joe Zeff wrote:
On 08/06/2014 11:31 PM, Doug wrote:
This is not an answer, but a question: Is there a bit-by-bit copy program that will copy _anything_ exactly, including encoding. so that Antonio's last comment becomes moot?
You should be able to do that with dd.
You can burn a DVD with dd?
I've done it with cp . The last time I tried it, it didn't work. Don't remember why.
You cannot copy TO a dvd with dd, cp, mv ....etc because writing to optical media requires specialized SW like cdrecord.
But, you can certainly copy a DVD to HD by the dd command.
On Thu, Aug 7, 2014 at 9:40 PM, Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
On Thu, 7 Aug 2014, Doug wrote:
On 08/07/2014 02:34 AM, Joe Zeff wrote:
On 08/06/2014 11:31 PM, Doug wrote:
This is not an answer, but a question: Is there a bit-by-bit copy program that will copy _anything_ exactly, including encoding. so that Antonio's last comment becomes moot?
You should be able to do that with dd.
You can burn a DVD with dd?
I've done it with cp . The last time I tried it, it didn't work. Don't remember why.
-- Michael hennebry@web.cs.ndsu.NoDak.edu "SCSI is NOT magic. There are *fundamental technical reasons* why it is necessary to sacrifice a young goat to your SCSI chain now and then." -- John Woods -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On 08/08/14 12:09, JD wrote:
You cannot copy TO a dvd with dd, cp, mv ....etc because writing to optical media requires specialized SW like cdrecord.
That's not 100% true. One could be using a DVD-RAM. :-) :-)
[egreshko@meimei ~]$ df /dev/sr0 Filesystem 1K-blocks Used Available Use% Mounted on /dev/sr0 4402628 12310 4166648 1% /run/media/egreshko/dvdram2
[egreshko@meimei ~]$ cp nq140731.gif /run/media/egreshko/dvdram2
[egreshko@meimei ~]$ ls /run/media/egreshko/dvdram2 lost+found nq140731.gif
BTW, I kind of hate to continue this thread since I just noticed it has been hijacked from the "cloned sd card is not booting" thread....
On 08Aug2014 12:46, ed greshko ed.greshko@greshko.com wrote:
BTW, I kind of hate to continue this thread since I just noticed it has been hijacked from the "cloned sd card is not booting" thread....
Yeah, I saw that earlier. So I told my mailer to break the thread ("#" in mutt) and it is all cool. In my mail folder, anyway:-) What, your mailer can't break/join threads?
Cheers, Cameron Simpson cs@zip.com.au
UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. - Doug Gwyn
On 08/08/14 13:33, Cameron Simpson wrote:
Yeah, I saw that earlier. So I told my mailer to break the thread ("#" in mutt) and it is all cool. In my mail folder, anyway:-) What, your mailer can't break/join threads?
Of course that is all irrelevant since that doesn't fix the archives. :-)
On Thu, 7 Aug 2014, JD wrote:
You cannot copy TO a dvd with dd, cp, mv ....etc because writing to optical media requires specialized SW like cdrecord.
As mentioned, I've done it. Surprised me that it worked. That said, it does not work any more. 'Tis been a few years since I've done it.
On 08/09/14 03:20, Michael Hennebry wrote:
On Thu, 7 Aug 2014, JD wrote:
You cannot copy TO a dvd with dd, cp, mv ....etc because writing to optical media requires specialized SW like cdrecord.
As mentioned, I've done it. Surprised me that it worked. That said, it does not work any more. 'Tis been a few years since I've done it.
Actually, you can still do that today. Took me a while to remember this.....
In order to do that you need to access the drive in "Packet Writing" mode.
You can do that after installing udftools and using the various utilities within it to create a packet writing device and associate it with the DVD drive and then format the DVD+/- RW disc properly for use.
On 08/08/2014 06:35 PM, Ed Greshko wrote:
On 08/09/14 03:20, Michael Hennebry wrote:
On Thu, 7 Aug 2014, JD wrote:
/snip/
The subject is correct: there is something verkocht in the latest K3b, ver. 2.0.2. I tried on two computers with two OSs to burn a DVD with K3b, and it screwed up with both of them. In the PCLOS Forum, there is a new post today about K3b being fubar. Just another example of the devs not listening to Ann Landers' advice--"If it ain't broke, don't fix it!" Or another old axiom: "If you play with anything long enough, you'll break it!" I have used K3b for years without a problem, and they went and broke it.
--doug
Sorry about top posting. This old phone only does it this way.
I use k3b 2.0.2 under F17 for burning video dvd's and don't have a problem. Also use it for data dvd and install dvd.
Would like to know how it is fubar.
Dave Sent from my BlackBerry® smartphone powered by Mobilicity
-----Original Message----- From: Doug dmcgarrett@optonline.net Sender: users-bounces@lists.fedoraproject.org Date: Fri, 08 Aug 2014 19:01:50 To: users@lists.fedoraproject.org Reply-To: Community support for Fedora users users@lists.fedoraproject.org Subject: Re: Cannot make a copy of video DVD with k3b
On 08/08/2014 06:35 PM, Ed Greshko wrote:
On 08/09/14 03:20, Michael Hennebry wrote:
On Thu, 7 Aug 2014, JD wrote:
/snip/
The subject is correct: there is something verkocht in the latest K3b, ver. 2.0.2. I tried on two computers with two OSs to burn a DVD with K3b, and it screwed up with both of them. In the PCLOS Forum, there is a new post today about K3b being fubar. Just another example of the devs not listening to Ann Landers' advice--"If it ain't broke, don't fix it!" Or another old axiom: "If you play with anything long enough, you'll break it!" I have used K3b for years without a problem, and they went and broke it.
--doug
On 08/08/2014 08:49 PM, davidschaak1@mobilicity.blackberry.com wrote:
Sorry about top posting. This old phone only does it this way.
I use k3b 2.0.2 under F17 for burning video dvd's and don't have a problem. Also use it for data dvd and install dvd.
Would like to know how it is fubar.
Dave Sent from my BlackBerry® smartphone powered by Mobilicity
-----Original Message----- From: Doug dmcgarrett@optonline.net Sender: users-bounces@lists.fedoraproject.org Date: Fri, 08 Aug 2014 19:01:50 To: users@lists.fedoraproject.org Reply-To: Community support for Fedora users users@lists.fedoraproject.org Subject: Re: Cannot make a copy of video DVD with k3b snip/
On 08/09/2014 12:12 AM, Doug wrote:
On 08/08/2014 08:49 PM, davidschaak1@mobilicity.blackberry.com wrote:
Sorry about top posting. This old phone only does it this way.
I use k3b 2.0.2 under F17 for burning video dvd's and don't have a problem. Also use it for data dvd and install dvd.
Would like to know how it is fubar.
Dave Sent from my BlackBerry® smartphone powered by Mobilicity
In my own case, K3b refused to burn 100% of a file which gave a proper md5sum on two computers, separate operating systems, separate downloads. The same file download transferred via Konqueror-SuperUser to the Windows 7 partition and burned by burncdcc.exe had no burn problem and the disk had no trouble installing and using (with the exception of a particular difficulty with its software). In the case of the "fubar" which is my own interpretation, here is the quote from MCP on the PCLOS Forum, which was posted on July 21, altho I didn't see it until today:
"k3b has not given me any problems. I don't burn that many disks but just recently when I tried to copy a dvd it got to the point of burning and it just stopped and would not move past the "Insert blank disk" message. I tried several times and then resorted to creating an image which it did, but when I put in a blank and tried to burn it would not progress past the mdsum. The burn button was greyed out."
Another post on the PCLOS Forum, from craesz, same thread, reads as follows:
"I too am having difficulty with K3b... I haven't used this machine to burn a CD in a while. Each time I try to burn, it tells me that there is an I/O problem and most likely my drive is full.... it's not. I just ran the above command and the output is: Code: [Select] javascript:void(0);
|brwxrwxrwx+ 1 root root 11, 0 Aug 7 05:46 /dev/sr0 "
|
The subject is correct: there is something verkocht in the latest K3b, ver. 2.0.2. I tried on two computers with two OSs to burn a DVD with K3b, and it screwed up with both of them. In the PCLOS Forum, there is a new post today about K3b being fubar. Just another example of the devs not listening to Ann Landers' advice--"If it ain't broke, don't fix it!" Or another old axiom: "If you play with anything long enough, you'll break it!" I have used K3b for years without a problem, and they went and broke it.
--doug
See opening of last post.
I agree about if ain't broke don't fix it. I still have a fc5 nfs server that is still doing its job.
Dave
Sent from my BlackBerry® smartphone powered by Mobilicity
-----Original Message----- From: Doug dmcgarrett@optonline.net Sender: users-bounces@lists.fedoraproject.org Date: Sat, 09 Aug 2014 00:22:31 To: users@lists.fedoraproject.org Reply-To: Community support for Fedora users users@lists.fedoraproject.org Subject: Re: Cannot make a copy of video DVD with k3b
On 08/08/2014 08:49 PM, davidschaak1@mobilicity.blackberry.com wrote:
Sorry about top posting. This old phone only does it this way.
I use k3b 2.0.2 under F17 for burning video dvd's and don't have a problem. Also use it for data dvd and install dvd.
Would like to know how it is fubar.
Dave Sent from my BlackBerry® smartphone powered by Mobilicity
In my own case, K3b refused to burn 100% of a file which gave a proper md5sum on two computers, separate operating systems, separate downloads. The same file download transferred via Konqueror-SuperUser to the Windows 7 partition and burned by burncdcc.exe had no burn problem and the disk had no trouble installing and using (with the exception of a particular difficulty with its software). In the case of the "fubar" which is my own interpretation, here is the quote from MCP on the PCLOS Forum, which was posted on July 21, altho I didn't see it until today:
"k3b has not given me any problems. I don't burn that many disks but just recently when I tried to copy a dvd it got to the point of burning and it just stopped and would not move past the "Insert blank disk" message. I tried several times and then resorted to creating an image which it did, but when I put in a blank and tried to burn it would not progress past the mdsum. The burn button was greyed out."
On 08/09/2014 12:12 AM, Doug wrote:
On 08/08/2014 08:49 PM, davidschaak1@mobilicity.blackberry.com wrote:
Sorry about top posting. This old phone only does it this way.
I use k3b 2.0.2 under F17 for burning video dvd's and don't have a problem. Also use it for data dvd and install dvd.
Would like to know how it is fubar.
Dave Sent from my BlackBerry® smartphone powered by Mobilicity
In my own case, K3b refused to burn 100% of a file which gave a proper md5sum on two computers, separate operating systems, separate downloads. The same file download transferred via Konqueror-SuperUser to the Windows 7 partition and burned by burncdcc.exe had no burn problem and the disk had no trouble installing and using (with the exception of a particular difficulty with its software). In the case of the "fubar" which is my own interpretation, here is the quote from MCP on the PCLOS Forum, which was posted on July 21, altho I didn't see it until today:
"k3b has not given me any problems. I don't burn that many disks but just recently when I tried to copy a dvd it got to the point of burning and it just stopped and would not move past the "Insert blank disk" message. I tried several times and then resorted to creating an image which it did, but when I put in a blank and tried to burn it would not progress past the mdsum. The burn button was greyed out."
Another post on the PCLOS Forum, from craesz, same thread, reads as follows:
"I too am having difficulty with K3b... I haven't used this machine to burn a CD in a while. Each time I try to burn, it tells me that there is an I/O problem and most likely my drive is full.... it's not. I just ran the above command and the output is: Code: [Select] javascript:void(0);
|brwxrwxrwx+ 1 root root 11, 0 Aug 7 05:46 /dev/sr0 "
|
-----Original Message----- From: Doug dmcgarrett@optonline.net Sender: users-bounces@lists.fedoraproject.org Date: Fri, 08 Aug 2014 19:01:50 To: users@lists.fedoraproject.org Reply-To: Community support for Fedora users users@lists.fedoraproject.org Subject: Re: Cannot make a copy of video DVD with k3b
On 08/08/2014 06:35 PM, Ed Greshko wrote:
On 08/09/14 03:20, Michael Hennebry wrote:
On Thu, 7 Aug 2014, JD wrote:
/snip/
The subject is correct: there is something verkocht in the latest K3b, ver. 2.0.2. I tried on two computers with two OSs to burn a DVD with K3b, and it screwed up with both of them. In the PCLOS Forum, there is a new post today about K3b being fubar. Just another example of the devs not listening to Ann Landers' advice--"If it ain't broke, don't fix it!" Or another old axiom: "If you play with anything long enough, you'll break it!" I have used K3b for years without a problem, and they went and broke it.
--doug
On 08/06/2014 05:26 AM, Louis Lagendijk wrote:
On Tue, 2014-08-05 at 23:44 -0400, Robert Moskowitz wrote:
Starting File System Check on/dev/disk/by-uuid/1dc8...f055a32473b9... [ 13.911063] systemd-fsck[368]: _/: The filesystem size (according to the superblock) is 3587707 blocks [ OK ] Started dracut pre-mount hook. [ 13.919598] systemd-fsck[368]: The physical size of the device is 3548795 blocks [ 13.937109] systemd-fsck[368]: Either the superblock or the partition table is likely to be corrupt! [ 13.944962] systemd-fsck[368]: _/: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
are the cards exactly the same size? It looks as if the card you copiued to is smaller than the one you copied from... What does fdisk -l report for disk size for the "old" and "new" cards?
Well, yes they are different:
# fdisk -l /dev/sdb
Disk /dev/sdb: 14.7 GiB, 15720251392 bytes, 30703616 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: 0xd42361d8
# fdisk -l /dev/sdc
Disk /dev/sdc: 14.5 GiB, 15560867840 bytes, 30392320 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: 0xed0dd3b4
And nothing I can do about that. Seems that the size is based on whatever fits based on quality of the chip.
On 08/06/2014 02:16 PM, Robert Moskowitz wrote:
And nothing I can do about that. Seems that the size is based on whatever fits based on quality of the chip.
http://media.ccc.de/browse/congress/2013/30C3_-_5294_-_en_-_saal_1_-_2013122...
Watch this, and you never look at an SD-Card the same ever again.
On Wed, 2014-08-06 at 08:16 -0400, Robert Moskowitz wrote:
On 08/06/2014 05:26 AM, Louis Lagendijk wrote:
On Tue, 2014-08-05 at 23:44 -0400, Robert Moskowitz wrote:
Starting File System Check on/dev/disk/by-uuid/1dc8...f055a32473b9... [ 13.911063] systemd-fsck[368]: _/: The filesystem size (according to the superblock) is 3587707 blocks [ OK ] Started dracut pre-mount hook. [ 13.919598] systemd-fsck[368]: The physical size of the device is 3548795 blocks [ 13.937109] systemd-fsck[368]: Either the superblock or the partition table is likely to be corrupt! [ 13.944962] systemd-fsck[368]: _/: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
are the cards exactly the same size? It looks as if the card you copiued to is smaller than the one you copied from... What does fdisk -l report for disk size for the "old" and "new" cards?
Well, yes they are different:
# fdisk -l /dev/sdb
Disk /dev/sdb: 14.7 GiB, 15720251392 bytes, 30703616 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: 0xd42361d8
# fdisk -l /dev/sdc
Disk /dev/sdc: 14.5 GiB, 15560867840 bytes, 30392320 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: 0xed0dd3b4
And nothing I can do about that. Seems that the size is based on whatever fits based on quality of the chip.
Do a resizefs <device/partition> new-size to something smaller than what will fit on the new stick. After copying the content over it should boot ok and then correct the partiton table (delete the partition and create it again, fdisk should automatically set the size IIRC), then do a resize2fs <device/partiton> without size ro enlarge the partion to it's max size. The only problem: for the shrinking the partion must be unmounted.
Louis
-
antonio montagnani -
Cameron Simpson -
davidschaak1＠mobilicity.blackberry.com -
Doug -
Ed Greshko -
JD -
Jeandet Alexis -
Jens Neu -
Joe Zeff -
Louis Lagendijk -
Michael Hennebry -
Patrick O'Callaghan -
Paul Cartwright -
Rick Stevens -
Robert Moskowitz -
Tim -
Wolfgang S. Rupprecht