Bug#769388: marked as done ('PermitRootLogin without-password' in new installations breaks some use cases)
Your message dated Sun, 3 Mar 2019 20:35:55 +0100 with message-id <7b603213-96c5-8056-b6d3-7b2c7a62a...@debian.org> and subject line close release-notes bugs for releases before stretch has caused the Debian Bug report #769388, regarding 'PermitRootLogin without-password' in new installations breaks some use cases to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 769388: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769388 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: openssh-server Version: 1:6.0p1-4 Severity: grave Installed openssh-server on debian stable. As soon as i update the package to latest version (it is reported for the other version as i cannot login if the package is not at that version) login becomes impossible with the error Oct 17 20:11:34 nl-01 sshd[25206]: Accepted password for root from IP port 44676 ssh2 Oct 17 20:11:34 nl-01 sshd[25206]: pam_loginuid(sshd:session): set_loginuid failed Oct 17 20:11:34 nl-01 sshd[25206]: pam_unix(sshd:session): session opened for user root by (uid=0) Oct 17 20:11:34 nl-01 sshd[25206]: error: PAM: pam_open_session(): Cannot make/remove an entry for the specified session Oct 17 20:11:34 nl-01 sshd[25206]: Received disconnect from IP: 11: disconnected by user -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-vserver-amd64 (SMP w/24 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages openssh-server depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.51 ii dpkg 1.17.1 ii libc6 2.17-93 ii libcomerr2 1.42.8-1 ii libgssapi-krb5-2 1.11.3+dfsg-3 ii libkrb5-3 1.11.3+dfsg-3 ii libpam-modules 1.1.3-7.1 ii libpam-runtime 1.1.3-7.1 ii libpam0g 1.1.3-7.1 ii libselinux12.1.13-3 ii libssl1.0.01.0.1e-3 ii libwrap0 7.6.q-24 ii lsb-base 4.1+Debian12 ii openssh-client 1:6.0p1-4 ii procps 1:3.3.8-2 ii zlib1g 1:1.2.8.dfsg-1 Versions of packages openssh-server recommends: ii ncurses-term 5.9+20130608-1 ii openssh-blacklist0.4.1+nmu1 ii openssh-blacklist-extra 0.4.1+nmu1 ii xauth1:1.0.7-1 Versions of packages openssh-server suggests: pn molly-guard pn monkeysphere pn rssh pn ssh-askpass pn ufw -- debconf information: ssh/vulnerable_host_keys: ssh/encrypted_host_key_but_no_keygen: * ssh/use_old_init_script: true ssh/disable_cr_auth: false --- End Message --- --- Begin Message --- Hi, We are sorry that we were not able to handle your contribution or suggestion for changes to the release-notes. I am going over old bugs and I am closing all the items that were suggested for the release-notes of Debian releases before stretch. On the good side, some even appear to have been applied, without the bug being closed. Please don't hesitate to open a new bug if you think your suggestion is still valuable for the release-notes of buster. If you do that, we'd appreciate it when you try to summarize the issue properly when the closed bug was more than a couple of messages. Paul signature.asc Description: OpenPGP digital signature --- End Message ---
Installations
Hi How to install my EPSON STYLE TX300F *profeMontiel* *Alfabetizador web < wl > (wl = web literacy)*
Bug#771825: marked as done (release-notes: Update information on non-systemd Jessie upgrades and installations)
Your message dated Sat, 14 May 2016 13:45:50 + with message-id <57372c0e.6080...@thykier.net> and subject line Re: Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations has caused the Debian Bug report #771825, regarding release-notes: Update information on non-systemd Jessie upgrades and installations to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 771825: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771825 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release-notes Severity: Important Hello, As promised on debian-devel attached is a first proposal for an update of the release notes. There are two small issues with the patch: - The text is edited without seeing the markup result. How to do that? - The second part about preseeding will be tested tonight, and an updated patch will be submitted if any changes are needed. Thanks! --- release_notes.current 2014-12-02 16:45:21.060959945 +0100 +++ release_notes.updated 2014-12-02 18:15:00.936959303 +0100 @@ -19,6 +19,16 @@ 193 Pin: release o=Debian 194 Pin-Priority: -1 195 + + + It is also good to install sysvinit-core, sysvint and + sysvinit-utils as the first packages when upgrading. In case + you want an as-systemd-free-as-possible desktop environment, + it is also recommended to install systemd-shim, in order to + help apt and aptitude to avoid installing systemd-sysv and + other *systemd* components, unintentionally. + + 196 197 198 Be advised that some packages may have degraded behaviour or @@ -33,3 +43,43 @@ 207 role="package">systemd-sysv package must be 208 installed first. 209 + + + How to avoid the default init system for Jessie + + For new installations of Jessie the default init system + systemd-sysvinit will be installed. In order to run a + traditional init system, such as sysvinit-core, two + workarounds are available: + + + 1) Go through the installation, selecting the minimum number + of packages, maybe do only select standard (or use + netinst.iso). After the installation and first reboot, + install sysvinit-core and remove systemd-sysv (and maybe + other *systemd* packages). If a desktop is to be + installed install systemd-shim first before choosing other + components. + + + + 2) Use a preseed command to finish the install with + sysvinit-core instead of systemd-core. (again choosing a + minimum installation) + + Choose Advanced options + Choose ### Running custom commands during the installation + + Issue + + preseed/late_command="in-target apt-get install -y sysvinit-core" + + and continue with the installation. + For further info see + https://wiki.debian.org/systemd#Installing_without_systemd + and + + http://d-i.debian.org/manual/en.i386/apbs05.html + http://d-i.debian.org/manual/example-preseed.txt + + --- End Message --- --- Begin Message --- On Sun, 29 Mar 2015 16:55:17 +0200 Niels Thykier <ni...@thykier.net> wrote: > Control: tags -1 pending > > On 2014-12-15 17:00, Svante Signell wrote: > > [...] > > > > Hi I trimmed the patch, less text now. However, the LILO comment is > > still there. Do you want me to remove that one too? > > > > Hi, > > I have applied a minor patch to day based on your patch submitted here > (See attached). > > First hunk was accepted as-is (modulo whitespace). From the rest, I > extracted some minor pieces if not already documented else where. In > particular: > > * I documented that installing systemd-shim and sysvinit-core manually >might help APT and aptitude when the pin is in place. > > * The part of keeping "sysvinit" for having a fallback init was dropped >as it (meanwhile) got covered in 4.1.4.2[4.1.4]. As the removal of >sysvinit does not happen automatically, I asserted this was >sufficient. > > * The [4.1.4.2] section also covers how to reboot using sysvinit as >long as the bootloader supports changing the kernel command line >prior to booting. I know grub supports this and [1] suggests LILO >is also capable of doing this. > > A review is welcome - in particular please let me know if there are > things I left out that you believe should be included regardless. > > Thanks, > ~Niels > > [4.1.4] > https://www.debian.org/releases/jessie/amd64/release-notes/ch-upgrading.en.html#recovery > > (The closest I could get to a direct
Processed: Re: Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations
Processing control commands: tags -1 pending Bug #771825 [release-notes] release-notes: Update information on non-systemd Jessie upgrades and installations Added tag(s) pending. -- 771825: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771825 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-doc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b771825.14276409279351.transcr...@bugs.debian.org
Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations
Control: tags -1 pending On 2014-12-15 17:00, Svante Signell wrote: [...] Hi I trimmed the patch, less text now. However, the LILO comment is still there. Do you want me to remove that one too? Hi, I have applied a minor patch to day based on your patch submitted here (See attached). First hunk was accepted as-is (modulo whitespace). From the rest, I extracted some minor pieces if not already documented else where. In particular: * I documented that installing systemd-shim and sysvinit-core manually might help APT and aptitude when the pin is in place. * The part of keeping sysvinit for having a fallback init was dropped as it (meanwhile) got covered in 4.1.4.2[4.1.4]. As the removal of sysvinit does not happen automatically, I asserted this was sufficient. * The [4.1.4.2] section also covers how to reboot using sysvinit as long as the bootloader supports changing the kernel command line prior to booting. I know grub supports this and [1] suggests LILO is also capable of doing this. A review is welcome - in particular please let me know if there are things I left out that you believe should be included regardless. Thanks, ~Niels [4.1.4] https://www.debian.org/releases/jessie/amd64/release-notes/ch-upgrading.en.html#recovery (The closest I could get to a direct link to 4.1.4.2) [1] http://docstore.mik.ua/orelly/linux/lnut/ch04_05.htm From f7b12fd75b034b3da8868b944e247fd7b1c72f51 Mon Sep 17 00:00:00 2001 From: nthykier nthykier@313b444b-1b9f-4f58-a734-7bb04f332e8d Date: Sun, 29 Mar 2015 14:40:44 + Subject: [PATCH] issues: Improve the systemd section a bit Signed-off-by: Niels Thykier ni...@thykier.net git-svn-id: svn+ssh://svn.debian.org/svn/ddp/manuals/trunk/release-notes@10678 313b444b-1b9f-4f58-a734-7bb04f332e8d --- en/issues.dbk | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/en/issues.dbk b/en/issues.dbk index c74cb38..cb69026 100644 --- a/en/issues.dbk +++ b/en/issues.dbk @@ -316,8 +316,11 @@ $ echo 'openssh-server openssh-server/permit-root-login boolean true' | debconf- para Jessie ships with systemitem role=packagesystemd-sysv/systemitem as -emphasisdefault/emphasis init system. If you have a -preference for another init such as systemitem +emphasisdefault/emphasis init system. This package is +installed automatically on upgrades. + /para + para +If you have a preference for another init such as systemitem role=packagesysvinit-core/systemitem or systemitem role=packageupstart/systemitem, it is recommended to setup APT pinning prior to the upgrade. This may also be required if @@ -325,7 +328,7 @@ $ echo 'openssh-server openssh-server/permit-root-login boolean true' | debconf- please refer to xref linkend=issues-lxc-wheezy-host /. /para paraAs an example, to prevent systemitem -role=packagesystemd/systemitem from being installed during the +role=packagesystemd-sysv/systemitem from being installed during the upgrade, you can create a file called filename/etc/apt/preferences.d/local-pin-init/filename with the following contents: @@ -349,6 +352,12 @@ Pin-Priority: -1 role=packagesystemd-sysv/systemitem package must be installed first. /para + para +If APT or aptitude issues computing an upgrade path with the pin +in place, you may be able to help it by manually installing both +systemitem role=packagesysvinit-core/systemitem and +systemitem role=packagesystemd-shim/systemitem. + /para section id=systemd-auto-mounts-incompat !-- Wheezy to Jessie -- titleStricter handling of failing mounts during boot under systemd/title -- 2.1.4
Bug#769388: 'PermitRootLogin without-password' in new installations breaks some use cases
On 2015-01-26 00:16, Cyril Brulebois wrote: Niels Thykier ni...@thykier.net (2015-01-16): On Thu, 13 Nov 2014 11:08:45 + Simon McVittie s...@debian.org wrote: Another possibility would be to use a low-priority question that is only shown in the expert installer, but can be pre-seeded. Please also keep in mind that such questions need to be translated. I am not certain on the policy for d-i for having pre-seedable configuration without an expert question. Preseedable configuration is way lighter than (expert or not) questions, since it's only about an extra key/value to handle in scripts, and there's no need for translations. We have many of those, and we could support an extra one without too much hassle. Ok, sounds good. :) At first glance, having this question asked in expert mode wouldn't seem too crazy. I'm a bit worried about the timing though; this should have been noticed and worked on way earlier (this change happened in March). Sadly, we have had tons of issues in Debian, we ought to have discovered months ago. :-/ If this is not an issue for d-i, I suppose it could be added solely in the openssh-server-udeb package. Nice try. :) That udeb is here to provide ssh support during the installation process, it doesn't quite control what's happening in the system getting installed. Ok, where would something like this go then? I tried checking out the d-i source and I am yet to figure out the place where random preseedable/expert questions go. Is this case basically shove the debconf selections into the target system and let the regular .deb packages deal with it? If so, it seems that openssh mostly already permits this to be preseeded: if dpkg --compare-versions $2 lt-nl 1:6.6p1-1 \ [ $(get_config_option PermitRootLogin) = yes ] db_get openssh-server/permit-root-login [ $RET = true ]; then set_config_option PermitRootLogin without-password fi (I suspect it just needs a little fiddling with the --compare-versions) [...] If we are going down this route, then let us have it documented in the installation-guide. If needed be, we can add a reference from the release notes to the relevant part of the installation guide (or maybe just a remark about it). Though note that the release-notes only handles upgrades between the (soon-to-be) previous and the (soon-to-be) current release, so I firmly believe it should be documented in the installation-guide to ensure it is a stand-alone document. We can either document that late_command option (right now) or implement something specific to be preseeded, and document it when it's done. By the way: You wrote about the need for translations above, that applies to the installation guide as well. Mraw, KiBi. True - I assumed that the installation-guide was as easy to update on the website as the release-notes. I am ready to look into writing a patch for d-i to provide this to be preseedable. I am presume it needs to be documented somewhere in d-i (either as an expert question, in the installation-manual or in the standard preseed-example file). I do not mind doing it as an expert question as well assuming we still have time for getting translations. Thanks, ~Niels -- To UNSUBSCRIBE, email to debian-doc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54c73a2b.3060...@thykier.net
Bug#769388: 'PermitRootLogin without-password' in new installations breaks some use cases
Niels Thykier ni...@thykier.net (2015-01-27): Ok, where would something like this go then? I tried checking out the d-i source and I am yet to figure out the place where random preseedable/expert questions go. Is this case basically shove the debconf selections into the target system and let the regular .deb packages deal with it? If so, it seems that openssh mostly already permits this to be preseeded: if dpkg --compare-versions $2 lt-nl 1:6.6p1-1 \ [ $(get_config_option PermitRootLogin) = yes ] db_get openssh-server/permit-root-login [ $RET = true ]; then set_config_option PermitRootLogin without-password fi (I suspect it just needs a little fiddling with the --compare-versions) ... True - I assumed that the installation-guide was as easy to update on the website as the release-notes. I am ready to look into writing a patch for d-i to provide this to be preseedable. I am presume it needs to be documented somewhere in d-i (either as an expert question, in the installation-manual or in the standard preseed-example file). I do not mind doing it as an expert question as well assuming we still have time for getting translations. I've added this issue on my list of things to keep track for RC2. I should be able to try and deal with sorting out which package to patch, so that you can concentrate on other release-y things. Mraw, KiBi. signature.asc Description: Digital signature
Bug#769388: 'PermitRootLogin without-password' in new installations breaks some use cases
Niels Thykier ni...@thykier.net (2015-01-16): On Thu, 13 Nov 2014 11:08:45 + Simon McVittie s...@debian.org wrote: Another possibility would be to use a low-priority question that is only shown in the expert installer, but can be pre-seeded. Please also keep in mind that such questions need to be translated. I am not certain on the policy for d-i for having pre-seedable configuration without an expert question. Preseedable configuration is way lighter than (expert or not) questions, since it's only about an extra key/value to handle in scripts, and there's no need for translations. We have many of those, and we could support an extra one without too much hassle. At first glance, having this question asked in expert mode wouldn't seem too crazy. I'm a bit worried about the timing though; this should have been noticed and worked on way earlier (this change happened in March). If this is not an issue for d-i, I suppose it could be added solely in the openssh-server-udeb package. Nice try. :) That udeb is here to provide ssh support during the installation process, it doesn't quite control what's happening in the system getting installed. It is already possible to put something like this on the kernel command line when booting the installer, which might be useful: preseed/late_command=in-target sed -i 's/PermitRootLogin without-password/PermitRootLogin yes/' /etc/ssh/sshd_config If you are producing VM images that are designed to be cloned repeatedly, to make those VM images secure and correct, you already need a post-processing step to do things like deleting the ssh host key, setting a new unique systemd/D-Bus machine ID and so on; it seems If we are going down this route, then let us have it documented in the installation-guide. If needed be, we can add a reference from the release notes to the relevant part of the installation guide (or maybe just a remark about it). Though note that the release-notes only handles upgrades between the (soon-to-be) previous and the (soon-to-be) current release, so I firmly believe it should be documented in the installation-guide to ensure it is a stand-alone document. We can either document that late_command option (right now) or implement something specific to be preseeded, and document it when it's done. By the way: You wrote about the need for translations above, that applies to the installation guide as well. Mraw, KiBi. signature.asc Description: Digital signature
Processed: Re: Bug#769388: 'PermitRootLogin without-password' in new installations breaks some use cases
Processing control commands: tags 769388 moreinfo Bug #769388 [release-notes] 'PermitRootLogin without-password' in new installations breaks some use cases Added tag(s) moreinfo. -- 769388: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769388 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-doc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b769388.14216526593578.transcr...@bugs.debian.org
Bug#769388: 'PermitRootLogin without-password' in new installations breaks some use cases
Control: tags 769388 moreinfo On Sun, 18 Jan 2015 21:32:31 + Simon McVittie s...@debian.org wrote: Control: reassign 769388 release-notes Control: severity 769388 normal On 18/01/15 19:38, Michael Gilbert wrote: Isn't this also a documentation issue? A section could be added to the release notes on how to preseed a user for this type of installation use case? Yes, I think so. #726661 is a technical issue, not a documentation issue like #769388, but they were initially treated as a single bug because the symptom described in the original title (Does not permit login as root) could be caused by either. Anyway, I think both problems can be solved with more information in the release notes, so maybe reassign there? Makes sense to me. S Hi, I am a bit confused as to why you reassigned this to release-notes, when the remaining issue seems to be related to the debian-installer (which has its own documentation package called installation-guide). For the record, the /upgrade/ variant of this issue /is already/ documented in the release notes (and has been so for at least 2 weeks). Did you mean to reassign this to the installation-guide? Thanks, ~Niels -- To UNSUBSCRIBE, email to debian-doc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54bcb299.4010...@thykier.net
Processed: Re: Bug#769388: 'PermitRootLogin without-password' in new installations breaks some use cases
Processing control commands: reassign 769388 release-notes Bug #769388 [openssh-server] 'PermitRootLogin without-password' in new installations breaks some use cases Bug reassigned from package 'openssh-server' to 'release-notes'. No longer marked as found in versions openssh/1:6.6p1-1. Ignoring request to alter fixed versions of bug #769388 to the same values previously set severity 769388 normal Bug #769388 [release-notes] 'PermitRootLogin without-password' in new installations breaks some use cases Severity set to 'normal' from 'grave' -- 769388: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769388 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-doc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b769388.142161675216402.transcr...@bugs.debian.org
Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations
On Mon, Dec 15, 2014 at 05:00:32PM +0100, Svante Signell wrote: +It is also a good idea to install +systemitem role=package sysvinit-core, sysvint and sysvinit-utils Might you mean sysvinit instead of sysvint ? +/systemitem as the first packages when upgrading. -- hendrik -- To UNSUBSCRIBE, email to debian-doc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141220033642.ga14...@topoi.pooq.com
Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations
On Sun, 2014-12-14 at 17:01 +, Brian Potkin wrote: On Thu 04 Dec 2014 at 12:02:27 +0100, Svante Signell wrote: +It is also a good idea to install +systemitem role=package sysvinit-core, sysvint and sysvinit-utils +/systemitem as the first packages when upgrading. What is gained by doing this? If pinning is used sysvinit-core is installed. Are you sure? I'm not. Pinning is a help for apt and aptitude to resolve which packages to install. If sysvinit-core is installed before a dist-upgrade is done why bother with pinning? Other packages might install systemd-sysv by mistake? As was the case with libpam-systemd before the Depends: of libpam-systemd was changed to systemd-shim | systemd-sysv? Pinning helps you to avoid such mistakes. Aren't sysvint and sysvinit-utils already on the system and upgraded without doing anything special with them beforehand? Not sure about this either. Are you? -- To UNSUBSCRIBE, email to debian-doc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1418645602.18327.49.ca...@g3620.my.own.domain
Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations
On Sun, 2014-12-14 at 11:46 +0100, Joost van Baal-Ilić wrote: Hi Svante, Care to update the patch now that the CTTE-decision has been taken? I can apply the patch today. Thanks for your work! Bye, Attached is an updated patch, adding some information about apt-get upgrade and apt-get dist-upgrade, as well as the grub new entry. I'll create a Wheezy image and try out the examples in the patch (if/when time permits). Maybe somebody else is interested in helping out too? Thanks! Index: en/issues.dbk === --- en/issues.dbk (revision 10513) +++ en/issues.dbk (working copy) @@ -178,12 +178,15 @@ para Jessie ships with systemitem role=packagesystemd-sysv/systemitem as -emphasisdefault/emphasis init system. If you have a -preference for another init such as systemitem +emphasisdefault/emphasis init system. +This package is now installed automatically on upgrades. + /para + para +If you have a preference for another init such as systemitem role=packagesysvinit-core/systemitem or systemitem role=packageupstart/systemitem, it is recommended to setup APT pinning prior to the upgrade. As an example, to prevent -systemitem role=packagesystemd/systemitem from being +systemitem role=packagesystemd-sysv/systemitem from being installed during the upgrade, you can create a file called filename/etc/apt/preferences.d/local-pin-init/filename with the following contents: @@ -193,6 +196,11 @@ Pin: release o=Debian Pin-Priority: -1 /screen + para +Please note that the upgrade may install packages containing +systemd in their name even with APT pinning. These alone do +emphasisnot/emphasis change your init system. + /para caution para Be advised that some packages may have degraded behaviour or @@ -199,14 +207,51 @@ may be lacking features under a non-default init system. /para /caution + itemizedlist + listitem para -Please note that the upgrade may install packages containing -systemd in their name even with APT pinning. These alone do -emphasisnot/emphasis change your init system. To use -systemd as your init system, the systemitem -role=packagesystemd-sysv/systemitem package must be -installed first. +It is also a good idea to install +systemitem role=package sysvinit-core, sysvint and sysvinit-utils +/systemitem as the first packages when upgrading. + /para /listitem + listitem para apt-get upgrade from Wheezy to Jessie can boot + with init=/lib/sysvinit/init unless/until the old sysvinit package + is removed by e.g. autoclean. + caution + Don't autoclean until you have installed sysvinit-core if you + don't want systemd-sysv installed! + /caution + /para /listitem + listitem para apt-get dist-upgrade Wheezy to Jessie will get + systemd-sysv installed, and sysvinit will be history!! Otherwise + you need to install sysvinit-core on next reboot (if your system + boots). + caution + Don't dist-upgrade until you have installed sysvinit-core if you + don't want systemd-sysv installed! + /caution + /para /listitem + listitem para grub will get a new menu entry to boot with + init=/lib/sysvinit/init if something goes wrong with the switch to + systemd-sysv (unless you dist-upgrade). If you are using some other + bootloader, e.g. LILO you are on your own. /para /listitem + listitem para +If you have a desktop environment installed, it is also +recommended to install systemitem +role=packagesystemd-shim/systemitem to /para + itemizedlist + listitem para + assist apt and/or aptitude with the upgrade, + /para /listitem + listitem para avoid getting systemitem + role=packagesystemd-sysv/systemitem installed by mistake, + e.g. if you have forgotten to create the pinning file. /para + /listitem + /itemizedlist + /listitem + /itemizedlist + section id=systemd-auto-mounts-incompat !-- Wheezy to Jessie -- titleStricter handling of failing mounts during boot under systemd/title
Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations
On Mon, 2014-12-15 at 16:46 +0100, Joost van Baal-Ilić wrote: Hi again Svante, On closer look of the proposed patch, I feel the tone is not right. Text like apt-get dist-upgrade Wheezy to Jessie will get systemd-sysv installed, and sysvinit will be history!! Otherwise you need to install sysvinit-core on next reboot (if your system boots). is not suitable for our release notes. The release notes should emphasise default or very common scenarios. We assume most of our users to go with our new default choice of systemd. Those preferring other init systems might in general be better helped by e.g. pointing to a wiki page. I agree with what Osamu Aoki wrote on december 3, in slightly different context. However, if you can supply _short_ and _simple_ instructions on how to upgrade and keep the previously selected init-system, such instructions are likely suitable. I was a bit put off by your use of !!. I believe the 2 quoted sentences could better be dropped. Care to minimise and adjust the patch? Sorry for not raising this earlier. Hi I trimmed the patch, less text now. However, the LILO comment is still there. Do you want me to remove that one too? Index: en/issues.dbk === --- en/issues.dbk (revision 10513) +++ en/issues.dbk (working copy) @@ -178,12 +178,15 @@ para Jessie ships with systemitem role=packagesystemd-sysv/systemitem as -emphasisdefault/emphasis init system. If you have a -preference for another init such as systemitem +emphasisdefault/emphasis init system. +This package is now installed automatically on upgrades. + /para + para +If you have a preference for another init such as systemitem role=packagesysvinit-core/systemitem or systemitem role=packageupstart/systemitem, it is recommended to setup APT pinning prior to the upgrade. As an example, to prevent -systemitem role=packagesystemd/systemitem from being +systemitem role=packagesystemd-sysv/systemitem from being installed during the upgrade, you can create a file called filename/etc/apt/preferences.d/local-pin-init/filename with the following contents: @@ -193,6 +196,11 @@ Pin: release o=Debian Pin-Priority: -1 /screen + para +Please note that the upgrade may install packages containing +systemd in their name even with APT pinning. These alone do +emphasisnot/emphasis change your init system. + /para caution para Be advised that some packages may have degraded behaviour or @@ -199,14 +207,41 @@ may be lacking features under a non-default init system. /para /caution + itemizedlist + listitem para -Please note that the upgrade may install packages containing -systemd in their name even with APT pinning. These alone do -emphasisnot/emphasis change your init system. To use -systemd as your init system, the systemitem -role=packagesystemd-sysv/systemitem package must be -installed first. +It is also a good idea to install +systemitem role=package sysvinit-core, sysvint and sysvinit-utils +/systemitem as the first packages when upgrading. + /para /listitem + listitem para apt-get upgrade from Wheezy to Jessie can boot + with init=/lib/sysvinit/init until the old sysvinit package + is removed by e.g. autoclean. + /para /listitem + listitem para apt-get dist-upgrade Wheezy to Jessie will get + systemd-sysv installed, and sysvinit will be history. + /para /listitem + listitem para grub will get a new menu entry to boot with + init=/lib/sysvinit/init if something goes wrong with the switch to + systemd-sysv. If you are using some other bootloader, e.g. LILO you + are on your own. /para /listitem + listitem para +If you have a desktop environment installed, it is also +recommended to install systemitem +role=packagesystemd-shim/systemitem to /para + itemizedlist + listitem para + assist apt and/or aptitude with the upgrade, + /para /listitem + listitem para avoid getting systemitem + role=packagesystemd-sysv/systemitem installed by mistake, + e.g. if you have forgotten to create the pinning file. /para + /listitem + /itemizedlist + /listitem + /itemizedlist + section id=systemd-auto-mounts-incompat !-- Wheezy to Jessie -- titleStricter handling of failing mounts during boot under systemd/title
Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations
On Mon 15 Dec 2014 at 13:13:22 +0100, Svante Signell wrote: On Sun, 2014-12-14 at 17:01 +, Brian Potkin wrote: On Thu 04 Dec 2014 at 12:02:27 +0100, Svante Signell wrote: +It is also a good idea to install +systemitem role=package sysvinit-core, sysvint and sysvinit-utils +/systemitem as the first packages when upgrading. What is gained by doing this? If pinning is used sysvinit-core is installed. Are you sure? I'm not. Pinning is a help for apt and aptitude to resolve which packages to install. Here we both have in mind a Wheezy system with sysvinit (an essential package). I am sure that the pinning will lead to sysvinit-core being installed because of the dependencies of the init package. For a system with upstart sysvinit is not installed (they conflict). Such a system will not end up with systemd-sysv because of the pinning and the dependencies of the init package. If sysvinit-core is installed before a dist-upgrade is done why bother with pinning? Other packages might install systemd-sysv by mistake? As was the case with libpam-systemd before the Depends: of libpam-systemd was changed to systemd-shim | systemd-sysv? Pinning helps you to avoid such mistakes. Installing sysvinit-core first is fine if the Wheezy system has sysvinit to begin with; the dependencies of the init package are then satisfied. It would be a bad idea for upstart users to install sysvinit-core before doing a dist-upgrade. Aren't sysvint and sysvinit-utils already on the system and upgraded without doing anything special with them beforehand? Not sure about this either. Are you? I think you should become sure. Regards, Brian. -- To UNSUBSCRIBE, email to debian-doc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141215160636.gj19...@copernicus.demon.co.uk
Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations
On Mon 15 Dec 2014 at 17:00:32 +0100, Svante Signell wrote: Hi I trimmed the patch, less text now. However, the LILO comment is still there. Do you want me to remove that one too? A few other things should be considered for removal too. +It is also a good idea to install +systemitem role=package sysvinit-core, sysvint and sysvinit-utils +/systemitem as the first packages when upgrading. I have explained in another post why this is bad idea for Wheezy users of upstart who do not want to change. It isn't even a good idea when the user wants to keep sysvinit. It is unnecessary advice and should be omitted. + /para /listitem + listitem para apt-get upgrade from Wheezy to Jessie can boot + with init=/lib/sysvinit/init until the old sysvinit package + is removed by e.g. autoclean. 'autoclean' will not remove an installed package from the system. + listitem para +If you have a desktop environment installed, it is also +recommended to install systemitem +role=packagesystemd-shim/systemitem to /para + itemizedlist + listitem para + assist apt and/or aptitude with the upgrade, Why do apt/aptitude require assistance? They have the pinning file and the dependencies of libpam-systemd to go on. If either of them get it wrong it is a bug and to be reported. This advice is superfluous. + /para /listitem + listitem para avoid getting systemitem + role=packagesystemd-sysv/systemitem installed by mistake, + e.g. if you have forgotten to create the pinning file. /para Apt's resolver not working would be a bug. A user error would not be a bug. The presence or absence of systemd-shim has no bearing on whether systemd-sysv is installed. This advice is technically incorrect and also superfluous. Regards, Brian. -- To UNSUBSCRIBE, email to debian-doc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/15122014173249.50948b89f...@desktop.copernicus.demon.co.uk
Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations
Hi Svante, Brian: thanks for your comments; I tend to agree. I've just checked; the patch applies: joostvb@nusku:~/svn/release-notes% patch -p0 /tmp/en_issues.dbk.patch patching file en/issues.dbk Hunk #1 succeeded at 206 (offset 28 lines). Hunk #2 succeeded at 224 (offset 28 lines). Hunk #3 succeeded at 235 (offset 28 lines). . Some more comments/issues with the patch: Chapter 5. Issues to be aware of for jessie is about Sometimes, changes introduced in a new release have side-effects we cannot reasonably avoid, or they expose bugs somewhere else. This section documents issues we are aware of. I feel tips on how to override the new default init system do not belong here. Another place would likely be more suitable. Why do you use an itemizedlist? I feel just putting the listitems in normal paragraphs is better. On Mon, Dec 15, 2014 at 06:10:08PM +, Brian Potkin wrote: On Mon 15 Dec 2014 at 17:00:32 +0100, Svante Signell wrote: Hi I trimmed the patch, less text now. However, the LILO comment is still there. Do you want me to remove that one too? grub will get a new menu entry to boot with init=/lib/sysvinit/init if something goes wrong with the switch to systemd-sysv. If you are using some other bootloader, e.g. LILO you are on your own. Perhaps something like: If you don't use grub as bootloader, but e.g. LILO, changing to grub before upgrading to Jessie makes the upgrade more robust. During the migration from SysV init to systemd, grub will have an entry init=/lib/sysvinit/init, in order to keep the system bootable with the old SysV. . A few other things should be considered for removal too. snip + /para /listitem + listitem para apt-get upgrade from Wheezy to Jessie can boot + with init=/lib/sysvinit/init until the old sysvinit package + is removed by e.g. autoclean. 'autoclean' will not remove an installed package from the system. So just remove by e.g. autoclean. + listitem para +If you have a desktop environment installed, it is also +recommended to install systemitem +role=packagesystemd-shim/systemitem to /para + itemizedlist + listitem para + assist apt and/or aptitude with the upgrade, Why do apt/aptitude require assistance? They have the pinning file and the dependencies of libpam-systemd to go on. If either of them get it wrong it is a bug and to be reported. This advice is superfluous. I suggest something like: The package systemitem role=packagesystemd-shim/systemitem implements interfaces needed by desktop environment helpers expecting systemd-like functionality. The packagemanagement system will install this package if you use such a desktop environment without running systemd as init system. Bye, Joost -- To UNSUBSCRIBE, email to debian-doc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141216072558.gb3...@beskar.mdcc.cx
Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations
On Thu 04 Dec 2014 at 12:02:27 +0100, Svante Signell wrote: +It is also a good idea to install +systemitem role=package sysvinit-core, sysvint and sysvinit-utils +/systemitem as the first packages when upgrading. What is gained by doing this? If pinning is used sysvinit-core is installed. If sysvinit-core is installed before a dist-upgrade is done why bother with pinning? Aren't sysvint and sysvinit-utils already on the system and upgraded without doing anything special with them beforehand? Regards, Brian. -- To UNSUBSCRIBE, email to debian-doc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141214170115.ga1...@copernicus.demon.co.uk
Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations
On Thu 04 Dec 2014 at 12:02:27 +0100, Svante Signell wrote: +If you have a desktop environment installed, it is also +recommended to install systemitem +role=packagesystemd-shim/systemitem to + /para + itemizedlist + listitem para + assist apt and/or aptitude with the upgrade, + /para /listitem + listitem para + avoid getting systemitem role=packagesystemd-sysv/systemitem +installed by mistake. Which DE would not install systemd-shim when the recommended pinning is done? How can systemd-sysv be installed by mistake when the Depends: of libpam-systemd include systemd-shim | systemd-sysv? Regards, Brian. -- To UNSUBSCRIBE, email to debian-doc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/14122014235749.0987335cc...@desktop.copernicus.demon.co.uk
Re: Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations
On Jo, 04 dec 14, 12:02:27, Svante Signell wrote: Indeed, the package name is systemd-sysv. Though perhaps we should change it to systemd without marking it as a package. I presume that the user/admin is less interested in the actual package name and more in the name of the init system. Problem is: Does the pinning work if it is on systemd instead of systemd-sysv? The the pin would be about any systemd component? systemd-sysv Depends: systemd, so yes, it should work. However, since libpam-systemd (and AFAIU systemd-shim might as well) also depends on it this would effectively prevent one from installing anything that Depends: libpam-systemd Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations
On Wed, 2014-12-03 at 22:07 +0100, Niels Thykier wrote: On 2014-12-03 11:56, Svante Signell wrote: On Tue, 2014-12-02 at 23:01 +0100, Svante Signell wrote: [...] Index: en/issues.dbk === --- en/issues.dbk (revision 10513) +++ en/issues.dbk (working copy) @@ -183,7 +183,7 @@ role=packagesysvinit-core/systemitem or systemitem role=packageupstart/systemitem, it is recommended to setup APT pinning prior to the upgrade. As an example, to prevent -systemitem role=packagesystemd/systemitem from being +systemitem role=packagesystemd-sysv/systemitem from being Indeed, the package name is systemd-sysv. Though perhaps we should change it to systemd without marking it as a package. I presume that the user/admin is less interested in the actual package name and more in the name of the init system. Problem is: Does the pinning work if it is on systemd instead of systemd-sysv? The the pin would be about any systemd component? installed during the upgrade, you can create a file called filename/etc/apt/preferences.d/local-pin-init/filename with the following contents: @@ -193,12 +193,16 @@ Pin: release o=Debian Pin-Priority: -1 /screen - caution -para - Be advised that some packages may have degraded behaviour or - may be lacking features under a non-default init system. -/para - /caution I am not too happy with pushing the caution down. To be honest, I have been considering to push it up. Pushed up, as you wish. + note I am not entirely convinced this should be a note rather than a para. Fixed by using itemizedlist instead! +It is also good to install It is also a good idea to install ...? Fixed! +systemitem role=package sysvinit-core, sysvint and sysvinit-utils +/systemitem as the first packages when upgrading. In case +you want an emphasisas-systemd-free-as-possible/emphasis Not sure why the emphasis here. To be honest, the sentence strikes me as a bit odd (and possibly a bit long). Maybe just add it to the list above or simply just: If you have a desktop environment installed, it is also recommended to install systemd-shim to assist apt or/and aptitude with the upgrade path. Rewritten! +desktop environment, it is also recommended to install systemitem +role=packagesystemd-shim/systemitem in order to +help apt and aptitude to avoid installing systemd-sysv and +other *systemd* components, unintentionally. ^ Fixed! Why the *X*? We got emphasis if you want to highlight. Then again, see my previous remark about the entire sentence. New patch attached. Better now? Note the comment about the CTTE decision today (hopefully) about default init system on upgrades! Index: en/issues.dbk === --- en/issues.dbk (revision 10513) +++ en/issues.dbk (working copy) @@ -178,12 +178,16 @@ para Jessie ships with systemitem role=packagesystemd-sysv/systemitem as -emphasisdefault/emphasis init system. If you have a -preference for another init such as systemitem +emphasisdefault/emphasis init system. +This package is installed automatically on upgrades +emphasis(pending the CTTE decision today)/emphasis. + /para + para +If you have a preference for another init such as systemitem role=packagesysvinit-core/systemitem or systemitem role=packageupstart/systemitem, it is recommended to setup APT pinning prior to the upgrade. As an example, to prevent -systemitem role=packagesystemd/systemitem from being +systemitem role=packagesystemd-sysv/systemitem from being installed during the upgrade, you can create a file called filename/etc/apt/preferences.d/local-pin-init/filename with the following contents: @@ -193,6 +197,11 @@ Pin: release o=Debian Pin-Priority: -1 /screen + para +Please note that the upgrade may install packages containing +systemd in their name even with APT pinning. These alone do +emphasisnot/emphasis change your init system. + /para caution para Be advised that some packages may have degraded behaviour or @@ -199,14 +208,32 @@ may be lacking features under a non-default init system. /para /caution + itemizedlist + listitem para -Please note that the upgrade may install packages containing -systemd in their name even with APT pinning. These alone do -emphasisnot/emphasis change your init system. To use -systemd as your init system, the systemitem -role=packagesystemd-sysv/systemitem package must be -installed first. +It is also a good idea to install +systemitem role=package sysvinit-core, sysvint and sysvinit-utils +/systemitem as the first packages when upgrading. /para + /listitem + listitem
Bug#771825: [Fwd: Re: Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations]
On Wed, 2014-12-03 at 23:56 +0100, Javier Fernández-Sanguino Peña wrote: On Wed, Dec 03, 2014 at 05:13:38PM +0100, Svante Signell wrote: Hi Osamu, I will make a modified proposal to the actual document. However there is no installation-guide on this page: https://anonscm.debian.org/viewvc/ddp/manuals/trunk/ Where is it? The sources for the installation guide are available at https://anonscm.debian.org/viewvc/d-i/trunk/manual/en/ The web builds for the guide are available here: https://www.debian.org/releases/jessie/installmanual These might be useful for you in order to get a feeling of its structure and determine where chapter/section should your contributions go to. Javier, (and Osamu) Thanks for the info. I have now downloaded the installation-guide manual with apt-get source installation-guide-amd64. How to build e.g. the html part? -- To UNSUBSCRIBE, email to debian-doc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1417703169.3453.63.ca...@g3620.my.own.domain
Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations
Hi, (I don't know if it's still a good idea to keep this bug report in Cc, as installation-guide is handled by -boot@) Dixit Svante Signell, le 04/12/2014 : Thanks for the info. I have now downloaded the installation-guide manual with apt-get source installation-guide-amd64. How to build e.g. the html part? You can read ./doc/*.txt (especially building.txt) In short : ./build/buildone.sh architecture language format(s) Can you please submit your patch for installation-guide to -boot@ or report bug against installation-guide. Thanks Baptiste signature.asc Description: PGP signature
Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations
On Tue, 2014-12-02 at 23:01 +0100, Svante Signell wrote: On Tue, 2014-12-02 at 22:16 +0100, Niels Thykier wrote: On 2014-12-02 18:17, Svante Signell wrote: Package: release-notes Severity: Important [1] I would be expecting you to modify a file called en/issues.dbk... and I am not sure what the numbers at the beginning of each line is doing in an XML document, but... Attached is a svn diff for the release-notes. Comments are welcomed. Regarding the Installation guide for the second hunk, where to get that stuff? Thanks! Index: en/issues.dbk === --- en/issues.dbk (revision 10513) +++ en/issues.dbk (working copy) @@ -183,7 +183,7 @@ role=packagesysvinit-core/systemitem or systemitem role=packageupstart/systemitem, it is recommended to setup APT pinning prior to the upgrade. As an example, to prevent -systemitem role=packagesystemd/systemitem from being +systemitem role=packagesystemd-sysv/systemitem from being installed during the upgrade, you can create a file called filename/etc/apt/preferences.d/local-pin-init/filename with the following contents: @@ -193,12 +193,16 @@ Pin: release o=Debian Pin-Priority: -1 /screen - caution -para - Be advised that some packages may have degraded behaviour or - may be lacking features under a non-default init system. -/para - /caution + note +It is also good to install +systemitem role=package sysvinit-core, sysvint and sysvinit-utils +/systemitem as the first packages when upgrading. In case +you want an emphasisas-systemd-free-as-possible/emphasis +desktop environment, it is also recommended to install systemitem +role=packagesystemd-shim/systemitem in order to +help apt and aptitude to avoid installing systemd-sysv and +other *systemd* components, unintentionally. + /note para Please note that the upgrade may install packages containing systemd in their name even with APT pinning. These alone do @@ -207,6 +211,12 @@ role=packagesystemd-sysv/systemitem package must be installed first. /para + caution +para + Be advised that some packages may have degraded behaviour or + may be lacking features under a non-default init system. +/para + /caution section id=systemd-auto-mounts-incompat !-- Wheezy to Jessie -- titleStricter handling of failing mounts during boot under systemd/title
Bug#771825: [Fwd: Re: Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations]
---BeginMessage--- On Wed, 2014-12-03 at 22:02 +0900, Osamu Aoki wrote: Hi, Niels and Javi said well for release-notes and translation time-line of installation-guide against the freeze. If you are thinking of submitting a patch to installation-guide for the following part, I reminds you few things to get it accepted. This is too long and the tone of text is not right. Hi Osamu, I will make a modified proposal to the actual document. However there is no installation-guide on this page: https://anonscm.debian.org/viewvc/ddp/manuals/trunk/ Where is it? Thanks! ---End Message---
Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations
On Wed, 2014-12-03 at 17:12 +0100, Svante Signell wrote: I will make a modified proposal to the actual document. However there is no installation-guide on this page: https://anonscm.debian.org/viewvc/ddp/manuals/trunk/ Why should there be? The installation-guide package has Vcs-* headers. They work. Regards, Adam -- To UNSUBSCRIBE, email to debian-doc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1417640866.10998.15.ca...@adam-barratt.org.uk
Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations
On 2014-12-03 11:56, Svante Signell wrote: On Tue, 2014-12-02 at 23:01 +0100, Svante Signell wrote: [...] Hi, Attached is a svn diff for the release-notes. Comments are welcomed. Thanks, find my remarks interleaved in the patch. Regarding the Installation guide for the second hunk, where to get that stuff? I believe it is a real package (compared to the release-notes, which is just a pseudo-package). Thanks! en_issues.dbk.patch Index: en/issues.dbk === --- en/issues.dbk (revision 10513) +++ en/issues.dbk (working copy) @@ -183,7 +183,7 @@ role=packagesysvinit-core/systemitem or systemitem role=packageupstart/systemitem, it is recommended to setup APT pinning prior to the upgrade. As an example, to prevent -systemitem role=packagesystemd/systemitem from being +systemitem role=packagesystemd-sysv/systemitem from being Indeed, the package name is systemd-sysv. Though perhaps we should change it to systemd without marking it as a package. I presume that the user/admin is less interested in the actual package name and more in the name of the init system. installed during the upgrade, you can create a file called filename/etc/apt/preferences.d/local-pin-init/filename with the following contents: @@ -193,12 +193,16 @@ Pin: release o=Debian Pin-Priority: -1 /screen - caution -para - Be advised that some packages may have degraded behaviour or - may be lacking features under a non-default init system. -/para - /caution I am not too happy with pushing the caution down. To be honest, I have been considering to push it up. + note I am not entirely convinced this should be a note rather than a para. +It is also good to install It is also a good idea to install ...? +systemitem role=package sysvinit-core, sysvint and sysvinit-utils +/systemitem as the first packages when upgrading. In case +you want an emphasisas-systemd-free-as-possible/emphasis Not sure why the emphasis here. To be honest, the sentence strikes me as a bit odd (and possibly a bit long). Maybe just add it to the list above or simply just: If you have a desktop environment installed, it is also recommended to install systemd-shim to assist apt or/and aptitude with the upgrade path. +desktop environment, it is also recommended to install systemitem +role=packagesystemd-shim/systemitem in order to +help apt and aptitude to avoid installing systemd-sysv and +other *systemd* components, unintentionally. ^ Why the *X*? We got emphasis if you want to highlight. Then again, see my previous remark about the entire sentence. [...] Thanks for considering, ~Niels -- To UNSUBSCRIBE, email to debian-doc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/547f7b97.6020...@thykier.net
Bug#771825: [Fwd: Re: Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations]
On Wed, Dec 03, 2014 at 05:13:38PM +0100, Svante Signell wrote: Hi Osamu, I will make a modified proposal to the actual document. However there is no installation-guide on this page: https://anonscm.debian.org/viewvc/ddp/manuals/trunk/ Where is it? The sources for the installation guide are available at https://anonscm.debian.org/viewvc/d-i/trunk/manual/en/ The web builds for the guide are available here: https://www.debian.org/releases/jessie/installmanual These might be useful for you in order to get a feeling of its structure and determine where chapter/section should your contributions go to. Best regards Javier signature.asc Description: Digital signature
Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations
Package: release-notes Severity: Important Hello, As promised on debian-devel attached is a first proposal for an update of the release notes. There are two small issues with the patch: - The text is edited without seeing the markup result. How to do that? - The second part about preseeding will be tested tonight, and an updated patch will be submitted if any changes are needed. Thanks! --- release_notes.current 2014-12-02 16:45:21.060959945 +0100 +++ release_notes.updated 2014-12-02 18:15:00.936959303 +0100 @@ -19,6 +19,16 @@ 193 Pin: release o=Debian 194 Pin-Priority: -1 195 /screen + + para + It is also good to install sysvinit-core, sysvint and + sysvinit-utils as the first packages when upgrading. In case + you want an as-systemd-free-as-possible desktop environment, + it is also recommended to install systemd-shim, in order to + help apt and aptitude to avoid installing systemd-sysv and + other *systemd* components, unintentionally. + /para + 196 caution 197 para 198 Be advised that some packages may have degraded behaviour or @@ -33,3 +43,43 @@ 207 role=packagesystemd-sysv/systemitem package must be 208 installed first. 209 /para + + !-- New installations of Jessie -- + titleHow to avoid the default init system for Jessie/title + para + For new installations of Jessie the default init system + systemd-sysvinit will be installed. In order to run a + traditional init system, such as sysvinit-core, two + workarounds are available: + + para + 1) Go through the installation, selecting the minimum number + of packages, maybe do only select standard (or use + netinst.iso). After the installation and first reboot, + install sysvinit-core and remove systemd-sysv (and maybe + other *systemd* packages). If a desktop is to be + installed install systemd-shim first before choosing other + components. + /para + + para + 2) Use a preseed command to finish the install with + sysvinit-core instead of systemd-core. (again choosing a + minimum installation) + screen + Choose Advanced options + Choose ### Running custom commands during the installation + /screen + Issue + screen + preseed/late_command=in-target apt-get install -y sysvinit-core + /screen + and continue with the installation. + For further info see + https://wiki.debian.org/systemd#Installing_without_systemd + and + screen + http://d-i.debian.org/manual/en.i386/apbs05.html + http://d-i.debian.org/manual/example-preseed.txt + /screen + /para
Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations
On 2014-12-02 18:17, Svante Signell wrote: Package: release-notes Severity: Important Hello, As promised on debian-devel attached is a first proposal for an update of the release notes. There are two small issues with the patch: - The text is edited without seeing the markup result. How to do that? - The second part about preseeding will be tested tonight, and an updated patch will be submitted if any changes are needed. Thanks! Hi, Thanks for taking the time to write a patch for the release notes. I have two remarks: * It is not clear to me that this is a valid patch against the original source of the release notes (SVN)[1]. I can certainly extract the relevant parts and apply it manually, but this is inefficient use of our time (yours and mine) in the long run. * The second hunk of the patch seems better suited for the installation-guide. The release notes concerns itself with upgrades and does not cover the debian-installer. The original source of the release notes is at [2]. There is a git clone maintained by Julien at [3] if you prefer git over SVN. To build the release notes (for a single language and architecture), you run: make html LINGUA=en architecture=amd64 Which would build the English HTML version for amd64. The generated output will be in en/release-notes.amd64.html/index.en.html. NB: Some parts of the build system assumes you have a subversion checkout. The above command does not, but if you simply run make without any arguments you will trigger some of them. ~Niels [1] I would be expecting you to modify a file called en/issues.dbk... and I am not sure what the numbers at the beginning of each line is doing in an XML document, but... [2] https://anonscm.debian.org/viewvc/ddp/manuals/trunk/release-notes/ [3] https://anonscm.debian.org/cgit/users/jcristau/release-notes.git/ -- To UNSUBSCRIBE, email to debian-doc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/547e2c3f.9030...@thykier.net
Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations
On Tue, 2014-12-02 at 22:16 +0100, Niels Thykier wrote: On 2014-12-02 18:17, Svante Signell wrote: Package: release-notes Severity: Important Hello, As promised on debian-devel attached is a first proposal for an update of the release notes. There are two small issues with the patch: - The text is edited without seeing the markup result. How to do that? - The second part about preseeding will be tested tonight, and an updated patch will be submitted if any changes are needed. Thanks! Hi, Thanks for taking the time to write a patch for the release notes. I have two remarks: * It is not clear to me that this is a valid patch against the original source of the release notes (SVN)[1]. I can certainly extract the relevant parts and apply it manually, but this is inefficient use of our time (yours and mine) in the long run. See below. * The second hunk of the patch seems better suited for the installation-guide. The release notes concerns itself with upgrades and does not cover the debian-installer. Somebody was complaining that changing the installation-guide was a lot of work, e.g. translations work, and did not want the changes to be made there https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765803#40 I don't mind getting the second part included there instead. The original source of the release notes is at [2]. There is a git clone maintained by Julien at [3] if you prefer git over SVN. To build the release notes (for a single language and architecture), you run: make html LINGUA=en architecture=amd64 Which would build the English HTML version for amd64. The generated output will be in en/release-notes.amd64.html/index.en.html. NB: Some parts of the build system assumes you have a subversion checkout. The above command does not, but if you simply run make without any arguments you will trigger some of them. I will fix that tomorrow, thanks! ~Niels [1] I would be expecting you to modify a file called en/issues.dbk... and I am not sure what the numbers at the beginning of each line is doing in an XML document, but... I did cut and paste from the web page in iceweasel: https://anonscm.debian.org/viewvc/ddp/manuals/trunk/release-notes/en/issues.dbk?view=markuppathrev=10511 That's where the line numbers came from. I should have downloaded the page and edited that one instead. [2] https://anonscm.debian.org/viewvc/ddp/manuals/trunk/release-notes/ [3] https://anonscm.debian.org/cgit/users/jcristau/release-notes.git/ -- To UNSUBSCRIBE, email to debian-doc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1417557676.3453.19.ca...@g3620.my.own.domain
Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations
On Tue, Dec 02, 2014 at 11:01:16PM +0100, Svante Signell wrote: * The second hunk of the patch seems better suited for the installation-guide. The release notes concerns itself with upgrades and does not cover the debian-installer. Somebody was complaining that changing the installation-guide was a lot of work, e.g. translations work, and did not want the changes to be made there https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765803#40 I don't mind getting the second part included there instead. Translators (and I'm one of them) will have to update the installation-guide before the release. I think it's better to have the document where it should be and also agree that the Release Notes is not the place for that chunk. Best regards Javier signature.asc Description: Digital signature
