Re: have a mate-desktop CD was Re: magnet links and pushing them to meta-search engines.
On 17/03/2018, Steve McIntyre <steve@einval.com> wrote:
> [ Dropped the mate list - this isn't relevant there... ]
>
<snipped>
Reply in-line :-
>
> Then you were definitely using ISO mode in Rufus. The main problem
> with that (and with unetbootin and other tools that work like this) is
> that it's very easy to replace boot loader files with versions that
> don't work well together, or don't work the way we expect and have
> tested. If you're blindly modifying what the d-i and debian-cd scripts
> have produced, then we have no way of knowing if reported bugs are our
> fault or not. That's why we *really* don't recommend unetbootin, for
> example. We have had a lot of bugs reported by novice users that we
> just cannot reproduce.
>
Dear Steve,
I actually tried in both but neither worked in Rufus. I'm going to get
couple of usb sticks to get to the bottom of this mess.
> For Debian installer images for both i386 and amd64, we create iso
> hybrid media which will run 4 different ways:
>
> * BIOS boot from CD/DVD (isolinux)
> * BIOS boot from USB (isolinux)
> * UEFI boot from CD/DVD (grub)
> * UEFI boot from USB (grub)
>
Is it one and the same from -
https://cdimage.debian.org/cdimage/buster_di_alpha2/amd64/iso-cd/
https://cdimage.debian.org/cdimage/buster_di_alpha2/amd64/iso-cd/debian-buster-DI-alpha2-amd64-xfce-CD-1.iso
or somewhere different.
> and that's a deliberate choice for maximum flexibility from a single
> image. If a tool like unetbootin changes the setup of the media, it's
> very likely to break things here.
>
correction it was rufus who was trying to put in tools, not unetbootin.
I tried rufus both in iso mode as well as dd mode without any success at all.
>>During a discussion with Steve Mcntyre during debconf 2016, he had
>>shared about both the unrealiability of the usb drives themselves as
>>well as the data so now always use shasums to make sure the data
>>stream is correct.
>
> Yay!
>
>>This https://www.debian.org/CD/faq/#write-usb I had already done
>>before. I used the built-in
>>certutil and Get-FileHash on MS-Windows powershell to make sure the
>>sum was correct.
>>
>>Now that I'm on Debian GNU/Linux did as I had copied the same on one
>>of my usb disks, the .iso image which I just transferred to the hdd.
>>
>>shirish@debian:~/games$ ./check_debian_iso SHA1SUMS
>>debian-buster-DI-alpha2-amd64-xfce-CD-1.iso
>>Piping 331776 blocks of 'debian-buster-DI-alpha2-amd64-xfce-CD-1.iso'
>>through 'sha1sum'
>>to verify checksum list item
>> 'debian-buster-DI-alpha2-amd64-xfce-CD-1.iso'.
>>331776+0 records in
>>331776+0 records out
>>679477248 bytes (679 MB, 648 MiB) copied, 1.35603 s, 501 MB/s
>>Ok: 'debian-buster-DI-alpha2-amd64-xfce-CD-1.iso' matches
>>'debian-buster-DI-alpha2-amd64-xfce-CD-1.iso' in 'SHA1SUMS'
>>
>>although trying to do the same with /dev/sdb or /dev/sdb1 results in -
>>
>>shirish@debian:~/games$ ./check_debian_iso SHA1SUMS
>>debian-buster-DI-alpha2-amd64-xfce-CD-1.iso /dev/sdb
>>Does not look like an ISO 9660 filesystem: '/dev/sdb' magic=' '
>>
>>That's the usb key/thumb drive on which debian iso image is done by
>> unetbootin.
>
> So unetbootin will not have written an exact copy.
>
That might be correct.
see -
~/games$ ls -lh debian-buster-DI-alpha2-amd64-xfce-CD-1.iso
-rw-r--r-- 1 shirish shirish 648M Dec 5 21:37
debian-buster-DI-alpha2-amd64-xfce-CD-1.iso
~/games$ mount
........
/dev/sdb1 on /media/shirish/DEBIAN TEST type vfat
(rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
shirish@debian:~/games$ df -h /media/shirish/DEBIAN\ TEST/
Filesystem Size Used Avail Use% Mounted on
/dev/sdb1 29G 808M 29G 3% /media/shirish/DEBIAN TEST
But I do believe that during transfer from .iso image to installation
media some archives are extracted, hence perhaps the change .
I did notice that the time-stamp changes which it shouldn't have -
shirish@debian:/media/shirish/DEBIAN TEST$ ls -lh
total 46M
-rw-r--r-- 1 shirish shirish 146 Dec 5 21:04 autorun.inf
drwxr-xr-x 3 shirish shirish 64K Mar 10 02:00 boot
drwxr-xr-x 2 shirish shirish 64K Mar 10 02:00 css
drwxr-xr-x 3 shirish shirish 64K Mar 10 02:00 dists
drwxr-xr-x 4 shirish shirish 64K Mar 10 02:00 doc
drwxr-xr-x 3 shirish shirish 64K Mar 10 02:00 efi
drwxr-xr-x 2 shirish shirish 64K Mar 10 02:00 firmware
-rw-r--r-- 1 shirish shirish 180K Dec 4 12:55 g2ldr
-rw-r--r-- 1 shirish shirish 8.0K Dec 4 12:55 g2ldr.mbr
drwxr-xr-x 2 shirish shirish 64K Mar 10 02:00 install
drwxr-xr-x 3 shirish shirish 64K Mar 10 02:00 install.amd
drwxr-xr-x 2 shirish shirish 64K Mar 10 02:00 isolinux
-r--r--r-- 1 shirish shirish 32K Mar 10 02:07 ldlinux.sys
-rw-r--r-- 1 shirish shirish 146K Dec 5 21:05 md5sum.txt
-rw-r--r-- 1 shirish shirish 60K Mar 10 02:07 menu.c32
drwxr-xr-x 2 shirish shirish 64K Mar 10 02:00 pics
drwxr-xr-x 3 shirish shirish 64K Mar 10 02:00 pool
-rw-r--r-- 1 shirish shirish 8.8K Dec 5 21:05 README.html
-rw-r--r-- 1 shirish shirish 291 Mar 5 2017 README.mirrors.html
-rw-r--r-- 1 shirish shirish 86 Mar 5 2017 README.mirrors.txt
-rw-r--r-- 1 shirish shirish 535 Dec 5 21:04 README.source
-rw-r--r-- 1 shirish shirish 5.5K Dec 5 21:05 README.txt
-rwxr-xr-x 1 shirish shirish 618K Dec 4 12:55 setup.exe
-rw-r--r-- 1 shirish shirish 3.8K Mar 10 02:07 syslinux.cfg
drwxr-xr-x 2 shirish shirish 64K Mar 10 01:58 'System Volume Information'
drwxr-xr-x 2 shirish shirish 64K Mar 10 02:00 tools
-rw-r--r-- 1 shirish shirish 88K Mar 10 02:07 ubnfilel.txt
-rw-r--r-- 1 shirish shirish 39M Dec 5 21:04 ubninit
-rw-r--r-- 1 shirish shirish 4.3M Dec 5 21:04 ubnkern
-rw-r--r-- 1 shirish shirish 20K Mar 10 02:00 ubnpathl.txt
-rw-r--r-- 1 shirish shirish 233 Dec 5 21:04 win32-loader.ini
>>Although it appears to have worked though as was able to get a working
>>Debian GNU/Linux system at the end, was able to get updates, get the
>>net working and so on and so forth.
>>
>>FTR, I could have used cp or dd but that would have been only if I had
>>taken my lappy that day. It should not be a requirement that we should
>>have a debian laptop because in real-world scenarios many people not
>>might have access to an installation nor should they require one,
>>although do agree it's handy if it's there.
>
> Absolutely, hence why we have recommendations for rufus in DD mode, or
> before that win32diskimager.
I will definitely try rufus in dd mode but as of buy the sticks, make
sure they are genuine
although do trust the vendor but still, use f3 on it and then try to
do the above.
$ aptitude show f3
Package: f3
Version: 7.0-1
New: yes
State: installed
Automatically installed: no
Priority: optional
Section: utils
Maintainer: Antoine Beaupré <anarcat@debian.org>
Architecture: amd64
Uncompressed Size: 166 k
Depends: libc6 (>= 2.8), libparted2 (>= 3.1), libudev1 (>= 183)
Description: test real flash memory capacity
F3 (Fight Flash Fraud or Fight Fake Flash) tests the full capacity of
a flash card (flash drive, flash disk, pendrive).
F3 writes to the card and then checks if can read it. It will assure
you have not been bought a card with a smaller capacity than stated.
Note that the main goal of F3 is not to fix your removable media.
However, there are resources to mark the invalid areas.
This package provides these executables: f3write, f3read, f3brew,
f3fix and f3probe.
Homepage: http://oss.digirati.com.br/f3
Hence the need for time needed to figuring out things.
>
> --
> Steve McIntyre, Cambridge, UK.
> steve@einval.com
> < Aardvark> I dislike C++ to start with. C++11 just seems to be
> handing rope-creating factories for users to hang multiple
> instances of themselves.
>
>
--
Regards,
Shirish Agarwal शिरीष अग्रवाल
My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8
Reply to: