Re: d-i user questions, web proxies, automated installation
On Sun, Mar 27, 2022 at 03:43:47PM +0200, Marc Haber wrote: > Hi, > > ... intro ... Welcome > In a small side project I am currently helping a company to design and > implement a deployment process for embedded Debian to a headless > multimedia controller based on amd64 (sic!). Those machines do have HDMI > and USB, but hidden away inside the box so you need to open the case to > access those ports. I would like to avoid that at least for the bulk of > installations. > > Unfortunately, I find the Installation Guide a bit terse on the topic of > preseeded, headless installation, but am prepared to help improving the > document. I would probably need some guidance in finding the "right" way > to do things before writing them down (or, if weirdness turns out to be > a bug, filing the appropriate bugs) and am wondering whether this list > might be the correct medium to answer installation questions regarding > preseeding. I am afraid that technical questions regarding preseeding > will get drowned on debian-user, and probably not find in-depth answers > on debian-user-german. > > After a preseeded installation, a common task is to hand over the > freshly installed system to some kind of configuration management like > puppet. I have seen more or less ugly methods do to that, including a > multi-hundred character long shell string as d-i preseed/late_command > with advanced multi level quoting hell, having an localinit.deb which is > installed along with the base system and which does that initialization > and enrollment after first reboot into the fresly installed system, > staying around for the entire life of the box, etc. Is there any > documentation / opinion about doing this more elegantly? > > And then: Can I have a single pre-seed file that would allow me to > configure the Installer and Apt to choose the first web proxy from a > list of proxies defined in some pre-seed data field, choosing the first > one that happens to be available and responding, falling back to direct > connection if none of the proxies is there? That would allow me to use > the same Installer image for installations in a variety of places with > various differnt proxy setups, avoiding the work to have an Installer > image per site (giving the users the possibility to fail by just > choosing the wrong USB stick). A few days (a week?) ago wrote Phill something like There is https://hands.com/d-i/ and would like revisited together with you for recent release (Yeah, I staid in my email program, didn't visit the archive of the mailinglist for the exact text) > Imagine that I have a remote system in a network that I don't manage, > for example a hosting network. I have a box running some kind of > unnamed linux, a locally provided rescue system, or grml. I am currently > installing in such environments by debootstrapping manually, chrooting > into that system and using my existing configuration management to > "personalize" the installation. Is there a possibility to start d-i > proper in such a system to get all of d-i's magic, probably skipping > partitioning and filesystem creation (that might already been done)? url=the.remote.system as boot parameter. > And last question: How seriously pluggable is the Installer? Can I, for > example, build my own udeb for apt configuration or my own, much less > flexible partitioner and just throw those udebs into an installer tree > and directly use it? Or do I need to delve in-depth into the build > process of the entire Installer to do that? Begin. Start with what is already available. That way you can find "your missing piece". When "found" start wondering about how to optimize development of the new piece. > Thanks for helping. No need to Cc me any more, I am subscribed now. Please consider to have one subject in a thread. > Greetings > Marc Groeten Geert Stappers -- Silence is hard to parse
Re: d-i user questions, web proxies, automated installation
Geert Stappers writes: > On Sun, Mar 27, 2022 at 03:43:47PM +0200, Marc Haber wrote: >> Hi, >> >> ... intro ... > > Welcome > >> In a small side project I am currently helping a company to design and >> implement a deployment process for embedded Debian to a headless >> multimedia controller based on amd64 (sic!). Those machines do have HDMI >> and USB, but hidden away inside the box so you need to open the case to >> access those ports. I would like to avoid that at least for the bulk of >> installations. >> >> Unfortunately, I find the Installation Guide a bit terse on the topic of >> preseeded, headless installation, but am prepared to help improving the >> document. I would probably need some guidance in finding the "right" way >> to do things before writing them down (or, if weirdness turns out to be >> a bug, filing the appropriate bugs) and am wondering whether this list >> might be the correct medium to answer installation questions regarding >> preseeding. I am afraid that technical questions regarding preseeding >> will get drowned on debian-user, and probably not find in-depth answers >> on debian-user-german. >> >> After a preseeded installation, a common task is to hand over the >> freshly installed system to some kind of configuration management like >> puppet. I have seen more or less ugly methods do to that, including a >> multi-hundred character long shell string as d-i preseed/late_command >> with advanced multi level quoting hell, having an localinit.deb which is >> installed along with the base system and which does that initialization >> and enrollment after first reboot into the fresly installed system, >> staying around for the entire life of the box, etc. Is there any >> documentation / opinion about doing this more elegantly? >> >> And then: Can I have a single pre-seed file that would allow me to >> configure the Installer and Apt to choose the first web proxy from a >> list of proxies defined in some pre-seed data field, choosing the first >> one that happens to be available and responding, falling back to direct >> connection if none of the proxies is there? That would allow me to use >> the same Installer image for installations in a variety of places with >> various differnt proxy setups, avoiding the work to have an Installer >> image per site (giving the users the possibility to fail by just >> choosing the wrong USB stick). > > A few days (a week?) ago wrote Phill something like >There is https://hands.com/d-i/ >and would like revisited together with you >for recent release > (Yeah, I staid in my email program, didn't visit the archive of > the mailinglist for the exact text) I did a bit of testing of that at the time and got it working with bookworm, so pushed the new layout up to https://hands.com/d-i/ (which I've not yet tested from there, so it might still have some rough edges) At the very least, the documentation needs to be edited to talk about bookworm rather than jessie. >> Imagine that I have a remote system in a network that I don't manage, >> for example a hosting network. I have a box running some kind of >> unnamed linux, a locally provided rescue system, or grml. I am currently >> installing in such environments by debootstrapping manually, chrooting >> into that system and using my existing configuration management to >> "personalize" the installation. Is there a possibility to start d-i >> proper in such a system to get all of d-i's magic, probably skipping >> partitioning and filesystem creation (that might already been done)? > > url=the.remote.system > as boot parameter. > > >> And last question: How seriously pluggable is the Installer? Can I, for >> example, build my own udeb for apt configuration or my own, much less >> flexible partitioner and just throw those udebs into an installer tree >> and directly use it? Or do I need to delve in-depth into the build >> process of the entire Installer to do that? > > Begin. > Start with what is already available. > That way you can find "your missing piece". > When "found" start wondering about how to optimize development > of the new piece. The whole process is the result of udebs being pulled in by their dependencies, so you can replace parts or all of the process by satisfying the relevant dependencies with your own udebs. Of course, it's not possible to replace the bits that have already run by the time preseeding happens, unless you rebuild the media with your bits. You can also do pretty-much anything directly via preseeding if you don't mind being a little evil -- here's an example of some in-flight brain surgery: replacing bits of a udeb as it is unpacked to change its behaviour (which is OK for testing, but I'd generally recommend doing it properly in a udeb): https://hands.com/d-i/bug/846002/ BTW When it comes to testing new udebs, I have some stuff on salsa that should allow you to concentrate on building your udeb, and then have salsa generate a mini-ISO to tes
Re: Bug#1003366: Processed: Re: Bug#1007838: d-i.debian.org: Installer iSCSI does not work in Debian 11
Hello, On Fri, 2022-03-18 at 11:10 +0100, Cyril Brulebois wrote: > Thanks Eugene, > > Eugene Losowski-Gallagher > (2022-03-18): > > This looks like a duplicate of: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003366 > > Same issue (but with more diagnostics). > > Since one isn't supposed to be using iscsid within the installer, I'd > suggest dropping it from the udeb entirely, so that people don't > waste > time trying to start a daemon that's not supposed to be started > there? > I agree. My recommended setup for `root on iscsi` is documented in the README.Debian. > Alternatively, if that daemon can still be useful within the > installer, > I can look into implementing a double build for open-iscsi, building > with systemd support for the main binary, and without it for the udeb > binary. > > It could certainly be integrated into the installer in some form. But the setup has to be carefully stacked. And there will be multiple configuration scenarios (sw iscsi, hw iscsi, offload, multipath etc) that need to be tested in multiple combinations. Lately, I haven't had the volunteer time that I once had, to commit to these packages. So any help in implementing, testing and maintaining these features is welcome. > In any cases, that's a bit of a side quest, and the real issue is why > the regular installer tools aren't able to set up iSCSI storage. :) > (And that part I'm not familiar enough at this stage to be able to > debug.) I haven't checked this particular case. But, in general, you didn't much need to run the daemon in the installer. You just discover, and then establish the connecitons to the target and be done, for the part of the installer. On real boot, when init fires up iscsid daemon, it'll take over those connections and do the necessary housekeeping thenceforth. This is all around 8 years old setup knowledge across distributions. Not sure what the current approach is. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: This is a digitally signed message part
Bug#1007776: authemtication of wireless network after password input fails
The output of lsmod from the same Debian live is attached. I apologize for the delay. Cheers, Peter The live test is quite useful, thanks for mentioning it. I'm wondering whether this could be due to missing crypto modules inside our image, which I've seen to be the reason for failure to associate from the installer, while the installed system was fine. Any chance you could start the live image again, save the output of `lsmod`, and attach it here, using reply-all? Module Size Used by ctr16384 2 ccm20480 6 si2157 24576 1 si2168 24576 1 m88rs6000t 24576 1 a8293 20480 1 cx2584073728 1 intel_rapl_msr 20480 0 intel_rapl_common 28672 1 intel_rapl_msr snd_hda_codec_realtek 159744 1 snd_hda_codec_generic98304 1 snd_hda_codec_realtek ipmi_ssif 40960 0 ledtrig_audio 16384 1 snd_hda_codec_generic snd_hda_codec_hdmi 73728 1 skx_edac 24576 0 nfit 77824 1 skx_edac snd_hda_intel 57344 5 cx23885 208896 1 libnvdimm 196608 1 nfit snd_intel_dspcfg 28672 1 snd_hda_intel altera_ci 20480 1 cx23885 soundwire_intel45056 1 snd_intel_dspcfg tda18271 53248 1 cx23885 soundwire_generic_allocation16384 1 soundwire_intel altera_stapl 36864 1 cx23885 x86_pkg_temp_thermal20480 0 iwlmvm339968 0 snd_soc_core 315392 1 soundwire_intel intel_powerclamp 20480 0 m88ds3103 40960 2 cx23885 coretemp 20480 0 i2c_mux16384 2 m88ds3103,si2168 mac80211 983040 1 iwlmvm kvm_intel 327680 0 tveeprom 28672 1 cx23885 snd_compress 32768 1 snd_soc_core cx2341x32768 1 cx23885 soundwire_cadence 36864 1 soundwire_intel videobuf2_dvb 16384 1 cx23885 kvm 921600 1 kvm_intel libarc416384 1 mac80211 snd_hda_codec 172032 4 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek dvb_core 155648 4 m88ds3103,altera_ci,cx23885,videobuf2_dvb rc_core61440 1 cx23885 videobuf2_dma_sg 16384 1 cx23885 videobuf2_memops 20480 1 videobuf2_dma_sg irqbypass 16384 1 kvm snd_hda_core 110592 5 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek videobuf2_v4l2 36864 1 cx23885 videobuf2_common 65536 3 videobuf2_v4l2,cx23885,videobuf2_dvb snd_hwdep 16384 1 snd_hda_codec iwlwifi 294912 1 iwlmvm videodev 286720 5 cx2341x,videobuf2_v4l2,videobuf2_common,cx23885,cx25840 soundwire_bus 90112 3 soundwire_intel,soundwire_generic_allocation,soundwire_cadence rapl 20480 0 mc 61440 6 videodev,si2157,videobuf2_v4l2,dvb_core,videobuf2_common,cx25840 eeepc_wmi 16384 0 snd_pcm 135168 9 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,soundwire_intel,snd_compress,snd_soc_core,cx23885,snd_hda_core intel_cstate 20480 0 cfg80211 970752 3 iwlmvm,iwlwifi,mac80211 asus_wmi 45056 1 eeepc_wmi snd_timer 49152 1 snd_pcm battery20480 1 asus_wmi intel_uncore 176128 0 iTCO_wdt 16384 0 efi_pstore 16384 0 sparse_keymap 16384 1 asus_wmi pcspkr 16384 0 acpi_ipmi 20480 0 snd 110592 22 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_compress,snd_soc_core,cx23885,snd_pcm intel_pmc_bxt 16384 1 iTCO_wdt iTCO_vendor_support16384 1 iTCO_wdt intel_wmi_thunderbolt20480 0 rfkill 28672 7 asus_wmi,cfg80211 wmi_bmof 16384 0 tpm_crb20480 0 soundcore 16384 1 snd watchdog 28672 1 iTCO_wdt sg 36864 0 ipmi_si73728 1 ipmi_devintf 20480 0 ipmi_msghandler 118784 4 ipmi_devintf,ipmi_si,acpi_ipmi,ipmi_ssif mei_me 45056 0 tpm_tis16384 0 tpm_tis_core 28672 1 tpm_tis tpm73728 3 tpm_tis,tpm_crb,tpm_tis_core mei 139264 1 mei_me ioatdma61440 0 rng_core 16384 1 tpm evdev 28672 10 acpi_tad 20480 0 msr16384 0 fuse 167936 3 configfs 57344 1 efivarfs 16384 1 ip_tables 32768 0 x_tables 53248 1 ip_tables autofs453248 2 squashfs 69632 1 loop 40960 2 overlay 143360
Bug#1008587: installation-reports: dist-upgrade to sid works but autoremove takes out most of the Mate DE
Package: installation-reports Severity: important X-Debbugs-Cc: kneedragon1...@gmail.com (Please provide enough information to help the Debian maintainers evaluate the report efficiently - e.g., by filling in the sections below.) Boot method: netinstall-virtualmachine Image version: debian-11.3.0-amd64-netinst.iso Date: Machine: i7-6700-non-k Partitions: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [ ] Detect network card:[ ] Configure network: [ ] Detect media: [ ] Load installer modules: [ ] Clock/timezone setup: [ ] User/password setup:[ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: https://www.debian.org/Bugs/Reporting.en.html .. and I don't know that it is appropriate. Allow me to explain. I have a copy of Debian in a virtualbox, on a machine running Mint as the host. I have converted to sid, so my sources.list looks like ~ -- deb http://ftp.us.debian.org/debian/ sid main deb-src http://ftp.us.debian.org/debian/ sid main --- ~ I then go sudo apt dist-upgrade, and I get sid, and roughly 1 GB of left-over files, and apt encourages me to remove them by ~ sudo apt autoremove ~ all perfectly normal. What happens next is I can't reboot, I get a TTY. I can force a startx, but many of my Mate packages are gone. So an effort to manually reinstall mate, results in a dependency error, the version of mate to be installed requires an earlier version of python and you can't install that... I have made a clone of that install before I ran the autoremove and tried various fixes but so far I have been stumped. As long as I don't run the autoremove I have a perfectly functional sid + Mate, but there's about a GB of stuff I should be able to autoremove, and I can't... Sorry this doesn't comply with your format request, but in the circumstances, I think an effort to make it fit would simply confuse the problem. Yours respectfully, Mike Thompson. .> Please make sure that any installation logs that you think would be useful are attached to this report. Please compress large files using gzip. -- Package-specific info: == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="11 (bullseye) - installer build 20210731+deb11u3" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux debian 5.10.0-13-amd64 #1 SMP Debian 5.10.106-1 (2022-03-17) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC [Natoma] [8086:1237] (rev 02) lspci -knn: 00:01.0 ISA bridge [0601]: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] [8086:7000] lspci -knn: 00:01.1 IDE interface [0101]: Intel Corporation 82371AB/EB/MB PIIX4 IDE [8086:7111] (rev 01) lspci -knn: Kernel driver in use: ata_piix lspci -knn: Kernel modules: ata_piix, ata_generic lspci -knn: 00:02.0 VGA compatible controller [0300]: InnoTek Systemberatung GmbH VirtualBox Graphics Adapter [80ee:beef] lspci -knn: Subsystem: VMware Device [15ad:0405] lspci -knn: 00:03.0 Ethernet controller [0200]: Intel Corporation 82540EM Gigabit Ethernet Controller [8086:100e] (rev 02) lspci -knn: Subsystem: Intel Corporation PRO/1000 MT Desktop Adapter [8086:001e] lspci -knn: Kernel driver in use: e1000 lspci -knn: Kernel modules: e1000 lspci -knn: 00:04.0 System peripheral [0880]: InnoTek Systemberatung GmbH VirtualBox Guest Service [80ee:cafe] lspci -knn: 00:05.0 Multimedia audio controller [0401]: Intel Corporation 82801AA AC'97 Audio Controller [8086:2415] (rev 01) lspci -knn: Subsystem: Dell Device [1028:0177] lspci -knn: Kernel driver in use: snd_intel8x0 lspci -knn: Kernel modules: snd_intel8x0 lspci -knn: 00:06.0 USB controller [0c03]: Apple Inc. KeyLargo/Intrepid USB [106b:003f] lspci -knn: Kernel driver in use: ohci-pci lspci -knn: Kernel modules: ohci_pci lspci -knn: 00:07.0 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ACPI [8086:7113] (rev 08) lspci -knn: 00:0d.0 SATA controller [0106]: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) SATA Controller [AHCI mode] [8086:2829] (rev 02) lspci -knn: Kernel driver in use: ahci lspci -knn: Kernel modules: ahci usb-list: usb-list: Bus 01 Device 01: OHCI PCI host controller [1d6b:0001] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 00 usb-list:Manufacturer: Linux 5.10.0-13-amd64 ohci_hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub usb-list: usb-list: Bus 01 Device 02: USB Tablet [80ee:0021] usb-list:Level 01 Parent 01 Port 00 Class
