Bug#766914: Patch dropping hardware access groups
On Tue, Jan 30, 2018 at 3:32 PM Felipe Sateler wrote: > Control: tags 766914 patch > Control: tags 821424 patch > > Hi, > > Please find attached an (untested) patch dropping the hardware access > groups. > > I have reposted the patch as merge request: https://salsa.debian.org/installer-team/user-setup/merge_requests/1 -- Saludos, Felipe Sateler
Bug#766914: Patch dropping hardware access groups
Control: tags 766914 patch Control: tags 821424 patch Hi, Please find attached an (untested) patch dropping the hardware access groups. Saludos 0001-Drop-several-groups-from-the-default-user-groups.patch Description: Binary data
Re: Bug#872598: udev-udeb: no input in graphical installer
On Sat, Aug 19, 2017 at 9:38 AM, Cyril Brulebois <k...@debian.org> wrote: > Control: tag -1 patch > > Hi, > > (Again, please keep debian-boot@ in copy.) > > Raphael Hertzog <hert...@debian.org> (2017-08-19): >> > I've only quickly glanced at the contents of both packages, and >> > debdiff mentions no obvious issues (file lists are the same). >> >> I believe this is precisely the problem. The new udev-udeb should >> include a new file: >> diff --git a/debian/udev-udeb.install b/debian/udev-udeb.install >> index 6a8e2108f..6758fef06 100644 >> --- a/debian/udev-udeb.install >> +++ b/debian/udev-udeb.install >> @@ -5,6 +5,7 @@ lib/udev/ata_id >> lib/udev/scsi_id >> lib/udev/cdrom_id >> lib/udev/rules.d/50-udev-default.rules >> +lib/udev/rules.d/60-input-id.rules >> lib/udev/rules.d/60-cdrom_id.rules >> lib/udev/rules.d/60-persistent-input.rules >> lib/udev/rules.d/60-persistent-storage.rules >> >> I won't have the time to test this now but I believe it's the problem. > > That's absolutely correct. I've started by copying the file manually into > the netboot-gtk mini.iso, and confirmed the fix. To be extra sure, I've > rebuilt a systemd package with your change, and used the new udev udebs > for a clean build, and that works as well. > > A timely fix would be appreciated, the breakage(s) in the graphical > installer prevented us from releasing debian-installer over the past few > weeks, and it would be great not to wait too long before we're able to do > so, esp. with linux 4.12.6-1 having reached testing lately. > > Thinking about this, I'll check with debian-release@ and I might just > freeze all udeb-producing packages right away. Winter has come. > > >> It would be nice to have a fixed udev soon. Thank you Cyril for the >> investigation! >> >> I wonder if it would be possible to have autopkgtest tests covering >> udev-udeb... > > I'm still new to the whole autopkgtest thing, but from where I stand, the > fact d-i is broken has been known for quite a while; the core issue is > that nobody investigated this before I found some time. An easy way to be > more proactive on the systemd side would be to make sure that new (and/or > deleted) files in the udev and libudev1 binaries are detected by > maintainers (esp. since udev.install uses wildcards for rules files, while > udev-udeb.rules uses a static list), so that the update can be propagated > to the udebs if relevant. --fail-missing is broken on the udeb builds at the moment, so it is not enabled. I'll try to fix this and enable it. This should help catch these sort of issues in the future. -- Saludos, Felipe Sateler
Bug#866614: console-setup-linux: drop dependency on initscripts
On Fri, Jun 30, 2017 at 10:10 AM, Felipe Sateler <fsate...@debian.org> wrote: > Package: console-setup-linux > Version: 1.165 > Severity: minor > Tags: patch > User: pkg-systemd-maintain...@lists.alioth.debian.org > Usertags: initscripts-dep > > The package console-setup-linux Depends on: > > init-system-helpers (>= 1.29~) | initscripts > > Since i-s-h is already at the required version in stable, and i-s-h is > Essential, the alternative is fully superfluous for debian. It would be > nice to > have this dependency dropped for buster. Patch against git is attached > I just noticed the same applies to console-setup-freebsd. The same change should be applied there. -- Saludos, Felipe Sateler
Bug#866614: console-setup-linux: drop dependency on initscripts
Package: console-setup-linux Version: 1.165 Severity: minor Tags: patch User: pkg-systemd-maintain...@lists.alioth.debian.org Usertags: initscripts-dep The package console-setup-linux Depends on: init-system-helpers (>= 1.29~) | initscripts Since i-s-h is already at the required version in stable, and i-s-h is Essential, the alternative is fully superfluous for debian. It would be nice to have this dependency dropped for buster. Patch against git is attached. Saludos -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages console-setup-linux depends on: ii init-system-helpers 1.48 ii kbd 2.0.3-2+b1 pn keyboard-configuration console-setup-linux recommends no packages. Versions of packages console-setup-linux suggests: pn console-setup diff --git a/debian/control b/debian/control index 5857d6c..002a313 100644 --- a/debian/control +++ b/debian/control @@ -71,7 +71,7 @@ Section: utils Priority: optional Architecture: all Multi-Arch: foreign -Depends: kbd (>= 0.99-12) | console-tools (>= 1:0.2.3-16), keyboard-configuration (= ${source:Version}), ${misc:Depends}, init-system-helpers (>= 1.29~) | initscripts +Depends: kbd (>= 0.99-12) | console-tools (>= 1:0.2.3-16), keyboard-configuration (= ${source:Version}), ${misc:Depends} Suggests: console-setup Conflicts: console-setup-freebsd Breaks: console-terminus, console-cyrillic (<= 0.9-11), console-setup (<< 1.71)
Bug#857132: console-setup: additional info needed ?
On Thu, Mar 23, 2017 at 10:58 AM, Anton Zinoviev <an...@lml.bas.bg> wrote: > On Thu, Mar 23, 2017 at 02:37:48PM +0100, Michael Biebl wrote: >> >> In Debian, we don't enable the systemd-vconsole component [1]. > > This is good, but... > >> So there should be no console configuration happening from systemd's >> side. > > ...suppose udev creates a new console. As mentioned by Michael, this is not done by udev or systemd. > Then it has to be initialized > with some font, hasn't it? When it is created, the udev rule should be fired. So cached_setup_font.sh should be invoked again. > From my tests it seems that the font used > for this initialization is the same as the font used on the current > console. Isn't it possible that sometimes this font is set only _after_ > udev has started the script cached_setup_font.sh by the following rule > > ACTION=="add", SUBSYSTEM=="vtconsole", KERNEL=="vtcon*", > RUN+="/etc/console-setup/cached_setup_font.sh" > > however the font of the current console is read _before_ the script > cached_setup_font.sh has had a chance to configure the font? I don't know of any component that does that. Systemd-vconsole, as mentioned by Michael, is not enabled in the debian packages. However, I see the following in cached_setup_font: setfont '/etc/console-setup/cached_Lat15-Fixed16.psf.gz' if ls /dev/fb* >/dev/null 2>/dev/null; then for i in /dev/vcs[0-9]*; do { : setfont '/etc/console-setup/cached_Lat15-Fixed16.psf.gz' } < /dev/tty${i#/dev/vcs} > /dev/tty${i#/dev/vcs} done fi Might it be that /dev/fb* do not exist during boot, and thus the font is not loaded in all ttys? -- Saludos, Felipe Sateler
Bug#768062: Does not take already-selected alternate dependencies into account
On Tue, 04 Nov 2014 07:58:59 -0800 Josh Triplettwrote: > Package: debootstrap > Version: 1.0.64 > Severity: normal > > Please see the analysis in bug 746578. > > The essential package "init" has: > Depends: systemd-sysv | sysvinit-core | upstart > > The test in bug 746578 involved a modified libpam-systemd that had: > Depends: systemd-shim (>= 8-2) | systemd-sysv > > The test invoked debootstrap like this: > debootstrap --print-debs --no-check-gpg --include=libpam-systemd jessie $DIR > $MIRROR > > Given that set of constraints, debootstrap *should* install init, > systemd-sysv, libpam-systemd, and *not* systemd-shim, since systemd-sysv > already satisfies libpam-systemd's dependency. > > In addition to figuring that out automatically, debootstrap should at > least have produced that result if given --exclude=systemd-shim, since > no dependency requires debootstrap to add that back in. Doing a full dependency resolver in debootstrap may be too difficut, but excluding packages after resolution should be possible. Maybe this is enough? diff --git a/debootstrap b/debootstrap index 084a541..a0a6000 100755 --- a/debootstrap +++ b/debootstrap @@ -584,8 +584,6 @@ if am_doing_phase finddebs; then work_out_debs - base=$(without "$base $ADDITIONAL" "$EXCLUDE") - if [ "$RESOLVE_DEPS" = true ]; then requiredX=$(echo $(echo $required | tr ' ' '\n' | sort | uniq)) baseX=$(echo $(echo $base | tr ' ' '\n' | sort | uniq)) @@ -613,6 +611,8 @@ if am_doing_phase finddebs; then fi fi + base=$(without "$base $ADDITIONAL" "$EXCLUDE") + all_debs="$required $base" fi This currently prevents debootstrapping a system with dracut and a linux image installed, as dracut conflicts with initramfs-tools (which in turn is the first alternative on the linux image). Saludos,
Re: Support for merged-/usr now in debootstrap; default for stretch?
On Wed, 14 Sep 2016 16:50:13 +0200, Pierre Chifflier wrote: > On Wed, Sep 14, 2016 at 02:38:09PM +0000, Felipe Sateler wrote: >> On Tue, 13 Sep 2016 22:36:58 +0200, Ansgar Burchardt wrote: >> >> > Hi, >> > >> > debootstrap in unstable can now install with merged-/usr, that is >> > with /bin, /sbin, /lib* being symlinks to their counterpart in /usr. >> > Run >> > >> > debootstrap --merged-usr testing .../testing >> > http://deb.debian.org/debian >> > >> > to give it a try. >> > >> > It has been previously suggested to make this the default for (at >> > least) >> > new installations. I think Russ' earlier mail[1] explains quite well >> > why the "split" between / and /usr doesn't really work out for Debian >> > these days and that trying to maintain it for some configurations >> > (which are not documented) is mostly busy-work. There is also a nice >> > article on LWN[2] summarizing earlier discussions. >> > >> > I found these arguments convincing enough and would like to see the >> > default switched to merged-/usr for Stretch and later. Possibly also >> > switching systems on upgrade to the new scheme (not necessarily >> > already in the Stretch release cycle). >> >> I agree that merging /usr is a good thing to do. We should default to >> that, and at some point force the merge somehow (via the usrmerge >> package? >> ). Ideally, stretch systems that are fresh-installed should have the >> same configuration as stretch-upgraded systems, otherwise confusion >> will ensue. >> >> > Hi, > > Except that breaks having different mount points, which is useful to > enforce different mount options (my /usr is nodev,ro). You seem to misunderstand. The proposal is to move everything from /bin, / sbin, /lib{,64,32,...} into /usr/$dir. It does not prevent having /usr in a separate partition. Please see the references in Ansgar's original mail. > Does this mean this cannot be supported anymore ? It would be a step > backward, security-speaking, if split /usr does not work at all. Split /usr is still supported, but it has to be mounted by the initramfs. All initramfs providers in debian do so for stretch. Even more, having a split /usr that is not mounted by the initramfs is not supported: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830829 -- Saludos, Felipe Sateler
Re: Support for merged-/usr now in debootstrap; default for stretch?
On Tue, 13 Sep 2016 22:36:58 +0200, Ansgar Burchardt wrote: > Hi, > > debootstrap in unstable can now install with merged-/usr, that is with > /bin, /sbin, /lib* being symlinks to their counterpart in /usr. Run > > debootstrap --merged-usr testing .../testing > http://deb.debian.org/debian > > to give it a try. > > It has been previously suggested to make this the default for (at least) > new installations. I think Russ' earlier mail[1] explains quite well > why the "split" between / and /usr doesn't really work out for Debian > these days and that trying to maintain it for some configurations (which > are not documented) is mostly busy-work. There is also a nice article > on LWN[2] summarizing earlier discussions. > > I found these arguments convincing enough and would like to see the > default switched to merged-/usr for Stretch and later. Possibly also > switching systems on upgrade to the new scheme (not necessarily already > in the Stretch release cycle). I agree that merging /usr is a good thing to do. We should default to that, and at some point force the merge somehow (via the usrmerge package? ). Ideally, stretch systems that are fresh-installed should have the same configuration as stretch-upgraded systems, otherwise confusion will ensue. -- Saludos, Felipe Sateler
Bug#796603: Questions about console-setup.service (Re: Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138))
On 18 May 2016 at 17:42, Anton Zinoviev <an...@lml.bas.bg> wrote: > On Wed, May 18, 2016 at 01:33:06PM -0300, Felipe Sateler wrote: >> >> Ok. I see that the rules file appears to invoke the scripts in /etc >> directly. Is this intended > > Yes. The keyboard is configured by /lib/console-setup/keyboard-setup.sh > and the font by the scripts in /etc. > > Notice that /lib/console-setup/console-setup.sh does not run the scripts > in /etc at all. If necessary it runs setupcon. Oh, right. > >> (IOW, shouldn't they invoke the wrappers at /lib/console-setup)? > > Although setupcon is an universal and reliable tool, this cames at a > price --- it is slow. Many people have complained that console-setup > slows down the boot and thats the only reason I decided to use scripts > in /etc instead of setupcon. > > By the way, the only thing /lib/console-setup/console-setup.sh does in > addition to the scripts in /etc is to rebuild the scripts in /etc if > necessary. And it is necessary to rebuild these scripts only if the > sysadmin modifies the console configuration by hand and doesn't run > `setupcon --save-only` afterwards. In this case the wrapper will > rebuild the scripts in /etc during the first reboot. OK, this clarifies things. Thanks. > >> But upstream systemd and udev have pushed for mounting /usr in the >> initramfs for a long time, > > Is there a place where one can learn about such things? AFAIK, there is no document I can point at for this particular thing (which is a shame though). There is a page making the case for the merged /usr (ie, drop the distinction between / and /usr), and this necessitates that /usr is mounted before executing init (because init will live in /usr)[1]. Russ Allbery did a short summary during a recent thread discussing the same /usr merge in debian[2] [1] https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ [2] http://article.gmane.org/gmane.linux.debian.devel.general/206431 > >> Note that because it has no WantedBy line, this service will not be >> actually executed during boot. If the service should run as part of >> normal system boot, it should have either WantedBy=sysinit.target or >> WantedBy=multi-user.target. >> Services WantedBy=sysinit.target will be pulled in both single user >> and multi user boots. Services in multi-user.target will only be >> pulled in multi user boots. > > OK, then it has to be WantedBy=multi-user.target. Rebuilding the > scripts in /etc is not something we want in single user mode. Right, writing to /etc is probably not something that should be done there. -- Saludos, Felipe Sateler
Bug#796603: Questions about console-setup.service (Re: Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138))
On 18 May 2016 at 07:59, Anton Zinoviev <an...@lml.bas.bg> wrote: > On Wed, May 11, 2016 at 01:27:52PM -0300, Felipe Sateler wrote: >> >> Sure. Also, feel free to point me to what you have, and I can comment >> on that as well. > > I've pushed the changes I made in git. The new version of > keyboard-setup.service is more or less unchanged: > > [Unit] > Description=Set the console keyboard layout > DefaultDependencies=no > Before=local-fs-pre.target > Wants=local-fs-pre.target > ConditionPathExists=/bin/setupcon > > [Service] > Type=oneshot > ExecStart=/lib/console-setup/keyboard-setup.sh > RemainAfterExit=yes > > [Install] > WantedBy=sysinit.target This looks good to me. > As for console-setup.service, this script doesn't actually configure the > console (that is on Linux; on FreeBSD it does). Therefore, I removed > the instructions Before=system-getty.slice and WantedBy=sysinit.target. > The actual configuration of the console is accomplished by udev (see > /lib/udev/rules.d/90-console-setup.rules). Ok. I see that the rules file appears to invoke the scripts in /etc directly. Is this intended (IOW, shouldn't they invoke the wrappers at /lib/console-setup)? > >> > What about the following additional instruction: RequiresMountsFor=/usr >> >> It would be redundant, as /usr is guaranteed to be mounted by the >> initramfs (for stretch, both dracut and initramfs-tools do so). It >> would cause no harm, though. >> >> Split-/usr without an initramfs that mounts /usr is not supported and >> is likely to break. > > I suppose this is so only on Debian? In order to support other > nonstandard/future distributions I added this instruction. It does no harm, so it is OK to leave there. But upstream systemd and udev have pushed for mounting /usr in the initramfs for a long time, so it is unlikely a systemd-based system will not have /usr mounted, except as a misconfiguration. > So, now > console-setup.service looks in this way: > > [Unit] > Description=Set console font and keymap > DefaultDependencies=no > After=console-screen.service kbd.service local-fs.target > RequiresMountsFor=/usr > ConditionPathExists=/bin/setupcon > > [Service] > Type=oneshot > ExecStart=/lib/console-setup/console-setup.sh > RemainAfterExit=yes Note that because it has no WantedBy line, this service will not be actually executed during boot. If the service should run as part of normal system boot, it should have either WantedBy=sysinit.target or WantedBy=multi-user.target. Services WantedBy=sysinit.target will be pulled in both single user and multi user boots. Services in multi-user.target will only be pulled in multi user boots. -- Saludos, Felipe Sateler
Bug#796603: Questions about console-setup.service (Re: Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138))
On 11 May 2016 at 11:18, Anton Zinoviev <an...@lml.bas.bg> wrote: > On Wed, Mar 16, 2016 at 03:22:42PM -0300, Felipe Sateler wrote: >> >> > On Sun, Mar 06, 2016 at 02:51:34PM -0300, Felipe Sateler wrote: >> >> >> >> I meant the logic to determine if setupcon or the cached scripts >> >> should be run. If in the future that part is changed (eg, the names >> >> are changed, or more scripts are generated), there is no guarantee >> >> the change will reach users, since they may have modified the init >> >> script. > > Right now I am preparing some changes in console-setup and one of them > is to implement your suggestion to move the logic out of the init > scripts. Excellent. > >> Would you be OK, until further development comes along, to use a >> wrapper unit like this: > > And while I am reviewing your changes, I find (as expected) that there > are things I don't understand. So before I make changes and introduce > bugs, I decided to ask. Sure. Also, feel free to point me to what you have, and I can comment on that as well. > >> [Install] >> WantedBy=sysinit.target > > What is the purpose of this instruction? Wouldn't it be possible to > remove it at least for console-setup.service? WantedBy is the equivalent of the LSB Default-Start directive. This means that when the unit is enabled, it will be pulled in whenever sysinit.target is started. sysinit.target roughly corresponds to runlevel S. In particular, it is both pulled in by multi user and single user boots, which AFAICT is what we want for console-setup. Note that Wants relationships do not mean anything for ordering: this instruction does not specify that console-setup must finish for sysinit.target to be considered active. > > Also, inside console-setup.service I find these: > >> After=console-screen.service kbd.service local-fs.target > > What about the following additional instruction: RequiresMountsFor=/usr It would be redundant, as /usr is guaranteed to be mounted by the initramfs (for stretch, both dracut and initramfs-tools do so). It would cause no harm, though. Split-/usr without an initramfs that mounts /usr is not supported and is likely to break. > >> Before=system-getty.slice > > Nothing really serious is going to happen if this script is executed > after getty. Wouldn't it be better to remove this instruction? The idea behind it was to guarantee console-setup had run before the user could login to a console. Maybe it is not strictly necessary, but I think it provides good user experience. -- Saludos, Felipe Sateler
Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138)
On 24 April 2016 at 16:32, Anton Zinoviev <an...@lml.bas.bg> wrote: > On Fri, Apr 01, 2016 at 08:55:31PM -0300, Felipe Sateler wrote: >> >> I have uploaded a new version. I have not yet, however, secured commit >> rights to d-i git repository. If you want to pull the changes before I >> get the access, you can pull the signed tag from my fork: > > I noticed that you put the files *.service in the package > console-setup-freebsd and (as far as I can tell) this doesn't seem an > oversight but rather done by intention. Why? Yes, it was done on purpose. > > I think that the non-Linux ports of Debian do not use systemd or am I missing > something? No, they do not. But because the -freebsd package is Arch: all, it is still installable on linux archs. So, if by some chance a -freebsd package ends up installed in a linux arch, the cycle would not be reintroduced. The cost would be a few KB extra space wasted on some otherwise useless files. I think the tradeoff is acceptable. I hope that makes sense. -- Saludos, Felipe Sateler
Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138)
On 24 April 2016 at 04:33, Christian PERRIER <bubu...@debian.org> wrote: > > Quoting Felipe Sateler (fsate...@debian.org): > > I have uploaded a new version. I have not yet, however, secured commit > > rights to d-i git repository. If you want to pull the changes before I > > get the access, you can pull the signed tag from my fork: > > > > git pull https://anonscm.debian.org/git/users/fsateler/console-setup.git > > debian/1.141 > > > I just added you to committers : I didn't notice this discussion when > it happened and went on a problem when trying to upload a new version > of the package --> my new version was 1.141 as it was built from git, > and of course it was REJECTed as it conclicted with your upload. > > Would you mind pushing your changes to the D-I git? I'm more confident > in you doing so than me merging from your git repo as my git skills > are.let's say incomplete..:-) Done. I did not reapply the changelog commit though. -- Saludos, Felipe Sateler
Re: Bug#821424: pulseaudio: Do not put normal users on group audio
On 18 April 2016 at 14:59, asu <a...@marian1000.go.ro> wrote: > > > On 04/18/2016 07:36 PM, Felipe Sateler wrote: >> >> Control: reassign -1 debian-installer >> >> On 18 April 2016 at 13:06, Corcodel Marian <a...@marian1000.go.ro> wrote: >> >>> Any way pulseaudio is default sound server on debian and suggest to do >>> not put >>> users on audio group because cross interference with alsa programs, now >>> alsa is >>> for power users and pulseaudio is on default. >> >> Pulseaudio does not add the user to the audio group. I'm guessing the >> installer does, so I reassign there. >> >> > Pulseaudio does not add users but can do erase all users from audio group. We most certainly should not do that. -- Saludos, Felipe Sateler
Re: Bug#821424: pulseaudio: Do not put normal users on group audio
Control: reassign -1 debian-installer On 18 April 2016 at 13:06, Corcodel Marian <a...@marian1000.go.ro> wrote: > Any way pulseaudio is default sound server on debian and suggest to do not put > users on audio group because cross interference with alsa programs, now alsa > is > for power users and pulseaudio is on default. Pulseaudio does not add the user to the audio group. I'm guessing the installer does, so I reassign there. -- Saludos, Felipe Sateler
Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138)
On 19 March 2016 at 06:55, Anton Zinoviev <an...@lml.bas.bg> wrote: > On Wed, Mar 16, 2016 at 03:22:42PM -0300, Felipe Sateler wrote: >> >> Yet another one would be to have setupcon itself detect the existence >> of the cached scripts. > > The only reason there are cached scripts is that people are complaining > that console-setup is slow at boot. The cached scripts contain the > mininum configuration sufficient to configure the console. If we run > setupcon, we don't need cached scripts. > >> Would you be OK, until further development comes along, to use a >> wrapper unit like this: > > Yes and thank you! > >> I plan to do a NMU fixing this bug via a unit like the above, please >> tell me if you want to address this in some other way. > > However, I don't think it is appropriate to do a NMU with such changes. > Instead you should make a regular upload of the package. I don't know > whether you have commit rights in the repository of Debian installer > (where the sources of console-setup are), or not, but in any case I > think you can obtain such rights in no time. I have uploaded a new version. I have not yet, however, secured commit rights to d-i git repository. If you want to pull the changes before I get the access, you can pull the signed tag from my fork: git pull https://anonscm.debian.org/git/users/fsateler/console-setup.git debian/1.141 -- Saludos, Felipe Sateler
Bug#819288: console-setup-linux: keyboard-setup.sh init script (actually, the cached scripts) rely on /tmp, which may not be mounted at early boot
On 26 March 2016 at 06:21, Anton Zinoviev <an...@lml.bas.bg> wrote: > On Sat, Mar 26, 2016 at 12:53:45AM -0300, Felipe Sateler wrote: >> >> The cached scripts rely on the compiled keyboard maps to be present in >> /tmp (presumably by having being saved by setupcon -k). > > Hm, this is totaly unexpected. Normally the cached scripts rely on > compiled keyboard maps in /etc. > > The only reason I can see the cached scripts rely on maps in /tmp is > that /etc/ was read-only when `setupcon --save-only` was executed by > /etc/init.d/console-setup.sh or `dpkg-reconfigure`. > > The cached scripts should never rely on files in /tmp and this is a bug > I will have to fix somehow. However, an important question we have to > investigate here is this: why in your system the cached scripts rely on > files in /tmp. Interesting. Indeed, re-running console-setup.sh (after boot) generates a new cached_setup_keyboard script that uses a file in /etc. Even more, I cannot reproduce the original problem, and cannot find in the code how did this happen in the first place (after all, the script should not have been written to /etc either!) But, maybe setupcon should force remove the cached script if it contains references to /tmp (or better yet, the script does not match /etc/console-setup/cached_*.map.gz) -- Saludos, Felipe Sateler
Bug#819288: console-setup-linux: keyboard-setup.sh init script (actually, the cached scripts) rely on /tmp, which may not be mounted at early boot
Package: console-setup-linux Version: 1.141 Severity: normal Hi, The cached scripts rely on the compiled keyboard maps to be present in /tmp (presumably by having being saved by setupcon -k). However, when /tmp is a separate filesystem, this will never work, as the init script is run to soon, and for memory-backed /tmp it can only work during the same boot. The cached stuff needs to be stored elsewhere. -- System Information: Debian Release: stretch/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-1-amd64 (SMP w/4 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) Versions of packages console-setup-linux depends on: ii init-system-helpers 1.29 ii initscripts 2.88dsf-59.3 ii kbd 2.0.3-2 ii keyboard-configuration 1.141 console-setup-linux recommends no packages. Versions of packages console-setup-linux suggests: ii console-setup 1.141 Versions of packages keyboard-configuration depends on: ii debconf 1.5.59 ii liblocale-gettext-perl 1.07-1+b1 Versions of packages console-setup depends on: ii debconf 1.5.59 ii keyboard-configuration 1.141 ii xkb-data2.17-1 Versions of packages console-setup suggests: ii locales2.22-4 ii locales-all [locales] 2.22-4 ii lsb-base 9.20160110 Versions of packages console-setup-linux is related to: pn console-common ii console-data 2:1.12-5 pn console-tools pn gnome-control-center ii kbd 2.0.3-2 ii systemd 229-3 -- debconf information: * keyboard-configuration/model: Generic 105-key (Intl) PC * keyboard-configuration/store_defaults_in_debconf_db: true * keyboard-configuration/xkb-keymap: us * keyboard-configuration/layout: console-setup/guess_font: keyboard-configuration/ctrl_alt_bksp: false console-setup/charmap47: UTF-8 console-setup/fontsize-fb47: 8x16 keyboard-configuration/unsupported_layout: true * keyboard-configuration/modelcode: pc105 console-setup/store_defaults_in_debconf_db: true * keyboard-configuration/optionscode: * keyboard-configuration/compose: No compose key * keyboard-configuration/layoutcode: us * keyboard-configuration/toggle: No toggling keyboard-configuration/unsupported_config_options: true console-setup/use_system_font: console-setup/fontsize-text47: 8x16 console-setup/fontface47: Fixed * keyboard-configuration/variantcode: * keyboard-configuration/other: keyboard-configuration/unsupported_config_layout: true console-setup/codesetcode: Lat15 keyboard-configuration/unsupported_options: true console-setup/fontsize: 8x16 debian-installer/console-setup-udeb/title: * keyboard-configuration/altgr: The default for the keyboard layout * keyboard-configuration/variant: English (US) * keyboard-configuration/switch: No temporary switch console-setup/framebuffer_only: console-setup/codeset47: # Latin1 and Latin5 - western Europe and Turkic languages
Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138)
On 6 March 2016 at 19:29, Anton Zinoviev <an...@lml.bas.bg> wrote: > Thank you for the useful explanations in your message! Glad they are useful :) > > On Sun, Mar 06, 2016 at 02:51:34PM -0300, Felipe Sateler wrote: >> >> I meant the logic to determine if setupcon or the cached scripts should be >> run. If in the future that part is changed (eg, the names are changed, or >> more scripts are generated), there is no guarantee the change will reach >> users, since they may have modified the init script. > > I see... Yes, you are correct about this. > >> However, this is not exactly the same: if the cached script fails, then >> setupcon would not be run. > > I was just pondering on the different options I had. One of them was > to change the cached script so that it runs setupcon when necessary. Yet another one would be to have setupcon itself detect the existence of the cached scripts. >> Also, I would advise against having different logic in the systemd services >> than in the init scripts: the maintenance burden is higher, and requires a >> higher initial understanding from people not already familiar with the >> package. > > I agree in 100% with this. Would you be OK, until further development comes along, to use a wrapper unit like this: [Unit] Description=Set the console keyboard layout DefaultDependencies=no Before=local-fs-pre.target Wants=local-fs-pre.target ConditionPathExists=/bin/setupcon [Service] Type=oneshot ExecStart=/etc/init.d/keyboard-setup.sh start RemainAfterExit=yes [Install] WantedBy=sysinit.target And mutatis mutandis for console-setup.sh? While not being the optimal setup, it works, and avoids reliance on the debian-specific runlevel S support. I plan to do a NMU fixing this bug via a unit like the above, please tell me if you want to address this in some other way. -- Saludos, Felipe Sateler
Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138)
On 5 Mar 2016 17:01, "Anton Zinoviev" <an...@lml.bas.bg> wrote: > > On Fri, Mar 04, 2016 at 03:08:39PM -0300, Felipe Sateler wrote: > > > > > Unfortunately, I will not be able to maintain this file or to update it > > > in accordance with future changes in systemd. So I suppose that unless > > > you or somebody else volunteers to maintain it, it will be better to > > > continue without it. > > > > As long as the initscript does simple things, it should require very > > little maintainance. While I can't commit to maintain it (I am no > > expert in console matters), feel free to CC pkg-systemd-maintainers or > > myself if you ever receive a bug about this. > > The reason I hesitate is that I am not a "normal" maintainer of > console-setup. While I have enough time for development related to > console-setup, my limitations force me to allocate this time in batches > with relatively large periods between them. In fact, it won't be > incorrect to say that most of the time other people take care of this > package (one can easily observe this in the changelog). As long as the systemd service keeps relatively close to what the init script is doing, keeping the service file up to date is easy. The only problematic parts would be if the dependencies are changing; but then there are people that can answer questions. It would be a bit harder if the systemd units and init scripts start diverging. > > > >> Before=local-fs-pre.target > > >> Wants=local-fs-pre.target > > > > > > What is the meaning of these two? > > > > This ensures it is run before systemd attempts to fsck and mount any > > local filesystems. It is therefore a relatively appropriate > > replacement for the checkroot dependency. > > What does 'Wants' do? Is this some kind of optimization? Wants means that whenever the service is started, the listed dependencies should be started as well. In systemd, ordering and functional dependencies are orthogonal, so there are separate keywords to specify both. Ordering dependencies do not mean that all the listed services will be activated, it only means: if these units are part of the same transaction, then start them before (or after) the declaring unit. The functional dependency means that if the service is to be started, the listed units will be added to the transaction. In this case, there is a small optimization: mounts and fsck services are ordered after local-fs-pre, but do not depend on it. Thus on simple scenarios the target is never incorporated into the boot transaction. Services that should run before need to cause the target to be pulled in explicitly, which is why keyboard-setup.sh would need to Want it. There are more details about the target in the systemd.special manpage, and about dependencies in systemd.unit. > > > There does not appear to be a keymap init script: > > > > These are created by the kernel when devtmpfs is mounted, and systemd > > mounts /dev before starting any units, so they should be available, > > yes. > > This is good. It seems we don't need 'After'. Right, it can be started as early as possible (and keymap removed from the init script). > > > > One novelty in version 1.138 is that it is unnecessary to run setupcon > > > in order to configure the console. It is OK to configure the keyboard > > > in this way, but this usually will be slower than what the script > > > keyboard-setup.sh does -- instead of setupcon it runs > > > /etc/console-setup/cached_setup_keyboard.sh and reverts to using > > > setupcon only when this script doesn't exist of fails. > > > > IMO, the init script should be as dumb as possible, as it is a > > conffile. Therefore all program logic should move outside the script > > and into a helper script that lives in /lib. This way, improvements > > are guaranteed to be shipped to users. > > The script /etc/console-setup/cached_setup_keyboard.sh is not a > configuration file and the user is not supposed to edit it. Since it is > autogenerated, there is no problem to ship improvements to the users. > (Under FHS this script would have to go in /var rather than in /etc, > however, we need it while /var is not yet mounted. Years ago, nobody at > debian-devel could find a solution to this problem, so now console-setup > violates this aspect of FHS.) I meant the logic to determine if setupcon or the cached scripts should be run. If in the future that part is changed (eg, the names are changed, or more scripts are generated), there is no guarantee the change will reach users, since they may have modified the init script. > > > The resulting unit would be: > > > > Conditi
Bug#804988: keyboard-configuration: Please drop dependency on initscripts package
On 5 Mar 2016 17:02, "Anton Zinoviev" <an...@lml.bas.bg> wrote: > > On Fri, Mar 04, 2016 at 11:23:52AM -0300, Felipe Sateler wrote: > > > > AFAICT, initscripts itself is only needed to ensure the Required-Start > > dependency of keyboard-setup.sh. This problem is solved by replacing > > the dependency with init-system-helpers (>= 1.29~), which will do the > > right thing when initscripts is not installed (ie, not abort the > > installation). > > Another problem is the $remote_fs dependency of console-setup.sh. See > #621077. The problem is fixed when init-system-helpers (>= 1.29~) is installed. Update-rc.d has been modified so that when it detects that initscripts is not installed, insserv is invoked in a way that doesn't fail if dependencies are missing. Therefore, the dependency can be changed from initscripts to init-system-helpers (>= 1.29~). Saludos
Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138)
Control: reopen -1 Control: found -1 1.138 On 3 March 2016 at 08:24, Debian Bug Tracking System <ow...@bugs.debian.org> wrote: > Source: console-setup > Source-Version: 1.138 > > We believe that the bug you reported is fixed in the latest version of > console-setup, which is due to be installed in the Debian FTP archive. >* On Linux: move init.d/console-setup.sh out of singe user mode. > Closes: #796603, #816090. There is still keyboard-configuration.sh in runlevel S. So this problem is still present. I suggest including a service file like this: [Unit] Description=Set preliminary keymap DefaultDependencies=no Before=local-fs-pre.target Wants=local-fs-pre.target After=udev.service keymap.service ConditionPathExists=/bin/setupcon [Service] Type=oneshot EnvironmentFile=-/etc/default/locale ExecStart=/bin/setupcon --keyboard-only RemainAfterExit=yes [Install] WantedBy=sysinit.target -- Saludos, Felipe Sateler
Bug#804988: keyboard-configuration: Please drop dependency on initscripts package
Control: reopen -1 Control: found -1 1.138 On Thu, 03 Mar 2016 11:21:32 + Anton Zinoviev <zinov...@debian.org> wrote: > Source: console-setup > Source-Version: 1.138 > > We believe that the bug you reported is fixed in the latest version of > console-setup, which is due to be installed in the Debian FTP archive. > * Move the init scripts from keyboard-configuration to > console-setup-linux and console-setup-freebsd. Closes: #805928. > Give them a .sh extension to make them sourcable. Move the > dependency on initscripts to these two packages. Closes: #804988. Moving the dependency to another package does not remove the dependency ;), so this bug is not fixed. AFAICT, initscripts itself is only needed to ensure the Required-Start dependency of keyboard-setup.sh. This problem is solved by replacing the dependency with init-system-helpers (>= 1.29~), which will do the right thing when initscripts is not installed (ie, not abort the installation). -- Saludos, Felipe Sateler
Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138)
On 4 March 2016 at 14:40, Anton Zinoviev <an...@lml.bas.bg> wrote: > On Fri, Mar 04, 2016 at 11:23:54AM -0300, Felipe Sateler wrote: >> >> There is still keyboard-configuration.sh in runlevel S. So this >> problem is still present. > > Yes. The problem however is much smaller because this script does not > require $remote_fs. Right. The real problem however, is that rcS support is a debian-specific patch, and the systemd maintainers would like to drop it to decrease maintainance workload. >> I suggest including a service file like this: > > OK. > > Unfortunately, I will not be able to maintain this file or to update it > in accordance with future changes in systemd. So I suppose that unless > you or somebody else volunteers to maintain it, it will be better to > continue without it. As long as the initscript does simple things, it should require very little maintainance. While I can't commit to maintain it (I am no expert in console matters), feel free to CC pkg-systemd-maintainers or myself if you ever receive a bug about this. > >> Description=Set preliminary keymap > > 'Set the console keyboard layout' is a better description. The new > console-setup is better optimized for speed and configures the keyboard > only once. > >> Before=local-fs-pre.target >> Wants=local-fs-pre.target > > What is the meaning of these two? This ensures it is run before systemd attempts to fsck and mount any local filesystems. It is therefore a relatively appropriate replacement for the checkroot dependency. > >> After=udev.service keymap.service These two were copied as-is from the LSB headers > > The reason for keymap.service is that the keymap of console-setup can > take precedence to the keymap provided by the package kbd (I am not sure > this package still configures the keyboard, in the past it did). There does not appear to be a keymap init script: % apt-file search etc/init.d/key console-setup-freebsd: /etc/init.d/keyboard-setup.sh console-setup-linux: /etc/init.d/keyboard-setup.sh keystone: /etc/init.d/keystone This can be dropped then. > > The keyboard configuration depends on the existence of /dev/null and > /dev/tty[1-6]. I have no idea whether this small dependency requires > udeb.service. These are created by the kernel when devtmpfs is mounted, and systemd mounts /dev before starting any units, so they should be available, yes. > >> EnvironmentFile=-/etc/default/locale > > What does this do? This file is used (optionally) only in abnormal > situations. It reads the key-value pairs from the file (if it exists), and exports them as environment variables. Shell commands are not supported, only assignments. > >> ExecStart=/bin/setupcon --keyboard-only > > One novelty in version 1.138 is that it is unnecessary to run setupcon > in order to configure the console. It is OK to configure the keyboard > in this way, but this usually will be slower than what the script > keyboard-setup.sh does -- instead of setupcon it runs > /etc/console-setup/cached_setup_keyboard.sh and reverts to using > setupcon only when this script doesn't exist of fails. IMO, the init script should be as dumb as possible, as it is a conffile. Therefore all program logic should move outside the script and into a helper script that lives in /lib. This way, improvements are guaranteed to be shipped to users. I don't think it is reasonable to try to replicate the logic in keyboard-configuration.sh via systemd dependencies. I would instead split out a script as mentioned, and invoke that (instead of setupcon) in the ExecStart line. If you do not want to extract the logic to a separate script, then the course of action should be to drop the EnvironmentFile, and have ExecStart=/etc/init.d/keyboard-setup.sh start to delegate all the logic to the init script. Note that the important part for us is not the amount of work a given runlevel S script does, but rather that the dependencies are defined by the systemd unit, and not autoguessed from the LSB headers. The resulting unit would be: [Unit] Description=Set the console keyboard layout DefaultDependencies=no Before=local-fs-pre.target Wants=local-fs-pre.target ConditionPathExists=/bin/setupcon [Service] Type=oneshot ExecStart=/etc/init.d/keyboard-setup.sh start # Alternatively, if the setup logic is split to a separate script: #ExecStart=/lib/console-setup/keyboard-setup.sh RemainAfterExit=yes [Install] WantedBy=sysinit.target -- Saludos, Felipe Sateler
Bug#796603: keyboard-configuration: Has init script in runlevel S but no matching service file
On 29 February 2016 at 15:22, Anton Zinoviev <an...@lml.bas.bg> wrote: > On Mon, Feb 29, 2016 at 09:54:23AM -0300, Felipe Sateler wrote: >> >> On Mon, 22 Feb 2016 19:33:28 +0300 Anton Zinoviev <an...@lml.bas.bg> wrote: >> > tags 796603 + help patch >> >> I see you tagged this bug help. What can I do to help move this forward? > > Thank you. In the new version I am preparing now (should be ready in a > couple of days), this script will move out of runlevel S on Linux and on > FreeBSD there is no systemd. Interesting. Why is it no longer required during early boot? > So it seems there will be no need for a > systemd service unit. Well, that depends on the value of "need" ;). A systemd unit would still be useful, as it allows better tracking by systemd of the process. I can submit a systemd unit, after I see the end result of this rework you are doing now. -- Saludos, Felipe Sateler
Bug#796603: keyboard-configuration: Has init script in runlevel S but no matching service file
Hi Anton, On Mon, 22 Feb 2016 19:33:28 +0300 Anton Zinoviev <an...@lml.bas.bg> wrote: > tags 796603 + help patch I see you tagged this bug help. What can I do to help move this forward? -- Saludos, Felipe Sateler
Bug#796603: keyboard-configuration: Has init script in runlevel S but no matching service file
On 10 October 2015 at 09:54, Felipe Sateler <fsate...@debian.org> wrote: > Control: tags -1 patch > > Missed the bug cc, sorry for the duplicate. > > On 1 September 2015 at 17:54, Michael Biebl <bi...@debian.org> wrote: >> Am 01.09.2015 um 19:38 schrieb Felipe Sateler: >>> On 1 September 2015 at 14:05, Anton Zinoviev <an...@lml.bas.bg> wrote: >>>> On Thu, Aug 27, 2015 at 03:18:17PM -0300, Felipe Sateler wrote: >>>>> >>>>> Does console-setup actually need to be run before user services are >>>>> started? My guess is that it only needs to run before getty, but it >>>>> should not block other services that want to start. >>>> >>>> It should run before fsck. >>> >>> That is definitely not what the init script says[1]: >>> >>> # Provides: console-setup >>> # Required-Start:$remote_fs >> >> Right, the $remote_fs dependency means it's actually started pretty late. >> I guess what Anton meant was keyboard-setup. > > OK, so I added 2 service files, and preserved the early startup. However: > > 1. keyboard-setup is setup very early at boot, before > local-fs-pre.target so that it occurs before fsck (at least the ones > that don't happen in the initrd). > 2. The ordering on console-setup is relaxed so that it starts early, > but after /usr and /usr/local are mounted and the root fs is remounted > (so that it can be saved in /etc). At the same time, this will not > delay any further services except the gettys by being > Before=system-getty.slice (BTW, maybe we need a getty-pre.target?). I have attached a new version. Changes: 1. Add ConditionPathExists (because the service is shipped in another package). 2. Add RemainAfterExit=yes. I was getting the service started multiple times during boot. -- Saludos, Felipe Sateler From 7bf25445c6c72e532235448e9342572a138cbccf Mon Sep 17 00:00:00 2001 From: Felipe Sateler <fsate...@debian.org> Date: Sat, 10 Oct 2015 08:40:50 -0300 Subject: [PATCH] Add systemd units --- debian/changelog | 7 +++ debian/keyboard-configuration.console-setup.service | 16 debian/keyboard-configuration.keyboard-setup.service | 16 debian/rules | 8 4 files changed, 47 insertions(+) create mode 100644 debian/keyboard-configuration.console-setup.service create mode 100644 debian/keyboard-configuration.keyboard-setup.service diff --git a/debian/changelog b/debian/changelog index 8c7915f..0a63688 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +console-setup (1.134+nmu1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Add systemd units + + -- Felipe Sateler <fsate...@debian.org> Thu, 08 Oct 2015 20:18:37 -0300 + console-setup (1.134) unstable; urgency=medium [ Colin Watson ] diff --git a/debian/keyboard-configuration.console-setup.service b/debian/keyboard-configuration.console-setup.service new file mode 100644 index 000..d75c3dd --- /dev/null +++ b/debian/keyboard-configuration.console-setup.service @@ -0,0 +1,16 @@ +[Unit] +Description=Set console font and keymap +DefaultDependencies=no +After=console-screen.service kbd.service local-fs.target +Before=system-getty.slice +RequiresMountsFor=/usr /usr/local +ConditionPathExists=/bin/setupcon + +[Service] +Type=oneshot +EnvironmentFile=-/etc/default/locale +ExecStart=/bin/setupcon --save +RemainAfterExit=yes + +[Install] +WantedBy=sysinit.target diff --git a/debian/keyboard-configuration.keyboard-setup.service b/debian/keyboard-configuration.keyboard-setup.service new file mode 100644 index 000..946b91f --- /dev/null +++ b/debian/keyboard-configuration.keyboard-setup.service @@ -0,0 +1,16 @@ +[Unit] +Description=Set preliminary keymap +DefaultDependencies=no +Before=local-fs-pre.target +Wants=local-fs-pre.target +After=udev.service keymap.service +ConditionPathExists=/bin/setupcon + +[Service] +Type=oneshot +EnvironmentFile=-/etc/default/locale +ExecStart=/bin/setupcon --keyboard-only +RemainAfterExit=yes + +[Install] +WantedBy=sysinit.target diff --git a/debian/rules b/debian/rules index d709312..1982d0d 100755 --- a/debian/rules +++ b/debian/rules @@ -145,10 +145,18 @@ install-main: build usr/share/console-setup/ dh_link -pkeyboard-configuration usr/share/X11/xkb/rules/xorg.lst \ usr/share/doc/keyboard-configuration/xorg.lst + dh_systemd_enable -pkeyboard-configuration \ + --name keyboard-setup + dh_systemd_enable -pkeyboard-configuration \ + --name console-setup dh_installinit -pkeyboard-configuration \ --no-start --name keyboard-setup -- start 06 S . dh_installinit -pkeyboard-configuration \ --no-start --name console-setup -- start 49 S . + dh_systemd_start -pkeyboard-configuration \ + --no-start --name keyboard-setup + dh_systemd_start -pkeyboard-configuration \ + --no-start --name console-setup .PHONY : install-bdf2psf install-bdf2psf: build -- 2.6.2
Bug#796603: keyboard-configuration: Has init script in runlevel S but no matching service file
On 10 October 2015 at 09:54, Felipe Sateler <fsate...@debian.org> wrote: > On 1 September 2015 at 17:54, Michael Biebl <bi...@debian.org> wrote: >> Am 01.09.2015 um 19:38 schrieb Felipe Sateler: >>> On 1 September 2015 at 14:05, Anton Zinoviev <an...@lml.bas.bg> wrote: >>>> On Thu, Aug 27, 2015 at 03:18:17PM -0300, Felipe Sateler wrote: >>>>> >>>>> Does console-setup actually need to be run before user services are >>>>> started? My guess is that it only needs to run before getty, but it >>>>> should not block other services that want to start. >>>> >>>> It should run before fsck. >>> >>> That is definitely not what the init script says[1]: >>> >>> # Provides: console-setup >>> # Required-Start:$remote_fs >> >> Right, the $remote_fs dependency means it's actually started pretty late. >> I guess what Anton meant was keyboard-setup. > > OK, so I added 2 service files, and preserved the early startup. On IRC it was pointed out that --save is not necessary under systemd: /usr must always be mounted. However I decided to preserve it because: 1. I am not 100% sure that /usr is guaranteed to be mounted (the initrd AFAIK does not handle all cases). 2. On reboot to sysv it would be good to preserve the files in /etc. If /usr is actually guaranteed to be available, then we should drop --save from both the init script and service file. -- Saludos, Felipe Sateler
Bug#796603: Fwd: Bug#796603: keyboard-configuration: Has init script in runlevel S but no matching service file
Control: tags -1 patch Missed the bug cc, sorry for the duplicate. On 1 September 2015 at 17:54, Michael Biebl <bi...@debian.org> wrote: > Am 01.09.2015 um 19:38 schrieb Felipe Sateler: >> On 1 September 2015 at 14:05, Anton Zinoviev <an...@lml.bas.bg> wrote: >>> On Thu, Aug 27, 2015 at 03:18:17PM -0300, Felipe Sateler wrote: >>>> >>>> Does console-setup actually need to be run before user services are >>>> started? My guess is that it only needs to run before getty, but it >>>> should not block other services that want to start. >>> >>> It should run before fsck. >> >> That is definitely not what the init script says[1]: >> >> # Provides: console-setup >> # Required-Start:$remote_fs > > Right, the $remote_fs dependency means it's actually started pretty late. > I guess what Anton meant was keyboard-setup. OK, so I added 2 service files, and preserved the early startup. However: 1. keyboard-setup is setup very early at boot, before local-fs-pre.target so that it occurs before fsck (at least the ones that don't happen in the initrd). 2. The ordering on console-setup is relaxed so that it starts early, but after /usr and /usr/local are mounted and the root fs is remounted (so that it can be saved in /etc). At the same time, this will not delay any further services except the gettys by being Before=system-getty.slice (BTW, maybe we need a getty-pre.target?). Review welcome. -- Saludos, Felipe Sateler From 7ed5dcd10e76b25304ca2584cd828be4aa61e61c Mon Sep 17 00:00:00 2001 From: Felipe Sateler <fsate...@debian.org> Date: Sat, 10 Oct 2015 08:40:50 -0300 Subject: [PATCH] Add systemd units --- debian/changelog | 7 +++ debian/keyboard-configuration.console-setup.service | 14 ++ debian/keyboard-configuration.keyboard-setup.service | 14 ++ debian/rules | 8 4 files changed, 43 insertions(+) create mode 100644 debian/keyboard-configuration.console-setup.service create mode 100644 debian/keyboard-configuration.keyboard-setup.service diff --git a/debian/changelog b/debian/changelog index 73796fb..6b8dae1 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +console-setup (1.133+nmu1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Add systemd units + + -- Felipe Sateler <fsate...@debian.org> Thu, 08 Oct 2015 20:18:37 -0300 + console-setup (1.133) unstable; urgency=medium [ Updated translations ] diff --git a/debian/keyboard-configuration.console-setup.service b/debian/keyboard-configuration.console-setup.service new file mode 100644 index 000..67af770 --- /dev/null +++ b/debian/keyboard-configuration.console-setup.service @@ -0,0 +1,14 @@ +[Unit] +Description=Set console font and keymap +DefaultDependencies=no +After=console-screen.service kbd.service local-fs.target +Before=system-getty.slice +RequiresMountsFor=/usr /usr/local + +[Service] +Type=oneshot +EnvironmentFile=-/etc/default/locale +ExecStart=/bin/setupcon --save + +[Install] +WantedBy=sysinit.target diff --git a/debian/keyboard-configuration.keyboard-setup.service b/debian/keyboard-configuration.keyboard-setup.service new file mode 100644 index 000..d50247b --- /dev/null +++ b/debian/keyboard-configuration.keyboard-setup.service @@ -0,0 +1,14 @@ +[Unit] +Description=Set preliminary keymap +DefaultDependencies=no +Before=local-fs-pre.target +Wants=local-fs-pre.target +After=udev.service keymap.service + +[Service] +Type=oneshot +EnvironmentFile=-/etc/default/locale +ExecStart=/bin/setupcon -k + +[Install] +WantedBy=sysinit.target diff --git a/debian/rules b/debian/rules index d709312..1982d0d 100755 --- a/debian/rules +++ b/debian/rules @@ -145,10 +145,18 @@ install-main: build usr/share/console-setup/ dh_link -pkeyboard-configuration usr/share/X11/xkb/rules/xorg.lst \ usr/share/doc/keyboard-configuration/xorg.lst + dh_systemd_enable -pkeyboard-configuration \ + --name keyboard-setup + dh_systemd_enable -pkeyboard-configuration \ + --name console-setup dh_installinit -pkeyboard-configuration \ --no-start --name keyboard-setup -- start 06 S . dh_installinit -pkeyboard-configuration \ --no-start --name console-setup -- start 49 S . + dh_systemd_start -pkeyboard-configuration \ + --no-start --name keyboard-setup + dh_systemd_start -pkeyboard-configuration \ + --no-start --name console-setup .PHONY : install-bdf2psf install-bdf2psf: build -- 2.6.0
Bug#796603: keyboard-configuration: Has init script in runlevel S but no matching service file
On 1 September 2015 at 14:05, Anton Zinoviev <an...@lml.bas.bg> wrote: > On Thu, Aug 27, 2015 at 03:18:17PM -0300, Felipe Sateler wrote: >> >> Does console-setup actually need to be run before user services are >> started? My guess is that it only needs to run before getty, but it >> should not block other services that want to start. > > It should run before fsck. That is definitely not what the init script says[1]: # Provides: console-setup # Required-Start:$remote_fs # Required-Stop: # Should-Start: console-screen kbd # Default-Start: S The keyboard-setup script does, though[2]: # X-Start-Before: checkroot [1] http://sources.debian.net/src/console-setup/1.132/debian/keyboard-configuration.console-setup.init/ [2] http://sources.debian.net/src/console-setup/1.132/debian/keyboard-configuration.keyboard-setup.init/ -- Saludos, Felipe Sateler
Bug#796603: keyboard-configuration: Has init script in runlevel S but no matching service file
On 23 August 2015 at 09:56, Cyril Brulebois k...@debian.org wrote: Hi, fsate...@debian.org fsate...@debian.org (2015-08-22): Package: keyboard-configuration Severity: important User: pkg-systemd-maintain...@lists.alioth.debian.org Usertags: init-rcs-service (maintonly considered slightly annoying.) Hi, Your package keyboard-configuration has an initscript that is enabled in runlevel S, but it does not provide a corresponding systemd service unit. Systemd generates units for all sysv init scripts that do not have a corresponding systemd unit. By default, it sets DefaultDependencies=yes, which means they get ordered after early boot has finished. The problem is that to preserve the runlevel S semantics, systemd in debian is currently[1] ordering all S services Before=sysinit.target. This target is particularly early in the boot sequence, which means that it is most of the time too strict. In turn, this means it is fairly easy to end up with dependency cycles. For an example, see bug [763315]. Do note that the cycle still exists with sysvinit, it is just that systemd complains more loudly. Please add a systemd unit for the given service with the appropriate dependencies, which most of the time will be less strict than Before=sysinit.target. In other cases, the script is simply not applicable in systemd, in which case the package should ship a symlink to /dev/null as /lib/systemd/system/initscript.service. We have prepared a transition wiki page[2] explaining the issue in more detail, and outlining some general guidance. Please refer to it as it will have useful information. If you have any other doubts, feel free to ask in pkg-systemd-maintain...@lists.alioth.debian.org (Talking more as d-i RM than possible comaintainer, which I'm not.) src:console-setup could probably do with more hands on it, especially given (very friendly) bug reports like #763695. If you guys had any time to spend on making sure boot time dependencies are correct, and possibly that boot time performances improve over time, that would be much appreciated. Does console-setup actually need to be run before user services are started? My guess is that it only needs to run before getty, but it should not block other services that want to start. If someone could answer that question it should be very simple to provide a patch for this. -- Saludos, Felipe Sateler
Bug#763695: console-setup is slowest part of boot, not fast as setupcon manpage tells us
On Wed, 8 Oct 2014 18:27:04 +0300 Anton Zinoviev an...@lml.bas.bg wrote: On Wed, Oct 01, 2014 at 11:31:18PM +0200, Julian Andres Klode wrote: console-setup requires 800ms during a boot. The complete boot finishes in 4.1 seconds. This really should not be a shell script in the long term, but short term at least removing fast from the manual page would be a good idea... Here's a boot graph: https://people.debian.org/~jak/boot.svg One possible explanation is what Samuel Thibault proposed (for some reason setupcon doesn't use cached keymap). The following is (may be) another explanation. I don't know how exactly recent Debian systems boot so the following is only a guess. Considering that keyboard-setup.service uses only 190 ms compared to 823 ms for console-setup.service, I suppose that these 823 ms are caused by forked printf commands (by setupcon) waiting for the virtual consoles to become active. So during most of these 823ms the scripts were waiting and didn't consume cpu resources. If my hypothesis is true, the proper fix is to improve the description console-setup.service in order to run it only after the virtual consoles become active. This, however, is not something I can do (with my current knowledge). I am experiencing the same problem. I edited setupcon to add set -x at the beginning to help tracing where the slowness is. It doesn't look like printf is at fault. I also tried changing the amount of ACTIVE_CONSOLES in /etc/default/console-setup but it did not make much of a difference (I tried setting it to just tty1 and to the empty string). Logs, plots and systemd-blame at https://people.debian.org/~fsateler/console-setup/ Saludos -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caafdzj-mpu7mexwftcixqaec-1fjgegfp7z2jxldxzutp4b...@mail.gmail.com
Bug#758116: Please be verbose whether you would like to get your Blend promoted by tasksel
Hi, On Wed, Sep 3, 2014 at 2:40 AM, Andreas Tille andr...@an3as.eu wrote: Hi, On Wed, Sep 03, 2014 at 07:45:12AM +0200, Per Andersson wrote: I don't think this is a particularly good measure since the blends are relatively unknown. I think it is not a measure for a sequence but rather a measure whether a Blend should be included or not. For instance I missed multimedia-tasks in my list (for the simple reason that I have not seen any relevant commit since nearly one year). But for sure multimedia is quite important for our users and perhaps the fact that there is a chance to prominently be shown in the installer might be a motivation for multimedia maintainers to review the tasks (both team members who previously commited to Git in CC). Sorry for not commenting on the bug but we did start a discussion within the multimedia team on wether we want to pursue this or not. Unfortunately, there seems to not be enough manpower to actually prepare a reasonable set of tasks. We did discuss what would be desirable, but nobody actually stepped up and offered to do the job. I would very much like to have the multimedia tasks included, but unfortunately I think they are not high quality enough at the moment, and I can't commit to improving them in the short term (ie, before the freeze). -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caafdzj8rzx2it7t+ko_jfd1ppqmsphzvn+zkm2e2+aneesw...@mail.gmail.com
Bug#583993: discover-pkginstall: Recommends ipw3954-source, which no longer exists
On Tue, Jun 1, 2010 at 02:29, Petter Reinholdtsen p...@hungry.com wrote: [Felipe Sateler] % discover-pkginstall -l ipw3945-source ipw3945 has been superseeded by the iwl drivers. Thank you for reviewing the discover-pkginstall behaviour. :) When did it become superseeded? What does that mean for discover? Should some other package be proposed, or the ipw3945-source package not be proposed for newer versions of Debian? Yes, ipw* should not be proposed anymore. Instead, firmware-iwlwifi should be. But that's another bug (#464968). -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktin50mxdxwhefr3d0u8am_fy2haljs8xbx9ya...@mail.gmail.com
Bug#583993: discover-pkginstall: Recommends ipw3954-source, which no longer exists
Package: discover-data Version: 2.2010.04.07 Severity: normal % discover-pkginstall -l ipw3945-source ipw3945 has been superseeded by the iwl drivers. -- Package-specific info: lspci: 00:00.0 Host bridge [0600]: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub [8086:2a00] (rev 0c) 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 0c) 00:02.1 Display controller [0380]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a03] (rev 0c) 00:1a.0 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 [8086:2834] (rev 02) 00:1a.1 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 [8086:2835] (rev 02) 00:1a.7 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 [8086:283a] (rev 02) 00:1b.0 Audio device [0403]: Intel Corporation 82801H (ICH8 Family) HD Audio Controller [8086:284b] (rev 02) 00:1c.0 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 [8086:283f] (rev 02) 00:1c.1 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 [8086:2841] (rev 02) 00:1c.3 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 [8086:2845] (rev 02) 00:1c.5 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 6 [8086:2849] (rev 02) 00:1d.0 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 [8086:2830] (rev 02) 00:1d.1 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 [8086:2831] (rev 02) 00:1d.2 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 [8086:2832] (rev 02) 00:1d.7 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 [8086:2836] (rev 02) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev f2) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller [8086:2815] (rev 02) 00:1f.1 IDE interface [0101]: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller [8086:2850] (rev 02) 00:1f.2 SATA controller [0106]: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller [8086:2829] (rev 02) 00:1f.3 SMBus [0c05]: Intel Corporation 82801H (ICH8 Family) SMBus Controller [8086:283e] (rev 02) 03:01.0 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 IEEE 1394 Controller [1180:0832] (rev 05) 03:01.1 SD Host controller [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822] (rev 22) 03:01.2 System peripheral [0880]: Ricoh Co Ltd R5C843 MMC Host Controller [1180:0843] (rev 12) 03:01.3 System peripheral [0880]: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter [1180:0592] (rev 12) 03:01.4 System peripheral [0880]: Ricoh Co Ltd xD-Picture Card Controller [1180:0852] (rev ff) 09:00.0 Ethernet controller [0200]: Broadcom Corporation NetLink BCM5906M Fast Ethernet PCI Express [14e4:1713] (rev 02) 0c:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection [8086:4222] (rev 02) lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 038: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth) Bus 003 Device 039: ID 413c:8126 Dell Computer Corp. Wireless 355 Bluetooth Bus 003 Device 040: ID 0a5c:4502 Broadcom Corp. Keyboard (Boot Interface Subclass) Bus 003 Device 041: ID 0a5c:4503 Broadcom Corp. Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub loaded modules: 8086:2a02 drm 8086:2834 uhci_hcd 8086:2835 uhci_hcd 8086:283a ehci_hcd 8086:284b snd_hda_intel 8086:2830 uhci_hcd 8086:2831 uhci_hcd 8086:2832 uhci_hcd 8086:2836 ehci_hcd 8086:2850 ata_piix 8086:2829 ahci 8086:283e i2c_i801 1180:0832 firewire_ohci 1180:0822 sdhci_pci 1180:0843 ricoh_mmc 14e4:1713 tg3 8086:4222 iwl3945 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash discover-data depends on no packages. Versions of packages discover-data recommends: ii pciutils 1:3.1.7-3 Linux PCI Utilities discover-data suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive:
Bug#345999: installation-report: Fails to detect CD
On Wednesday 11 January 2006 01:34, Felipe Sateler wrote: On Wednesday 11 January 2006 01:23, Frans Pop wrote: Felipe, could you send us the output of 'lsmod' for both the old installer (that worked) and the new one? That might be a problem, because the laptop is not currently here (it should back be in a couple of days). Unfortunately, I could never get a hold of that laptop for enough time to actually do that, and now the laptop is completely out of my reach, so I won't be able to check lsmod's output. Sorry. -- Felipe Sateler pgpNtkae82vD0.pgp Description: PGP signature