Bug#806852: debian-installer: Rescue/Emergency shell unusable with locked root account
Package: debian-installer Severity: normal Dear Debian Installer Developers, Currently if a user chooses to lock the root account during installation, they are in for an unpleasant surprise when attempting to fix boot-time issues using a rescue/emergency shell. In this case, the user will be presented with the following message: Cannot open access to console, the root account is locked. See sulogin(8) man page for more details. Then boot will either continue or fail without running a root shell (based on whether the system is usable without intervention). This issue was reported against util-linux, which previously carried a patch to unconditionally allow passwordless root login through sulogin, in bug 789950.[1] The util-linux portion of the issue was fixed when util-linux upstream added the "--force" option to sulogin to provide this behavior.[2] However, the issue still remains for users, since none of the init systems or init scripts call sulogin with this option. Unconditionally adding "--force" to every invocation of sulogin is not an ideal solution, since it presents a security issue for kiosks and other computers which are not physically secure if users can provoke an emergency shell during boot (perhaps ^C during routine fsck?). However, this was the previous behavior, so it may be considered an acceptable risk by some/many. This is a tricky issue to fix without unconditional "--force", since it requires coordination across multiple packages. Andreas Henriksson presented the current thinking in Comment 63 of bug 789950[3], including having d-i install an override snippet for systemd to use the "--force" option when root is locked via the installer. This seems like a very clean solution for systemd, but, of course, it doesn't address the other init systems or init scripts (such as checkroot.sh) which call sulogin. It may also cause issues for users who lock or unlock the root account after installation, if they expect unconditional login or users not expecting unconditional login when choosing the option during installation. After considering the issue a bit, the best alternative that I could come up with would be to create a convention for marking the root account as locked-but-emergency-accessible or locked-and-always-inaccessible in passwd/shadow (e.g. by using a particular symbol in the password field to denote either case) then updating the init systems and init scripts to check this condition before deciding whether to invoke sulogin with "--force" (or, alternatively, to carry a Debian-specific patch to get this behavior by default in sulogin, similar to the previous situation for better or worse). But, of course, adding such a convention is a lot of work to implement and document, and introduces meaning where there was none before, which is not ideal. If anyone has other ideas, or if the general consensus is to only worry about the systemd case (and make the others unconditionally use --force or risk breakage), at least for now, that would be fine by me. Thanks for considering, Kevin 1. https://bugs.debian.org/789950 2. https://github.com/karelzak/util-linux/pull/200 3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789950#63
Bug#806849: debian-installer: d-i fails to install grub2 correctly for efi system using encrypted LVM
Package: debian-installer Version: stretch alpha 4 Severity: important Tags: d-i Dear Maintainer, I have a new System76 Oryx Pro laptop using efi boot. Ubuntu installs successfully but I can't get debian to install using encrypted LVM. The laptop has an nvme device which requires efi boot so I can't just disable it. Here are my repro steps: 1. Boot using netinst (tried both stable and testing, stable doesn't work at all I think due to efi?) 2. Performed normal install (tried both text and gui) 3. Included proprietary firmware for wifi from usb key when prompted 4. selected encrypted LVM with separate home partition, changed root partition to 20GB and made some other lvm adjustments 5. proceeded to install base system successfully 6. when it comes time to install grub, it fails. no better error message provided, nothing in /var/logs either The laptop came with working ubuntu on it, and I was able to boot from an ubuntu live CD. I was able to chroot into the installed system from here and everything looked right, but I still haven't figured out the right incantation of grub to get it to install so it will unlock my encrypted drive (right now, it does boot off the nvme device but drops me to a grub prompt). Short of becoming a grub wizard, the best way to get my system the way I want it is probaly to fix the installer =| if there is anything I can do to provide extra information, please do not hesitate to contact me. I also hang out on freenode as cmyers. Thanks! -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.1.5-x86_64-linode61 (SMP w/3 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Re: Backports installed without prompt if not in base suite: bug or feature ?
(see the other mail for more on this topic and also hopefully as a clearup of what was meant initially; just picking some semi-unique element here) On Tue, Dec 01, 2015 at 03:39:25PM +0100, Philip Hands wrote: > David Kalnischkies writes: > > Personally, I am in the "enable backports by default" camp as I believe > > that most people who issue a "apt install foo" want foo installed and do > > not care enough about stable vs. backports to say 'no' to the solution > > even IF they would know at the right moment that foo comes from > > backports (same for non-free) > > I'd say that non-free is very different from backports in this context. > > One might enable non-free solely to get a wifi driver, and want nothing > else from it. One might disagree with the Debian position on GFDL and > want all the GNU documentation, while wanting nothing non-free. Which is exactly how some use backports: only wanting a very specific package, not the whole zoo. Its also how the majority of sources a user can have are supposed to operate as pretty much only "Debian my current release main" can be considered a catch all while all the rest was likely added to get this or that package only. > Such users are going to want updates to any of those packages, but > they're not going to want to get another single non-free package unless > they explicitly ask for it (with -t non-free or foo/non-free) The solution for those users is pinning packages from their undesired source to -1 (or lower, which translates exactly to "this is never a candidate") and pin specific packages (those which they have installed from there) to 100 (or slightly higher). That is cumbersome to work with, but it works. Its also a surefire way of running into miles long error messages you have to be a wizard for to decrypt. > Assuming we can make non-free behave in this way (so that upgrades are > automatic, but new installations are only by request), then it seems > possible that some people would also appreciate that feature in > backports. I already described that this is impossible with preferences alone and you can read all about it in the manpage for it: apt_preferences (Reading it carefully you will realize that this something most people describe as "upgrade" doesn't exist, but is just an happy accident of how pin values are chosen as by the time a new version is online nobody knows anymore where the old version came from…) I guess we could come up with some hardcoded logic in apt, but that wouldn't work for everything else be it aptitude, packagekit or whatever people use nowadays to install stuff and I don't see why backport or non-free would be special snowflakes here given that many users have many sources they only want very specific packages from. I further guess that we could hardcode a logic in libapt similar to the one described above with -1 and 100 pins, but that breaks tools which are supposed to flip to less preferred sources if needed like experimental buildds for example (see next), gives you the "perks" mentioned above and would be an all around stranger in an already complicated topic code and documentation wise. > If nothing else, having it as a configuration option that we can enable > by default would allow the d-i team to enable backports with confidence > knowing that this would not result in any surprised users. This imagined user isn't surprised that she gets a solution offered which includes packages from a less preferred source – aptitude does this all the time and was therefore also used to resolve dependencies on experimental buildds (now its apt with an external solver which has the same properties). In fact, we have plenty of bugreports detailing that users are surprised that apt is /NOT/ taking a package from a less desireable source. The external solver protocol for APT (EDSP) has an option to free a resolver from even more preferences concerns as I fought hard to not have it as the default… Your imagined user is surprised that she isn't told about such things before hand in a simple way (you can look for yourself with show or policy, or look at the download process, but that isn't simple and the later a bit late). That is a display problem, which as said, we are slowly but steadily working on in apt. Solving this with an option (our solution to everything) or just not enabling it by default isn't a solution: A user will just disable the option or enable the repository and will still be surprised by this. Even if you call the option I::want::apt::to::surprise::me=true. (People are repeatly told that recommends shouldn't be disabled, still way too many people do it and complain loudly if something breaks as that is a one time action with gets you into trouble only many months later if at all – and broken recommends are actually displayed…) Best regards David Kalnischkies signature.asc Description: PGP signature
Re: Backports installed without prompt if not in base suite: bug or feature ?
On Tue, Dec 01, 2015 at 05:00:47PM +0100, Rhonda D'Vine wrote: > * David Kalnischkies [2015-11-30 22:22:08 CET]: > > In other words: If you have experimental sources on your stable system, > > packages new in experimental will be automatically installed, too, if > > requested without any force needed (it won't be upgraded through as > > installed is pinned 100 which is higher than 1). Everything else would > > be against how pinning works – and its like that for 17 years now, so it > > can't be all bad – aka: feature. > > I really consider the reasoning of "it always has been that way" kinda > disturbing, frankly spoken. It has been used in very bad areas over the > history of human development, please don't use it. That's not really an > argument. All what I was trying to say is that the apt_preferences behaviour I explaining in this mail isn't a new invention, but exists since the beginning of apt in this way as a core design principle (in my eye), using the "it can't be all bad" as a reference to the fact that apt is still used while a lot of things with different designs fell out of favour because decisions in opensource aren't made by big white guys with power to have you killed if you look in the wrong direction, but by users who simply either use it or not. I wasn't advocating $very-bad-area because humanity did that for centuries and, frankly spoken, I am quite shocked its even suggested I would be – not only because that offends me, but it also suggests the work needed to stop $very-bad-area is even only remotely comparable to changing a piece of software – after all a single person can replace all of apt completely in a few days (q.e.d.: cupt) without fearing any negative consequences (beside users actually using it perhaps). (yes, I wrote that section last as reading what I had to respond to alone made me super angry already and I didn't want to paint the whole mail in this emotion) > > I don't think this is wrong, given that you have this source enabled > > you want that package installed, so not offering this solution would be > > a disservice. Pretty much the same thing as with non-free. > > And with my backports hat on I consider the comparison of backports > with non-free quite disrespectful, too ... I am sorry. I was using non-free (as it was established in the context already) as a means to broaden the view. Not in the "backport or non-free, its all the same crap" sense, but in the "I see little difference in the need to tell the user that a package comes from backports compared to that it comes from non-free given that both aren't the default source". An earlier draft was talking about experimental, various third-party repositories, future bikesheds and what have you, but I cut that out too reduce length and so ended up using only backports and non-free as the probably most relatable examples on opposite sites of the sources spectrum… As it is now obvious to me I cut so much, that its actually easy to get the wrong idea… so, again, I am sorry, it wasn't meant that way. > > Personally, I am in the "enable backports by default" camp as > > I believe that most people who issue a "apt install foo" want foo > > installed and do not care enough about stable vs. backports to say > > 'no' to the solution even IF they would know at the right moment > > that foo comes from backports (same for non-free) > > Again - please do *not* compare backports with non-free. And that you > consider people not to care is a fair bit disturbing. The objection to > putting backports into the default install should be reason enough for > you that there are people who *do* care and you shouldn't disregard > their opinion with a statement of people don't care anyway. I was saying "personally", I mentioned camp implying that there is (at least) another, words like "believe" and "most" aren't really very definitiv words and further down the line I even explicitly acknowledged the status quo as different and that I can agree with it even through I have a different opinion. I don't think that qualifies as disregarding opinions and don't caring, but I will assume that you only said that as you were expecting me to be like it after reading my previous statements (incorrectly, by my own fault). The whole paragraph was meant as full disclosure to avoid the inherent "display problem" of coming from a certain view point (aka source), but no indication of this (and yes, this is a "pun"). So, with that said, lets try again: I don't think its a good idea to change the behaviour I described explicitly in the last mail as plenty of users (including me) and tools actually depend on and like this behaviour. It is so natural that even the experimental buildds are using it (via aptitude or aspcud now) in that they take the liberty of using package versions from less preferred (declared via means of apt_preferences ex- or implicitly) sources to provide dependency resolutions a user can accept or not instead
Re: Trying to install Debian on an Asus VivoTab Smart ME400C
On Tue, 2015-12-01 at 23:49 +0100, Santiago Garcia Mantinan wrote: > Hi! > > A friend gave me this tablet which has a broken glass + digitizer so I > thought I could maybe make some use of it under Debian. > > The device is a 32 bits Atom based uefi machine, so I got first jessie's > installer and then a weekly stretch build but on both of them I could get to > the first menu but then keyboard stopped working (keyboard and boot pen > drive are plugged to a usb HUB). > > To try to get more info on the USB problem I thought I could copy an > installed uefi debian to the usb pen drive that I was using, so I installed > it on a uefi virtualbox and then copied the raw disk to the pen drive. > > The pen boots but after it loads kernel, initrd it fails to locate the root > image (it is on USB and we have no USB, so this was expected) but the > machine also has an sd card reader which seemed detected, so I copied the > same virtualbox image to the SD and booted of the USB (doesn't seem to allow > to boot from the SD) then the kernel and initrd are loaded and root is > found and debian booted. > > The image and kernel of Debian I'm running are Jessie's and I had an > rc.local which I was intending to gather some info, but unfortunately the > machine seems to hang without even finishing booting. > > I'll try to paste here what I've got till now, what seemed weird to me is > that I didn't see any trace of the USB or the WiFi devices. The firmware appears to have set up the PCI root and ACPI tables wrongly: [...] > Dec 2 09:29:28 debian kernel: [0.115143] PCI: MMCONFIG for domain > [bus 00-ff] at [mem 0xe000-0xefff] (base 0xe000) > Dec 2 09:29:28 debian kernel: [0.120549] [Firmware Info]: PCI: MMCONFIG > at [mem 0xe000-0xefff] not reserved in ACPI motherboard resources > Dec 2 09:29:28 debian kernel: [0.120555] PCI: not using MMCONFIG [...] > Dec 2 09:29:28 debian kernel: [0.139017] pci :00:02.0: can't claim > BAR 2 [mem 0xe000-0xefff]: no compatible bridge window [...] > I have some ideas of how to continue, installing a 4.3 kernel, maybe the 686 > branch, not the 586 one, You should definitely use 686-pae on this processor, not 586. But that's not likely to change the behaviour. It is possible that more recent kernel versions have a workaround but I don't see one. > but I thought commenting here first as I was > expecting things to be on the pci bus but doesn't seem to be the case. > > Any ideas of how to continue? > > Any other info I can try to gather and provide? Some kernel parameters to try: pci=assign-busses pci=realloc or together: pci=assign-busses,realloc Ben. -- Ben Hutchings Theory and practice are closer in theory than in practice. - John Levine, moderator of comp.compilers signature.asc Description: This is a digitally signed message part
Trying to install Debian on an Asus VivoTab Smart ME400C
Hi! A friend gave me this tablet which has a broken glass + digitizer so I thought I could maybe make some use of it under Debian. The device is a 32 bits Atom based uefi machine, so I got first jessie's installer and then a weekly stretch build but on both of them I could get to the first menu but then keyboard stopped working (keyboard and boot pen drive are plugged to a usb HUB). To try to get more info on the USB problem I thought I could copy an installed uefi debian to the usb pen drive that I was using, so I installed it on a uefi virtualbox and then copied the raw disk to the pen drive. The pen boots but after it loads kernel, initrd it fails to locate the root image (it is on USB and we have no USB, so this was expected) but the machine also has an sd card reader which seemed detected, so I copied the same virtualbox image to the SD and booted of the USB (doesn't seem to allow to boot from the SD) then the kernel and initrd are loaded and root is found and debian booted. The image and kernel of Debian I'm running are Jessie's and I had an rc.local which I was intending to gather some info, but unfortunately the machine seems to hang without even finishing booting. I'll try to paste here what I've got till now, what seemed weird to me is that I didn't see any trace of the USB or the WiFi devices. My rc.local logged this modules loaded: nls_utf8 12416 1 nls_cp437 12417 1 vfat 16967 1 fat52640 1 vfat eeepc_wmi 12536 0 asus_wmi 22333 1 eeepc_wmi sparse_keymap 12730 1 asus_wmi rfkill 18415 1 asus_wmi video 17791 1 asus_wmi evdev 17137 2 efi_pstore 12709 1 pcspkr 12531 0 coretemp 12686 0 efivars12993 1 efi_pstore wmi17147 1 asus_wmi tpm_tis17063 0 tpm26879 1 tpm_tis button 12824 0 battery13164 0 int3403_thermal12652 0 acpi_cpufreq 12831 0 ac 12627 0 processor 23285 2 acpi_cpufreq fuse 77518 1 autofs430769 2 ext4 430321 1 crc16 12327 1 ext4 mbcache12892 1 ext4 jbd2 68770 1 ext4 mmc_block 30463 3 thermal17343 0 thermal_sys27657 4 video,thermal,processor,int3403_thermal sdhci_acpi 12714 0 sdhci 34680 1 sdhci_acpi mmc_core 91888 3 mmc_block,sdhci,sdhci_acpi i2c_hid17210 0 hid85096 1 i2c_hid i2c_core 37002 1 i2c_hid And this lspci info: 00:00.0 0600: 8086:08c0 (rev 05) Subsystem: 1043:8562 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- [disabled] Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [b0] Vendor Specific Information: Len=07 Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit- Address: Data: 00:03.0 0480: 8086:08d0 (rev 05) Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- reserved Dec 2 09:29:28 debian kernel: [0.00] e820: remove [mem 0x000a-0x000f] usable Dec 2 09:29:28 debian kernel: [0.00] e820: last_pfn = 0x7edff max_arch_pfn = 0x10 Dec 2 09:29:28 debian kernel: [0.00] MTRR default type: uncachable Dec 2 09:29:28 debian kernel: [0.00] MTRR fixed ranges enabled: Dec 2 09:29:28 debian kernel: [0.00] 0-9 write-back Dec 2 09:29:28 debian kernel: [0.00] A-B uncachable Dec 2 09:29:28 debian kernel: [0.00] C-E write-back Dec 2 09:29:28 debian kernel: [0.00] F-F uncachable Dec 2 09:29:28 debian kernel: [0.00] MTRR variable ranges enabled: Dec 2 09:29:28 debian kernel: [0.00] 0 base 0 mask 08000 write-back Dec 2 09:29:28 debian kernel: [0.00] 1 base 07F00 mask 0FF00 uncachable Dec 2 09:29:28 debian kernel: [0.00] 2 base 07EE0 mask 0FFE0 uncachable Dec 2 09:29:28 debian kernel: [0.00] 3 base 07EDFF000 mask 0F000 uncachable Dec 2 09:29:28 debian kernel: [0.00] 4 disabled Dec 2 09:29:28 debian kernel: [0.00] 5 disabled Dec 2 09:29:28 debian kernel: [0.00] 6 disabled Dec 2 09:29:28 debian kern
Re: win32-loader_0.7.11_source.changes ACCEPTED into unstable
Hi, Debian FTP Masters (2015-11-30): > Accepted: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Format: 1.8 > Date: Mon, 30 Nov 2015 19:25:40 +0100 > Source: win32-loader > Binary: win32-loader > Architecture: source > Version: 0.7.11 > Distribution: unstable > Urgency: medium > Maintainer: Debian Install System Team > Changed-By: Didier Raboud > Description: > win32-loader - Debian-Installer loader for win32 > Closes: 806447 > Changes: > win32-loader (0.7.11) unstable; urgency=medium > . >* Update Vcs-Browser URLs This change is: -Vcs-Browser: http://anonscm.debian.org/gitweb/?p=d-i/win32-loader.git +Vcs-Browser: https://anonscm.debian.org/git/d-i/win32-loader.git I don't have anything against such changes in general, but I think it would make sense to have them done on all d-i packages at the same time (maybe after discussion/checks, see debhelper bump a while ago). But anyway, this particular change is not OK: | kibi@chloe:~$ wget https://anonscm.debian.org/git/d-i/win32-loader.git -O - | --2015-12-01 20:55:03-- | https://anonscm.debian.org/git/d-i/win32-loader.git | Resolving anonscm.debian.org (anonscm.debian.org)... 5.153.231.21 | Connecting to anonscm.debian.org (anonscm.debian.org)|5.153.231.21|:443... connected. | HTTP request sent, awaiting response... 404 Not Found | 2015-12-01 20:55:03 ERROR 404: Not Found. | Mraw, KiBi. signature.asc Description: Digital signature
Re: Backports installed without prompt if not in base suite: bug or feature ?
* David Kalnischkies [2015-11-30 22:22:08 CET]: > In other words: If you have experimental sources on your stable system, > packages new in experimental will be automatically installed, too, if > requested without any force needed (it won't be upgraded through as > installed is pinned 100 which is higher than 1). Everything else would > be against how pinning works – and its like that for 17 years now, so it > can't be all bad – aka: feature. I really consider the reasoning of "it always has been that way" kinda disturbing, frankly spoken. It has been used in very bad areas over the history of human development, please don't use it. That's not really an argument. > I don't think this is wrong, given that you have this source enabled and > you want that package installed, so not offering this solution would be > a disservice. Pretty much the same thing as with non-free. And with my backports hat on I consider the comparison of backports with non-free quite disrespectful, too ... > Personally, I am in the "enable backports by default" camp as I believe > that most people who issue a "apt install foo" want foo installed and do > not care enough about stable vs. backports to say 'no' to the solution > even IF they would know at the right moment that foo comes from > backports (same for non-free) Again - please do *not* compare backports with non-free. And that you consider people not to care is a fair bit disturbing. The objection to putting backports into the default install should be reason enough for you that there are people who *do* care and you shouldn't disregard their opinion with a statement of people don't care anyway. > but I can perfectly understand that some want to hold that off until > everyone actually has the information at the right moment. [That is > not to say that the treatment by a user doesn't change if she knows – > I prefer potentially buggy open firmware over closed one for example > and given the choice of cake via backports or no cake, I will opt for > backports accepting less service than stable, So you are applying your own opinion to all users - including the ones that explicitly tell you that they care differently. Way to go. Please understand that others might have different opinions on that and that those views are valid, too. So long, Rhonda -- Fühlst du dich mutlos, fass endlich Mut, los | Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden Fühlst du dich machtlos, geh raus und mach, los | 23.55: Alles auf Anfang Fühlst du dich haltlos, such Halt und lass los|
Re: Backports installed without prompt if not in base suite: bug or feature ?
David Kalnischkies writes: ... > Personally, I am in the "enable backports by default" camp as I believe > that most people who issue a "apt install foo" want foo installed and do > not care enough about stable vs. backports to say 'no' to the solution > even IF they would know at the right moment that foo comes from > backports (same for non-free) I'd say that non-free is very different from backports in this context. One might enable non-free solely to get a wifi driver, and want nothing else from it. One might disagree with the Debian position on GFDL and want all the GNU documentation, while wanting nothing non-free. Such users are going to want updates to any of those packages, but they're not going to want to get another single non-free package unless they explicitly ask for it (with -t non-free or foo/non-free) Assuming we can make non-free behave in this way (so that upgrades are automatic, but new installations are only by request), then it seems possible that some people would also appreciate that feature in backports. If nothing else, having it as a configuration option that we can enable by default would allow the d-i team to enable backports with confidence knowing that this would not result in any surprised users. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#806780: --foreign/--second-stage breaks with multiple components
Package: debootstrap
Version: 1.0.75
Severity: normal
Tags: patch
When passing multiple components to --second-stage things fail as debootstrap
tries to open debootstrap.invalid_dists_badger_snake|mushroom-armhf.Packages
rather then seperate Packages file for snake and mushroom.
Fixed in attached patch
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel
Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages debootstrap depends on:
ii wget 1.17-1
Versions of packages debootstrap recommends:
ii debian-archive-keyring 2014.3
ii gnupg 1.4.19-6
debootstrap suggests no packages.
-- no debconf information
>From 6621d8304cb79dcc6e07098caaf6eaa56fe8594a Mon Sep 17 00:00:00 2001
From: Sjoerd Simons
Date: Tue, 1 Dec 2015 09:09:07 +0100
Subject: [PATCH] Fix multiple components usage for --foreign
commit e24e4b006736734e, bug #757819 made resolve_deps and
setup_available in the --foreign case. However this only worked when
using just one component as the USE_COMPONENTS variable is | delimited.
Translate the USE_COMPONENTS variable on the fly from | delimited to
space delimeted to allow multiple components to work again.
Signed-off-by: Sjoerd Simons
---
functions | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/functions b/functions
index 8bef5e6..64d76e4 100644
--- a/functions
+++ b/functions
@@ -1256,14 +1256,14 @@ resolve_deps () {
local ALLPKGS2="";
while [ "$PKGS" != "" ]; do
local NEWPKGS=""
- for c in ${COMPONENTS:-$USE_COMPONENTS}; do
+ for c in ${COMPONENTS:-$(echo ${USE_COMPONENTS} | tr '|' ' ')}; do
local path="dists/$SUITE/$c/binary-$ARCH/Packages"
local pkgdest="$TARGET/$($DLDEST pkg "$SUITE" "$c" "$ARCH" "$m1" "$path")"
NEWPKGS="$NEWPKGS $("$PKGDETAILS" GETDEPS "$pkgdest" $PKGS)"
done
PKGS=$(echo "$PKGS $NEWPKGS" | tr ' ' '\n' | sort | uniq)
local REALPKGS=""
- for c in ${COMPONENTS:-$USE_COMPONENTS}; do
+ for c in ${COMPONENTS:-$(echo ${USE_COMPONENTS} | tr '|' ' ')}; do
local path="dists/$SUITE/$c/binary-$ARCH/Packages"
local pkgdest="$TARGET/$($DLDEST pkg "$SUITE" "$c" "$ARCH" "$m1" "$path")"
REALPKGS="$REALPKGS $("$PKGDETAILS" PKGS REAL "$pkgdest" $PKGS | sed -n 's/ .*REAL.*$//p')"
@@ -1279,7 +1279,7 @@ resolve_deps () {
setup_available () {
local m1="${MIRRORS%% *}"
- for c in ${COMPONENTS:-$USE_COMPONENTS}; do
+ for c in ${COMPONENTS:-$(echo ${USE_COMPONENTS} | tr '|' ' ')}; do
local path="dists/$SUITE/$c/binary-$ARCH/Packages"
local pkgdest="$TARGET/$($DLDEST pkg "$SUITE" "$c" "$ARCH" "$m1" "$path")"
# XXX: What if a package is in more than one component?
--
2.6.2
