Re: Install on remote KVM?

[Jose R R]

Niltze-

On Sat, Aug 11, 2018 at 6:37 AM, Ben Hutchings  wrote:
> On Sun, 2018-08-12 at 00:25 +1200, Richard Hector wrote:
>> On 12/08/18 00:16, Ben Hutchings wrote:
>> > On Sat, 2018-08-11 at 22:58 +1200, Richard Hector wrote:
>> > [...]
>> > > I'm mostly familiar with the netinst image, and it's what I generally
>> > > use to install on real hardware.
>> > >
>> > > I'm less familiar with netboot, but have used it for PXE installs 
>> > > (right?)
>> > >
>> > > What I'm missing is how I can use either of them on a remote KVM VPS,
>> > > where I get to see the boot process on some kind of remote console, and
>> > > I have the opportunity to provide a bootable ISO, but not much else.
>> > >
>> > > I've tried providing the netinst ISO, and it boots but can't find itself
>> > > for installing packages.
>> >
>> > OK, so you're only providing the netinst ISO?  Somehow I got the
>> > impression that you were providing a separate initramfs.  Sorry for the
>> > irrelevant answer.
>> >
>> > > Is that a matter of the appropriate storage drivers not being included,
>> > > or is it the way the VPS provider set up the virtual CD?
>> >
>> > It's both!  libvirt can provide (through QEMU) an emulated CD drive
>> > attached to an Intel PATA controller, Intel SATA controller, LSI Logic
>> > SCSI controller or virtio SCSI controller.  I've just verified that the
>> > installer works for all of the first three options, but not virtio.
>> >
>> > If there's an option to configure the CD drive to be attached through
>> > one of the other controllers, you should choose that.  But we should
>> > also add virtio drivers to the standard installer initramfs.
>>
>> Great, thanks heaps for all that effort.
>>
>> I don't think there's (currently) a way to attach it differently (though
>> I could request that, and they well might do it - which might help
>> people who want to install other distros too).
>>
>> But in the meantime, can I tell the installer to download a different
>> initramfs which will work? Or does one of the other installer ISOs (ie
>> not the netinst ones) come with a suitable initramfs?
>
> I can see two options:
>
> - Rebuild the standard installer with virtio-modules included, and then
>   rebuild the netinst ISO image
> - Build an ISO image from the netboot installer
>
> But neither of those are easy unless you're already familiar with the
> process.
>
> Ben.
>
UpCloud provide a similar interface to Virt-Manager when installing
your own OS. They address the issue being discussed here -- by
describing 'a trick' to install your own OS:

< https://www.upcloud.com/support/using-own-installation-media/ >

I can confirm it works as reported in
< https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847230 >


Best Professional Regards.

-- 
Jose R R
http://metztli.it
-
Download Metztli Reiser4: Debian Stretch w/ Linux 4.17 AMD64
-
feats ZSTD compression https://sf.net/projects/metztli-reiser4/
---
Official current Reiser4 resources: https://reiser4.wiki.kernel.org/

iso-scan_1.69_source.changes ACCEPTED into unstable

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 11 Aug 2018 23:25:53 +0200
Source: iso-scan
Binary: iso-scan load-iso
Architecture: source
Version: 1.69
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Holger Wansing 
Description:
 iso-scan   - Scan hard drives for an installer ISO image (udeb)
 load-iso   - Load installer components from an installer ISO (udeb)
Changes:
 iso-scan (1.69) unstable; urgency=medium
 .
   * Team upload
 .
   [ Cyril Brulebois ]
   * Update Vcs-{Browser,Git} to point to salsa (alioth's replacement).
 .
   [ Updated translations ]
   * Belarusian (be.po) by Viktar Siarheichyk
   * Finnish (fi.po) by Juhani Numminen
   * Dutch (nl.po) by Frans Spiesschaert
Checksums-Sha1:
 e0b7d2424821ea51da3b7a553c35cce09ecda101 1675 iso-scan_1.69.dsc
 bb44ba3015877996e1438e79b1d85b5a80550ef0 111576 iso-scan_1.69.tar.xz
 12fe46651b81dc77853f1c4cd8867391996c3f47 5584 iso-scan_1.69_amd64.buildinfo
Checksums-Sha256:
 c0b70fa38c56e6501d269c01a886729e1433c236660757690ca178c60ca748a0 1675 
iso-scan_1.69.dsc
 961aaedcdadc5879c2ca289ce11aa72b5fff202a45e70b78b464b8db1d603a6c 111576 
iso-scan_1.69.tar.xz
 ddae5111339acaf79964034a757372b0ea08533d2080fc850ab39a9549150464 5584 
iso-scan_1.69_amd64.buildinfo
Files:
 2129c47a321715233695991aa73cd641 1675 debian-installer optional 
iso-scan_1.69.dsc
 fdca281984c910a9d2281399aa0c5733 111576 debian-installer optional 
iso-scan_1.69.tar.xz
 13cbf1486f809d51fe6264715c0beb56 5584 debian-installer optional 
iso-scan_1.69_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEESWrG6BRCSzSFCDUpWfGHyhVusHYFAltvVfMACgkQWfGHyhVu
sHZ8vQ//Xhc66G4n1bRNkeSKN7EKbA8kyEchSNil8OJvjEAon7NNH1j40olmRDoG
DDfwfsPLk8f3+z3+8rJpQGwU5Q6IDVW+tuWaBVZI5pXHNL6/HIj9xMKVhWsXw4Uo
S46V6xlCZuNlDds9io9iyQCGl/gweskrf2BuczGamU6JkVe3w6C5FKwE/+cE1yve
VpDslbOb4+UH4RsSiXwoQewiU+9Glx+aSHeTmX74sFI7k/akaCLI0NuOKBt1jQtg
ieKtXDOHFMLeNU4v/+pXyBdOVa4bn5L8y9hiaony40FwIG/rgcOKgyJX6RhrnPwt
asfL5Ahg93T/cqX2J0n3xjYkvmjikf3E333Jmv+7bwV4FM1IYgPdXWcZyt0s6+SS
ihWHYj77clEwPTkdC+ffwv/m1g16+aXzX4u/RWv00Ek4EmDY9rDFuszDUeB4MevJ
Vk2DaD2027tH50AJtvFT1QFLlUfxJS3kXTsboaMQnLVB5hAUmtTzYeHIu6t/q0tV
2/iuADNVSAJA63b0W9jhsMOPwsHt5vt9i2f8s4Ec8n3pHtrZGdezqhXpEu/+y/bN
A0tYyADOHPLJTA6BO+ZIskDFN3Fb4TdXxsSMUEu/65xpXwC/6CC5F8h5cG2vGZ0c
q0gD2/iEnywd/EJn4wRsbCryhWPpcEm+6BVBuU9sm3+YDIefagc=
=VwDG
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

Processing of iso-scan_1.69_source.changes

[Debian FTP Masters]

iso-scan_1.69_source.changes uploaded successfully to localhost
along with the files:
  iso-scan_1.69.dsc
  iso-scan_1.69.tar.xz
  iso-scan_1.69_amd64.buildinfo

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

hw-detect_1.133_source.changes ACCEPTED into unstable

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 11 Aug 2018 23:11:08 +0200
Source: hw-detect
Binary: hw-detect ethdetect disk-detect driver-injection-disk-detect archdetect
Architecture: source
Version: 1.133
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Holger Wansing 
Description:
 archdetect - Hardware architecture detector (udeb)
 disk-detect - Detect disk drives (udeb)
 driver-injection-disk-detect - Detect OEM driver injection disks (udeb)
 ethdetect  - Detect network hardware and load kernel drivers for it (udeb)
 hw-detect  - Detect hardware and load kernel drivers for it (udeb)
Changes:
 hw-detect (1.133) unstable; urgency=medium
 .
   [ Cyril Brulebois ]
   * Update Vcs-{Browser,Git} to point to salsa (alioth's replacement).
 .
   [ Updated translations ]
   * Hebrew (he.po) by Yaron Shahrabani
Checksums-Sha1:
 a2cbc07340c23b2b2b07abaa2dc8c486d2204374 2040 hw-detect_1.133.dsc
 156a2ed204020c8e8bceecd3c4b4c2270978993a 188420 hw-detect_1.133.tar.xz
 0727bc4e14f3bf55b5f9bdb870450e7ce38c826b 6565 hw-detect_1.133_amd64.buildinfo
Checksums-Sha256:
 fea132eab56609a5bbfb53799422445b5bd2561e7a5bd759898af0b0a2118092 2040 
hw-detect_1.133.dsc
 36c184738857c5d794b3da743a744c4195c5183b3cd56dd46c889f0b93e22988 188420 
hw-detect_1.133.tar.xz
 2ebb324e572b6e297d783afdf30fe7adedfa2dbd58ab677a16fe5110057243a3 6565 
hw-detect_1.133_amd64.buildinfo
Files:
 1739886dcb3966dbb87d747a96b61252 2040 debian-installer standard 
hw-detect_1.133.dsc
 5f63cbb58b10f95ac457bbd38d16090c 188420 debian-installer standard 
hw-detect_1.133.tar.xz
 b4d1a95b8dd74d20a76c691f680ceb28 6565 debian-installer standard 
hw-detect_1.133_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEESWrG6BRCSzSFCDUpWfGHyhVusHYFAltvUnwACgkQWfGHyhVu
sHYm5w//Vg4Rp/XXl1i/oy0Zw+6NKXpj4luLl9fmmsPLMkFNmSXKh+Oh5/6gQ2sj
x9UFmco+jq8Yr6RM8yvbDbh/jcZDiLpV/beVKE9kHVhxaD5snaG8P81R9S7qG84b
ttWunbbENJq2wwqp+3mNC5s7gCxyDqWhsZN3rt/jtFjaL2Y93HFv2pEbk9gxXss+
WFPt2PEgsyPd8SSvWGdjzrZ9X+acmy0IopzxjPtIO58Wxe/qm3u/VMA+dMup7pOt
W5PM9xJp8ojwd4HaLPj8CmxfSh38tL80GpPYBKlHn4ZJfDDMa0D45EsVT3SqfBXO
NhQLCN288/P/EZNO520GRA5BmkJ7ChV7xGQqQ6tg5pEVPELkysH02hkysx5QGw4y
8ApAMVjLA3x7mOzo1itep5E5qXIOyj+Q8JMlwVw8d4H5+we0ACTftStLeWZdCLRp
LrzOYYu3lbK4sPYzLms58kYG1H/Li+XjwqreeVnUUF45YJCuw1jyyFD5w6wMgaXM
cl8cdj5mR6puiAb2OHWNo5o4MxuVnTiowYN8bA1MD+juuGoL2fViVdM8R+E/l+rD
AtmjRvU8eBh5iyOIPSEIQwSX2xy0EMqaNgarRV/9iKHUKPq0Op76iYjY+uFgc1qw
3v5BCFKC0fHbwjjLwU4XKEiqYEAOrPZ66vziUPDjWlYnA+2rMoA=
=z8oq
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

Processing of hw-detect_1.133_source.changes

[Debian FTP Masters]

hw-detect_1.133_source.changes uploaded successfully to localhost
along with the files:
  hw-detect_1.133.dsc
  hw-detect_1.133.tar.xz
  hw-detect_1.133_amd64.buildinfo

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

finish-install_2.95_source.changes ACCEPTED into unstable

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 11 Aug 2018 22:47:03 +0200
Source: finish-install
Binary: finish-install
Architecture: source
Version: 2.95
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Holger Wansing 
Description:
 finish-install - Finish the installation and reboot (udeb)
Changes:
 finish-install (2.95) unstable; urgency=medium
 .
   * Team upload
 .
   [ Cyril Brulebois ]
   * Update Vcs-{Browser,Git} to point to salsa (alioth's replacement).
 .
   [ Updated translations ]
   * Finnish (fi.po) by Juhani Numminen
   * Hebrew (he.po) by Yaron Shahrabani
   * Telugu (te.po) by Praveen Illa
Checksums-Sha1:
 52d6488678f3cebb666224f7d634063c23325542 1645 finish-install_2.95.dsc
 d8c31b1e1135925de246238355bf37964d46ce77 56636 finish-install_2.95.tar.xz
 eb772ae761283ec4db109b9c29b7c5deb61a52a4 5409 
finish-install_2.95_amd64.buildinfo
Checksums-Sha256:
 75aedbfe494569c1a751a5141d1484ccbb55ccca34b0a35a180a5cc226e2dabe 1645 
finish-install_2.95.dsc
 ba868274d364d860ce5d9d033856a66a3a7ced3f0a559ef93ba63dc5e313ecc1 56636 
finish-install_2.95.tar.xz
 18f52009f90024d268b2b7055ca172e33fe2b0076a8f5a2e9f3265a2c63e0d39 5409 
finish-install_2.95_amd64.buildinfo
Files:
 0b959917bd906ba0da0e9098057385f1 1645 debian-installer required 
finish-install_2.95.dsc
 f37155aa08e4598c9b4ec12dc19c2d33 56636 debian-installer required 
finish-install_2.95.tar.xz
 1ef54f272db0964c8bc85aeaa810a416 5409 debian-installer required 
finish-install_2.95_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEESWrG6BRCSzSFCDUpWfGHyhVusHYFAltvTe0ACgkQWfGHyhVu
sHbc9BAAqRUTuWUbrMYVpUqwWsDSzw1dpQEYg9h6q4xS11VKT2R3/I+rWjzeIccT
DcUKmqgyGFLHsrdB4i/mxDjJmwiEUu8cSFfz+SfuVj4j8Kk5tg3VWDAascaB/cNt
/jCkOVyK+MNR8Q0LkFNZ8LpTg8eokcQ1e8MuqmDQv4whhbo1C38yE6UunjaC++25
rY0oMN2U/efXUDXDeX/8zLZsPd5Wxxx3ZDp7FvGjjtmtXZMW7SJWMk+T6GO62+Gp
bfXv6iJaukKChGp2diNvfVTCrQ+HwhHcTpdZbQSvOEE5Eu94Lht8BYqCDxZpBVHd
GBUTSUx83UGwdwadfgBI2DsrzCTN9tYKvFuI+M/jC8jT6G0aSXP1vQuOsnD+jC1s
QJIK1OVPJn7IFUmRBwkDbJZxOgpRjUPwxB+j2kxk3tPcOkh9adNJSuKDS1OJ9XRL
OWehRTjGwnwM+xTminQJQrL+DyHYFNhm+5ogdlmIY5R59vUh0BMjZGWPVXggaRNW
uOcCdodJcp4Tf5FUfTweIOxaq/1Q206YmMatpWsoRDsU8lI8RgVpQ4n9++jhHI1o
KqVKwkUii+ZGLMFaMOuiABpALYpRUY2LesUnRcNIuG2ZrXDn6HhSd7MEATha7wwD
gDDqreBjijUvXuQxUnUHf1gVUzDsEJaGfzoAV9DTTEjqyjP+apI=
=HQmw
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

Processing of finish-install_2.95_source.changes

[Debian FTP Masters]

finish-install_2.95_source.changes uploaded successfully to localhost
along with the files:
  finish-install_2.95.dsc
  finish-install_2.95.tar.xz
  finish-install_2.95_amd64.buildinfo

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

debian-installer-utils_1.128_source.changes ACCEPTED into unstable

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 11 Aug 2018 22:26:25 +0200
Source: debian-installer-utils
Binary: di-utils-shell di-utils-reboot di-utils-exit-installer di-utils 
di-utils-mapdevfs di-utils-terminfo
Architecture: source
Version: 1.128
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Holger Wansing 
Description:
 di-utils   - Miscellaneous utilities for the debian installer (udeb)
 di-utils-exit-installer - Exit installer (udeb)
 di-utils-mapdevfs - mapdevfs utility for the debian installer (udeb)
 di-utils-reboot - Reboot (udeb)
 di-utils-shell - Execute a shell (udeb)
 di-utils-terminfo - Terminfo entries needed by newt/slang in debian installer 
(udeb)
Changes:
 debian-installer-utils (1.128) unstable; urgency=medium
 .
   * Team upload
 .
   [ Cyril Brulebois ]
   * Update Vcs-{Browser,Git} to point to salsa (alioth's replacement).
 .
   [ Updated translations ]
   * Hebrew (he.po) by Yaron Shahrabani
Checksums-Sha1:
 b846765ac0813aea8333f46998af161723ad9030 2239 debian-installer-utils_1.128.dsc
 fda2612e6b179117b454b23d0c7b21d35dc7b98c 98640 
debian-installer-utils_1.128.tar.xz
 8c59bf09a7216ea5ed41e0cebf46f42053cd9e73 6985 
debian-installer-utils_1.128_amd64.buildinfo
Checksums-Sha256:
 26bf7e57c8c936c239ab569008e81fc8e22033ad7b236a894e30f16d1efe86f1 2239 
debian-installer-utils_1.128.dsc
 1db23e0c63e736653fe0aa18e5045c2b2dc2f43fe5da0760f9c8474a681f3c4c 98640 
debian-installer-utils_1.128.tar.xz
 d22304135bc1d723666ae2bde3997d4fb3f82344bbe45f3e07ebf3001f670bca 6985 
debian-installer-utils_1.128_amd64.buildinfo
Files:
 87bd7b2fda276eceff9d6c4e6a246d3f 2239 debian-installer standard 
debian-installer-utils_1.128.dsc
 4d783d2075046006991888a38243668b 98640 debian-installer standard 
debian-installer-utils_1.128.tar.xz
 87dffbb8098a0e95e2ca083e7f19fcfb 6985 debian-installer standard 
debian-installer-utils_1.128_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEESWrG6BRCSzSFCDUpWfGHyhVusHYFAltvSLYACgkQWfGHyhVu
sHZv9xAAh/NGhpKJDj8ShJJ1RSYKS8jqRrDRkNzIClTDtaBfs2wyy43R5GB0LTul
f8SnHoqRBSdrwiis5txwWae9vXfWDbSqLyTIJ86+3zuhJBDFbVNSfFfl5y8w0Uw+
qMI7gmc4EOFE4y0pGy62JZRBAzS/BxGj5PEoZ6c2m42eEjAHHSqHbDJ6mPBe9BC7
ABJXsl9mWaeQAwX52g34eYF4gXaS3y9V3SnbWCbUCztGg3QFin0DRUYHfoQW6ZI3
bpoNSq1hDUOI+1VMKvTKnOz3oKAIaVKzYw0m/Xdt3ayF+31ghFsXvJxJa3lvZrz5
iqqAQs/syHBQrLrvx02B2W7jN/+ZdaadAjDKIJMd9aTaLGzIr5NHBelLP+hh1tYp
ko/CwSekzS/fzWX3SjGD7OdIFWrJ/EbSoUnuJmSlHj8OLcO3PHToGy62pX5N0sUw
PndT/ZGFscQOAZ43Y67QQDRqWZ12HQiknrzDkkbC4DWG+UpC7dAshkHwjsGVip5L
g25wphtuLKopHGQLpwYwZuZCbUPDegeBOQCb4KYIBrIrAAvdMJ1t9jdBXER9p6nB
21yH2onZBSBVhiMYD1ShUJnCy/R0VDR3ETMy+5FpPT0E0Esaftqlz6X/WIJtgFsp
Qc98v0IHxOvmH8FJI6RHmjNrpdw74Gume2BcgXIjjscMb7tBHVg=
=3fXV
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

Processing of debian-installer-utils_1.128_source.changes

[Debian FTP Masters]

debian-installer-utils_1.128_source.changes uploaded successfully to localhost
along with the files:
  debian-installer-utils_1.128.dsc
  debian-installer-utils_1.128.tar.xz
  debian-installer-utils_1.128_amd64.buildinfo

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

clock-setup_0.139_source.changes ACCEPTED into unstable

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 11 Aug 2018 21:10:18 +0200
Source: clock-setup
Binary: clock-setup
Architecture: source
Version: 0.139
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Holger Wansing 
Description:
 clock-setup - set up clock (udeb)
Changes:
 clock-setup (0.139) unstable; urgency=medium
 .
   * Team upload
 .
   [ Cyril Brulebois ]
 .
   * Update Vcs-{Browser,Git} to point to salsa (alioth's replacement).
 .
   [ Updated translations ]
   * Hebrew (he.po) by Yaron Shahrabani
Checksums-Sha1:
 7341200c83e009125f8591dede714c5bc25d1207 1614 clock-setup_0.139.dsc
 43a9c9fc6ebf52800d667a6ad2b124f097159587 75788 clock-setup_0.139.tar.xz
 f3f98218dee05c3e9b6cb3146c6bb1d8555459e2 5395 clock-setup_0.139_amd64.buildinfo
Checksums-Sha256:
 c80bbc234b73c799fd67c2dfc42423cdab848066073273c0ac9e1e84f1fb55cb 1614 
clock-setup_0.139.dsc
 9779767a15f130417f2b5641a1003fc3d6d8f8baff0e74d5963f00031dfc1af9 75788 
clock-setup_0.139.tar.xz
 533a2130b0d686e8fc66a83f36b5b4e74f10a40c59b7ef750694900947ba2cfe 5395 
clock-setup_0.139_amd64.buildinfo
Files:
 766fbf0314578f23b5319a0590136945 1614 debian-installer standard 
clock-setup_0.139.dsc
 193e6562a818b291d7ea39991c011ae4 75788 debian-installer standard 
clock-setup_0.139.tar.xz
 83dc92144c213d2b0e91a425b2c90202 5395 debian-installer standard 
clock-setup_0.139_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEESWrG6BRCSzSFCDUpWfGHyhVusHYFAltvObEACgkQWfGHyhVu
sHaXTQ/+N8OrukYW8Ciny7IP7p4fH3x8bCyaVXZvmtA208L0eBRPDWqu4HzQ/7Ed
VxGBKrxLs8OWXPT5Qi77QL+nG/jtQjBM3ncqaqPcd5/tsfXMR2Jm/Qf1m0ycxrhZ
Z2kmM8SNCGfzZLI/NQSPYNs1ITh9tvmoCurWAXbjWSElZOVgazuMOlOYxGCmgCoD
PUudmrN5ZDJtk6C7MHO2vNwE97k+0ZJMsVNxzMQMu7QrNsAiImtuOTrZpZ8I6tTT
ORZDp6EH6bCbCo3zcaqDskWPl9EU06DOW1pCuTEvTSO8I7t3nanuXVri6UL0NqIg
Lg+8Ku/0PFeSdgueqJHx8PB27X2Xd+1QI5CPY8e79Xo2/94LNaeMmQN3co4gZxlx
XpJNVtCAoGMRv0HkW5hgT3vL/3fKdKQXS/uAafU60No2bDfo1zhgLrvItKEFptVK
6ndH/6Xoy3xeaxpOfOughKVdUj55Gc+EA5BygcKVkoeVLk8/apsYYafVf1v6ozSm
U7T/wnvXFauJ8ZavS/MLsMcPYStUW9POdxwLCvztstNWpODSNJfg8kgvDsbcImTd
SIVrc/LqlMey3n3WIMjVbTKullw1h8Yc9gA9kEcD6eolwyj49opgB1RrGQ6KRaey
Gf0yEzX/8ohkU12Qaz3CE4GT/OWPFTwHgJ3Zv5iP/K9ESo02FaY=
=0aI/
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

Processing of clock-setup_0.139_source.changes

[Debian FTP Masters]

clock-setup_0.139_source.changes uploaded successfully to localhost
along with the files:
  clock-setup_0.139.dsc
  clock-setup_0.139.tar.xz
  clock-setup_0.139_amd64.buildinfo

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

Re: anna_1.68_source.changes ACCEPTED into unstable

[Holger Wansing]

Hi,

Cyril Brulebois  wrote:
> Hello,
> 
> Here are some answers. Feel free to (re)organize them in a wiki page
> under the DebianInstaller namespace. :)
> 
> Holger Wansing  (2018-08-10):
> > Yes, and I didn't read anything about that in the several
> > packaging/uploading docu. So that's mostly best practice, but no
> > strict packaging rule or the like?
> > 
> > Also, I don't know anything about tagging.  So, I need to know
> > something more about this tagging:
> > 
> > When do we use it?
> > Just for every new uploaded version, as it seems...
> > More circumstances, where to set tags?
> 
> I think most if not all packaging teams create tags when they upload a
> given revision of a source package; this even existed prior to git! :)
> 
> This makes it possible to identify what revision of source code was
> (probably, no absolute guarantee) used to create a given package,
> which limits the need for downloading entire history of source
> packages using debsnap and friends.
> 
> > Which tags do we use? The lightweighted or the annotated ones?
> > Looking at the existing tags, it seems that's annotated ones, but
> > without GPG signatur. Right?
> 
> I tend to use this when releasing:
> 
>   git commit -am 'releasing version $copied_from_changelog'
>   git tag -sm 'tagging version $copied_from_changelog' 
> $copied_possibly_adapted_from_changelog

Ok, understood.
And done.


Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

cdrom-detect_1.78_source.changes ACCEPTED into unstable

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 11 Aug 2018 12:08:29 +0200
Source: cdrom-detect
Binary: cdrom-detect
Architecture: source
Version: 1.78
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Holger Wansing 
Description:
 cdrom-detect - Detect CDROM devices and mount the CD (udeb)
Changes:
 cdrom-detect (1.78) unstable; urgency=medium
 .
   * Team upload
 .
   [ Cyril Brulebois ]
   * Update Vcs-{Browser,Git} to point to salsa (alioth's replacement).
 .
   [ Updated translations ]
   * Finnish (fi.po) by Juhani Numminen
   * Hebrew (he.po) by Yaron Shahrabani
Checksums-Sha1:
 d1f8de95be1d660501b21adc324040d1c4c51a7d 1673 cdrom-detect_1.78.dsc
 1f12208f2d6d9c787810926e60a8153098525754 126196 cdrom-detect_1.78.tar.xz
 0b5fefa2dcb604142ab5078ec08f4f8c6e38cf93 5389 cdrom-detect_1.78_amd64.buildinfo
Checksums-Sha256:
 c95807d9c613c6cf6a2695b22bd7d6e2259c003b67a7a5a7f691f60f67a7aa68 1673 
cdrom-detect_1.78.dsc
 893643e86bfdb0cbe9a406d1d54da36a7b597cf8466f180972075698905d1184 126196 
cdrom-detect_1.78.tar.xz
 3a7e3162a1a5372a9cb8c445d0ca2c01b00ec8b8c29029e741e7ec8db1f91206 5389 
cdrom-detect_1.78_amd64.buildinfo
Files:
 eeb30c5fbb96cb21480941ea06734c8b 1673 debian-installer optional 
cdrom-detect_1.78.dsc
 0fc723ff28df276439e88feef3f1f58d 126196 debian-installer optional 
cdrom-detect_1.78.tar.xz
 4b829318c6c4e4693666ecdda89a8d81 5389 debian-installer optional 
cdrom-detect_1.78_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEESWrG6BRCSzSFCDUpWfGHyhVusHYFAltvKx8ACgkQWfGHyhVu
sHb8WA/8DJwP3VDVS/Dvsg0cPaCzZc/5ZQEOkHNtrn+wI6Q82EDvG1eIq5PAaFAh
7VoMQxbN2xakNcWe4W2n7Qf9UKOIhxWAsHW/5tpWoNxHBouv6S33nvqsknonF877
sMN1LYRQAaM4bMhvnFKXoE0kYrpfGfyY0rjqWdgj/IxG1Lye7FzX/jRdE1bOfevx
l/6s3iycKglzd03HZ5tjxaAH/Jo6jXAJNqDMDjXBgti6CdSCAhnSfyewm82hGyGx
+Fr3AmAmCb2knTLNNSWJNxW6Y8XGkICom11DSPmuAw9+yS2mVLL8owck3mV5MobZ
SJJXhQR3kNd+epU2qdImcAsxclScnrvVeuDsiFjSplYa5sOj5659epMGspLJjODk
Kb9T0bnQkxQDapPRW5ylLkJx3Um7Z9AovR5e85sSJK09hhOBuM+HAEjcMMOb6sqf
GUIdJRyg6rY0Jkn8ItR++xLwmJlh8CMTrsS/3RTmbSzjqEscbpxHM7Da01fHJuvL
JRrmGdNDyzgfhI/WyWa25xKTMTAadAAySucBd2FymKIslG7woKRBNnYuBCAOOUgp
rIb75aqV0e549uqlQVjpddFOdfpakN/EmYyHYi4ZA2FZnbudxcfLjVy5TcgXd37q
UWP23g1sQvn0QUQnzrSwjD7lUpE2CP3LmSHXDHdp9ejHUMAALvU=
=r+tl
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

Processing of cdrom-detect_1.78_source.changes

[Debian FTP Masters]

cdrom-detect_1.78_source.changes uploaded successfully to localhost
along with the files:
  cdrom-detect_1.78.dsc
  cdrom-detect_1.78.tar.xz
  cdrom-detect_1.78_amd64.buildinfo

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

Welcome to

[Firelip Bjeg]

Hi, My Name is Albert MItchell (racineLLC Corporation)
Please i need to talk with someone from Support Team.
Thanks

Bug#815164: Welcome to

[Firelip Bjeg]

Hi, My Name is Albert MItchell (racineLLC Corporation)
Please i need to talk with someone from Support Team.
Thanks

Re: anna_1.68_source.changes ACCEPTED into unstable

[Cyril Brulebois]

Hello,

Here are some answers. Feel free to (re)organize them in a wiki page
under the DebianInstaller namespace. :)

Holger Wansing  (2018-08-10):
> Yes, and I didn't read anything about that in the several
> packaging/uploading docu. So that's mostly best practice, but no
> strict packaging rule or the like?
> 
> Also, I don't know anything about tagging.  So, I need to know
> something more about this tagging:
> 
> When do we use it?
> Just for every new uploaded version, as it seems...
> More circumstances, where to set tags?

I think most if not all packaging teams create tags when they upload a
given revision of a source package; this even existed prior to git! :)

This makes it possible to identify what revision of source code was
(probably, no absolute guarantee) used to create a given package,
which limits the need for downloading entire history of source
packages using debsnap and friends.

> Which tags do we use? The lightweighted or the annotated ones?
> Looking at the existing tags, it seems that's annotated ones, but
> without GPG signatur. Right?

I tend to use this when releasing:

  git commit -am 'releasing version $copied_from_changelog'
  git tag -sm 'tagging version $copied_from_changelog' 
$copied_possibly_adapted_from_changelog

If you don't have a GPG key handy (but then how would you debsign your
upload?), you might want to use “git tag -am” instead of “git tag -sm”,
which indeed creates an annotated tag, which still contains meta data
like the tagger, a message, etc.; except for the GPG signature part.

Interesting points:
 - you can mention the real/complete version in there;
 - you can verifiy the GPG signature if you ever doubt the repository
   (remember we have rather broad access with many many users on
   alioth first and on salsa now);
 - “git describe” doesn't use lightweight tags by default, one needs
   to pass “--tags”, so annotated/signed tags are better for that as
   well.

What about those versions?
 - $copied_from_changelog: hopefully self-explanatory :)
 - $copied_possibly_adapted_from_changelog: there are special
   characters that can be used in Debian version numbers, but cannot
   be used directly in git (like ':' and '~'), so we have to adjust
   for those.

Examples for ':' include apt-setup, busybox, tzsetup; depending on the
habits of the person who uploads them, the epoch part (N:) is
sometimes removed entirely (there can be a single version in the
Debian archive of a given package, regardless of the epoch part,
anyway). Usual replacement character is '%'.

Examples for '~' include all packages we backport using the usual
scheme: $unstable_version~deb9u1. Usual replacement character is '_'.

People might use git-buildpackage which has some tagging options,
but I tend to find the command line overly long, and it prefixes
tags with a debian/ string, which we doesn't really make sense in a
d-i context since most packages are Debian-specific anyway. We could
arguable ship a configuration file in all packages, but I'm not sure
we need more administrativia…

Maybe we should just have a tagging script in the scripts/ directory?
I used to use “xsf-tag” in the X Strike Force:
  https://salsa.debian.org/xorg-team/debian/xsf-tools/blob/master/xsf-tag

What do you think?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Debian 9.5 Installer

[Ben Hutchings]

[Moving to the debian-boot list]

On Sat, 2018-08-11 at 15:36 +0200, Carl-Valentin Schmitt wrote:
> Apparently the installer compels each time before Installation to delete
> hard disk too slowly.

It doesn't, though.

> It should be optional to delete (slowly) the harddisk or to format harddisk
> quickly.
> 
> In 9.5 installer there is no option for formatting without deleting.

If you install with full disk encryption enabled, then by default the
installer will overwrite the whole encrypted volume.  This is done to
avoid leaking some information about the size and structure of the
encrypted data.

You can cancel this process, and the installation process will still
continue.  That should really be explained in the status message.

If you don't install with full disk encryption, no overwriting is done
by default.

Ben.

-- 
Ben Hutchings
Time is nature's way of making sure that
everything doesn't happen at once.



signature.asc
Description: This is a digitally signed message part

Re: Install on remote KVM?

[Ben Hutchings]

On Sun, 2018-08-12 at 00:25 +1200, Richard Hector wrote:
> On 12/08/18 00:16, Ben Hutchings wrote:
> > On Sat, 2018-08-11 at 22:58 +1200, Richard Hector wrote:
> > [...]
> > > I'm mostly familiar with the netinst image, and it's what I generally
> > > use to install on real hardware.
> > > 
> > > I'm less familiar with netboot, but have used it for PXE installs (right?)
> > > 
> > > What I'm missing is how I can use either of them on a remote KVM VPS,
> > > where I get to see the boot process on some kind of remote console, and
> > > I have the opportunity to provide a bootable ISO, but not much else.
> > > 
> > > I've tried providing the netinst ISO, and it boots but can't find itself
> > > for installing packages.
> > 
> > OK, so you're only providing the netinst ISO?  Somehow I got the
> > impression that you were providing a separate initramfs.  Sorry for the
> > irrelevant answer.
> > 
> > > Is that a matter of the appropriate storage drivers not being included,
> > > or is it the way the VPS provider set up the virtual CD?
> > 
> > It's both!  libvirt can provide (through QEMU) an emulated CD drive
> > attached to an Intel PATA controller, Intel SATA controller, LSI Logic
> > SCSI controller or virtio SCSI controller.  I've just verified that the
> > installer works for all of the first three options, but not virtio.
> > 
> > If there's an option to configure the CD drive to be attached through
> > one of the other controllers, you should choose that.  But we should
> > also add virtio drivers to the standard installer initramfs.
> 
> Great, thanks heaps for all that effort.
> 
> I don't think there's (currently) a way to attach it differently (though
> I could request that, and they well might do it - which might help
> people who want to install other distros too).
> 
> But in the meantime, can I tell the installer to download a different
> initramfs which will work? Or does one of the other installer ISOs (ie
> not the netinst ones) come with a suitable initramfs?

I can see two options:

- Rebuild the standard installer with virtio-modules included, and then
  rebuild the netinst ISO image
- Build an ISO image from the netboot installer

But neither of those are easy unless you're already familiar with the
process.

Ben.

-- 
Ben Hutchings
Time is nature's way of making sure that
everything doesn't happen at once.


signature.asc
Description: This is a digitally signed message part

Re: Install on remote KVM?

[Richard Hector]

On 12/08/18 00:16, Ben Hutchings wrote:
> On Sat, 2018-08-11 at 22:58 +1200, Richard Hector wrote:
> [...]
>> I'm mostly familiar with the netinst image, and it's what I generally
>> use to install on real hardware.
>>
>> I'm less familiar with netboot, but have used it for PXE installs (right?)
>>
>> What I'm missing is how I can use either of them on a remote KVM VPS,
>> where I get to see the boot process on some kind of remote console, and
>> I have the opportunity to provide a bootable ISO, but not much else.
>>
>> I've tried providing the netinst ISO, and it boots but can't find itself
>> for installing packages.
> 
> OK, so you're only providing the netinst ISO?  Somehow I got the
> impression that you were providing a separate initramfs.  Sorry for the
> irrelevant answer.
> 
>> Is that a matter of the appropriate storage drivers not being included,
>> or is it the way the VPS provider set up the virtual CD?
> 
> It's both!  libvirt can provide (through QEMU) an emulated CD drive
> attached to an Intel PATA controller, Intel SATA controller, LSI Logic
> SCSI controller or virtio SCSI controller.  I've just verified that the
> installer works for all of the first three options, but not virtio.
> 
> If there's an option to configure the CD drive to be attached through
> one of the other controllers, you should choose that.  But we should
> also add virtio drivers to the standard installer initramfs.

Great, thanks heaps for all that effort.

I don't think there's (currently) a way to attach it differently (though
I could request that, and they well might do it - which might help
people who want to install other distros too).

But in the meantime, can I tell the installer to download a different
initramfs which will work? Or does one of the other installer ISOs (ie
not the netinst ones) come with a suitable initramfs?

Thanks,
Richard



signature.asc
Description: OpenPGP digital signature

Bug#689528: please add virtio support for cdrom at install time

[Ben Hutchings]

On Mon, 17 Mar 2014 03:32:41 +0100 Cyril Brulebois  wrote:
[...]
> I suspect the following happens:
>  - when booting on non-virtio cdrom, udebs are detected on the cdrom
>and/or on the network, loaded, and the virtio-modules kernel udeb is
>then loaded, and non-cdrom resources work fine (nic, hard disk).
>  - when booting with virtio cdrom, the relevant module hasn't been put
>in the initramfs, so cdrom isn't detected at all, and game over.

Richard just ran into this again.

> I suspect all we need is to add virtio-modules-${kernel:Version} to
> pkg-lists/cdrom/.cfg files. Quoting for example the amd64 one:

I agree.  This should be done for at least amd64 and i386.  It is
probably sensible for all architectures where virtio-modules is built.

[...]
> I haven't played much with virtio myself, but I could probably provide
> you with an amd64 netinst image for test purposes. Do you want to
> perform some tests?

I can test this easily.

Ben.

-- 
Ben Hutchings
Time is nature's way of making sure that
everything doesn't happen at once.



signature.asc
Description: This is a digitally signed message part

Re: Install on remote KVM?

[Ben Hutchings]

On Sat, 2018-08-11 at 22:58 +1200, Richard Hector wrote:
[...]
> I'm mostly familiar with the netinst image, and it's what I generally
> use to install on real hardware.
> 
> I'm less familiar with netboot, but have used it for PXE installs (right?)
>
> What I'm missing is how I can use either of them on a remote KVM VPS,
> where I get to see the boot process on some kind of remote console, and
> I have the opportunity to provide a bootable ISO, but not much else.
> 
> I've tried providing the netinst ISO, and it boots but can't find itself
> for installing packages.

OK, so you're only providing the netinst ISO?  Somehow I got the
impression that you were providing a separate initramfs.  Sorry for the
irrelevant answer.

> Is that a matter of the appropriate storage drivers not being included,
> or is it the way the VPS provider set up the virtual CD?

It's both!  libvirt can provide (through QEMU) an emulated CD drive
attached to an Intel PATA controller, Intel SATA controller, LSI Logic
SCSI controller or virtio SCSI controller.  I've just verified that the
installer works for all of the first three options, but not virtio.

If there's an option to configure the CD drive to be attached through
one of the other controllers, you should choose that.  But we should
also add virtio drivers to the standard installer initramfs.

Ben.

-- 
Ben Hutchings
Time is nature's way of making sure that
everything doesn't happen at once.



signature.asc
Description: This is a digitally signed message part

Re: Install on remote KVM?

[Richard Hector]

On 11/08/18 22:43, Ben Hutchings wrote:
> On Sat, 2018-08-11 at 20:14 +1200, Richard Hector wrote:
>> Hi - I hope I'm in the right place; feel free to redirect me.
>>
>> I want to install on a KVM-based VPS, using an ordinary installer (ie
>> not using the image provided).
>>
>> I used the provider's method to provide an ISO, and supplied the
>> standard amd64 netinst image - it boots fine, but can't find the 'cdrom'
>> afterwards. They suggest the netinst image doesn't have the drivers for
>> the KVM virtual cdrom - does that sound right? Are there alternative
>> images that would?
> [...]
> 
> I think you are confusing netinst with netboot.
> 
> A netboot installer image is an initramfs with input, graphics and
> network drivers included, but not storage drivers.  It downloads
> additional installer components from the network, not from local
> storage.
> 
> A netinst installer image is a disk image.  It includes one or more
> boot loaders, kernels, and initramfses; and additional installer
> components.  The initramfs additionally includes storage drivers.
> 
> If the netboot method doesn't work for you (maybe network auto-
> configuration doesn't work properly in this VPS?) you could try
> extracting the kernel (vmlinuz) and initramfs (initrd.img) from the
> netinst installer image and providing those instead of the netboot
> images.

Thanks Ben.

I'm mostly familiar with the netinst image, and it's what I generally
use to install on real hardware.

I'm less familiar with netboot, but have used it for PXE installs (right?)

What I'm missing is how I can use either of them on a remote KVM VPS,
where I get to see the boot process on some kind of remote console, and
I have the opportunity to provide a bootable ISO, but not much else.

I've tried providing the netinst ISO, and it boots but can't find itself
for installing packages. Is that a matter of the appropriate storage
drivers not being included, or is it the way the VPS provider set up the
virtual CD?

I've used virt-install on my own KVM machines, which I think does
something similar to a netboot, but I'm not sure what exactly (didn't
make much progress reading the source, unfortunately). I can't use that
method exactly, because I don't have raw access to the host machine.

I don't know how I could use netboot in this case, but any suggestions
are welcome.

I think they're using OnApp for managing this, if that helps - at least
that's the name that shows up with the prebuilt templates. I could of
course use their Stretch template, but I'd rather start clean if I can -
and possibly make some custom partitioning and filesystem choices.

Thanks,
Richard



signature.asc
Description: OpenPGP digital signature

Re: Install on remote KVM?

[Ben Hutchings]

On Sat, 2018-08-11 at 20:14 +1200, Richard Hector wrote:
> Hi - I hope I'm in the right place; feel free to redirect me.
> 
> I want to install on a KVM-based VPS, using an ordinary installer (ie
> not using the image provided).
> 
> I used the provider's method to provide an ISO, and supplied the
> standard amd64 netinst image - it boots fine, but can't find the 'cdrom'
> afterwards. They suggest the netinst image doesn't have the drivers for
> the KVM virtual cdrom - does that sound right? Are there alternative
> images that would?
[...]

I think you are confusing netinst with netboot.

A netboot installer image is an initramfs with input, graphics and
network drivers included, but not storage drivers.  It downloads
additional installer components from the network, not from local
storage.

A netinst installer image is a disk image.  It includes one or more
boot loaders, kernels, and initramfses; and additional installer
components.  The initramfs additionally includes storage drivers.

If the netboot method doesn't work for you (maybe network auto-
configuration doesn't work properly in this VPS?) you could try
extracting the kernel (vmlinuz) and initramfs (initrd.img) from the
netinst installer image and providing those instead of the netboot
images.

Ben.

-- 
Ben Hutchings
Time is nature's way of making sure that
everything doesn't happen at once.



signature.asc
Description: This is a digitally signed message part

Processed: merging 905864 905873

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> merge 905864 905873
Bug #905864 [debootstrap] Ubuntu trusty and xenial are installed with 
merged-/usr by default
Bug #905873 [debootstrap] debootstrap:  trusty and xenial not included in 
merged-usr blacklist
Merged 905864 905873
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
905864: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905864
905873: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905873
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Install on remote KVM?

[Richard Hector]

Hi - I hope I'm in the right place; feel free to redirect me.

I want to install on a KVM-based VPS, using an ordinary installer (ie
not using the image provided).

I used the provider's method to provide an ISO, and supplied the
standard amd64 netinst image - it boots fine, but can't find the 'cdrom'
afterwards. They suggest the netinst image doesn't have the drivers for
the KVM virtual cdrom - does that sound right? Are there alternative
images that would?

As an alternative, when I install on my own KVM server, I use
virt-install, and provide it with the url of the installer, and from
then on it proceeds without needing a CD or other local media. Is there
a way I can boot that on the remote VPS? Perhaps from grub, or from a
minimal ISO?

Any other suggestions?

Thanks,
Richard