1. Forum
  2. FidoNet
  3. ALT.OS.LINUX.MAGEIA

  • Problem copying Mageia 8 iso.

    From Doug Laidlaw@2:250/1 to All on Sat Jan 15 12:24:06 2022
    I have downloaded the full Mageia 8 iso by BitTorrent. Neither Etcher
    nor isodumper is able to write it to a USB stick successfully. I
    checked the download and tried to use a .torrent file from Distrowatch.
    Both said that the download had no problems. The report from Isodumper
    was a bit more informative. It said that the checksum in the ISO was defective and unreadable. In these circumstances, the BitTorrent
    protocol should ensure that the download is O.K.

    --- MBSE BBS v1.0.7.24 (GNU/Linux-x86_64)
    * Origin: Aioe.org NNTP Server (2:250/1@fidonet)
  • From Bit Twister@2:250/1 to All on Sat Jan 15 13:04:46 2022
    On Sat, 15 Jan 2022 23:24:06 +1100, Doug Laidlaw wrote:
    I have downloaded the full Mageia 8 iso by BitTorrent. Neither Etcher
    nor isodumper is able to write it to a USB stick successfully. I
    checked the download and tried to use a .torrent file from Distrowatch.
    Both said that the download had no problems. The report from Isodumper
    was a bit more informative. It said that the checksum in the ISO was defective and unreadable. In these circumstances, the BitTorrent
    protocol should ensure that the download is O.K.

    I always do a checksum on the download and burn.
    Saves me from creating coasters and wasting time on a bad
    burn/xfer to cd or usb.


    --- MBSE BBS v1.0.7.24 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From David W. Hodgins@2:250/1 to All on Sat Jan 15 22:05:37 2022
    On Sat, 15 Jan 2022 07:24:06 -0500, Doug Laidlaw <[email protected]> wrote:

    I have downloaded the full Mageia 8 iso by BitTorrent. Neither Etcher
    nor isodumper is able to write it to a USB stick successfully. I
    checked the download and tried to use a .torrent file from Distrowatch.
    Both said that the download had no problems. The report from Isodumper
    was a bit more informative. It said that the checksum in the ISO was defective and unreadable. In these circumstances, the BitTorrent
    protocol should ensure that the download is O.K.

    Did you download the sha3 signature to the same directory as the iso image?

    You can check the on disk copy with ...

    # cd /downloadlocation
    (for me, that's /s3/m8/Mageia-8-x86_64/ )
    [root@x3 /s3/m8/Mageia-8-x86_64]# cat Mageia-8-x86_64.iso.sha3 F3DADD10FCB64BCBAC55C91B9270521520D70195BDF27CEB414E0F4960863D8C3C0EC4ECDF5AFF87868FA8133BE1A58EFB58239DDC845F5A598DD0441EF685F3 Mageia-8-x86_64.iso
    [root@x3 /s3/m8/Mageia-8-x86_64]# sha3-512sum -c Mageia-8-x86_64.iso.sha3 Mageia-8-x86_64.iso: OK

    Using isodumper, it will check the sha3 sum of the copy from the usb stick after
    copying it, not the copy on disk. If the on disk copy is ok and the on usb stick
    copy is not, then the copy failed, likely due to a bad usb stick.

    If you don't have a copy of the sha3 sum file in the same directory as the iso file, isodumper will report "The computed and stored sums don't match", since there is no stored sha3 sum file.

    I'd prefer it that it reported that the sha3 sum file was not found, though it's
    not technically an error to say the sums don't match, and changing it would involve replacing the currently used python library function with a new function
    written to be written by Mageia.

    I've also opened https://bugs.mageia.org/show_bug.cgi?id=29895 as the key server
    hard coded in isodumper is no longer available, and the current gpg release key has expired.

    Regards, Dave Hodgins

    --- MBSE BBS v1.0.7.24 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Doug Laidlaw@2:250/1 to All on Sun Jan 16 14:07:58 2022
    On 16/1/22 00:04, Bit Twister wrote:
    I always do a checksum on the download and burn.
    Saves me from creating coasters and wasting time on a bad
    burn/xfer to cd or usb.

    A fair comment, but the checksum you need is that of the CD you burned.
    In my experience, that checksum never matches the one from the
    download. k3b derives its own checksum before the burn. and the two iso-dumpers would have done the same. Apparently, after the burn, the
    checksum could not be read to compare. The burn might still be good.

    --- MBSE BBS v1.0.7.24 (GNU/Linux-x86_64)
    * Origin: Aioe.org NNTP Server (2:250/1@fidonet)
  • From Doug Laidlaw@2:250/1 to All on Sun Jan 16 14:17:59 2022
    On 16/1/22 09:05, David W. Hodgins wrote:
    Using isodumper, it will check the sha3 sum of the copy from the usb
    stick after
    copying it, not the copy on disk. If the on disk copy is ok and the on
    usb stick
    copy is not, then the copy failed, likely due to a bad usb stick.

    What I downloaded was set by the .torrent file. It included checksums
    for MD5, sha3 and sha512, with gpg files for them all, including the iso itself.

    I burned the iso to 2 different USB sticks, the USB2 one I used
    originally and a fairly new Lexar USB3 one. Both burns failed.

    --- MBSE BBS v1.0.7.24 (GNU/Linux-x86_64)
    * Origin: Aioe.org NNTP Server (2:250/1@fidonet)
  • From Bit Twister@2:250/1 to All on Sun Jan 16 17:07:45 2022
    On Mon, 17 Jan 2022 01:07:58 +1100, Doug Laidlaw wrote:
    On 16/1/22 00:04, Bit Twister wrote:
    I always do a checksum on the download and burn.
    Saves me from creating coasters and wasting time on a bad
    burn/xfer to cd or usb.

    A fair comment, but the checksum you need is that of the CD you burned.
    In my experience, that checksum never matches the one from the
    download. k3b derives its own checksum before the burn. and the two iso-dumpers would have done the same. Apparently, after the burn, the checksum could not be read to compare. The burn might still be good.

    I use cdrecord for burning and readcd to read cd and iso for md5sum.
    Code snippet follows:

    echo "$_exe
    #***************************************
    #* Getting $_drive md5sum
    #***************************************
    "

    _iso_bytes=$(stat $_iso_fn -c %s)
    _sectors=$(( $_iso_bytes / 2048 ))

    set $(readcd sectors=0-$_sectors dev=$_drive f=- | md5sum)
    _cd_sum=$1

    echo "$_exe
    #***************************************
    #* Getting $_drive md5sum
    #***************************************
    "

    _iso_bytes=$(stat $_iso_fn -c %s)
    _sectors=$(( $_iso_bytes / 2048 ))

    set $(readcd sectors=0-$_sectors dev=$_drive f=- | md5sum)
    _cd_sum=$1

    echo "$_exe
    #***************************************
    #* Computing $_iso_fn md5sum
    #***************************************
    "
    set $(md5sum $_iso_fn)
    _iso_sum=$1


    if [ "$_cd_sum" != "$_iso_sum" ] ; then
    _fatal_msg=("md5sum mismatch"
    " "
    "dvd: $_cd_sum"
    "iso: $_iso_sum")
    fatal 1
    fi

    --- MBSE BBS v1.0.7.24 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Sun Jan 16 19:01:24 2022
    On 2022-01-16, Doug Laidlaw <[email protected]> wrote:
    On 16/1/22 00:04, Bit Twister wrote:
    I always do a checksum on the download and burn.
    Saves me from creating coasters and wasting time on a bad
    burn/xfer to cd or usb.

    A fair comment, but the checksum you need is that of the CD you burned.
    In my experience, that checksum never matches the one from the
    download. k3b derives its own checksum before the burn. and the two iso-dumpers would have done the same. Apparently, after the burn, the checksum could not be read to compare. The burn might still be good.

    Of course it is not the same. If you read /dev/sdb say (assuming that is
    your cdrom/usbstick) it will keep reading until it comes to the end of the disk.
    That will be beyond the end the file you just wrote to there with say
    dd. Thus the two files are of different lenths and have differnt
    contents, and the checksum will be different. You have to tell the
    checksum program to only read as many bytes as you wrote.

    --- MBSE BBS v1.0.7.24 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Sun Jan 16 19:02:52 2022
    On 2022-01-16, Doug Laidlaw <[email protected]> wrote:
    On 16/1/22 09:05, David W. Hodgins wrote:
    Using isodumper, it will check the sha3 sum of the copy from the usb
    stick after
    copying it, not the copy on disk. If the on disk copy is ok and the on
    usb stick
    copy is not, then the copy failed, likely due to a bad usb stick.

    What I downloaded was set by the .torrent file. It included checksums
    for MD5, sha3 and sha512, with gpg files for them all, including the iso itself.

    I burned the iso to 2 different USB sticks, the USB2 one I used
    originally and a fairly new Lexar USB3 one. Both burns failed.

    What do you mean "failed"? How did they fail? How do you know they
    failed. Be exact in your description.

    --- MBSE BBS v1.0.7.24 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From faeychild@2:250/1 to All on Mon Jan 17 00:16:28 2022
    On 17/1/22 01:17, Doug Laidlaw wrote:


    I burned the iso to 2 different USB sticks, the USB2 one I used
    originally and a fairly new Lexar USB3 one.  Both burns failed.


    I have always downloaded from the repo.
    Used to burn to CD which is a long clumsy perilous process.
    So I now install to USB stick with isodunmper and it has worked fine.
    I have some distrust for torrents - just my paranoia


    --
    faeychild
    Running plasmashell 5.20.4 on 5.15.11-desktop-3.mga8 kernel.
    Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso


    --- MBSE BBS v1.0.7.24 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)