Bug#694928: asks for confirmation on config-file change on /etc/default/rcS, while file didn't change
On Wed, Feb 06, 2013 at 04:59:04PM +0100, Michael Stapelberg wrote: On Sun, 2 Dec 2012 23:47:37 + Roger Leigh rle...@codelibre.net wrote: Please don't apply it just yet--we'll presumably need to get approval from the release team to change this in initscripts at the same time. I'll have a patch for initscripts shortly; might be a bit later in the week to allow for comprehensive testing. What’s the status on this? It’s been 2 months :-). I did send a mail to -release a week or so back, but haven't seen a response yet. Doing the change in initscripts is fairly trivial, but introducing a configuration file change at this point is probably not a great idea. If it's needed, I'll be happy to do it though. While editing a conffile isn't a good idea in general, the actual impact here is very low, and it's limited to ARM users, so if the consensus is that it's ignorable for wheezy, I'll be equally happy to postpone this for jessie and we can do the needed changes early in the jessie release cycle. Bottom line: I'll be happy to do whatever is needed. Just need some feedback on what is acceptable here. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20130206163445.ga21...@codelibre.net
Re: Bug#694928: asks for confirmation on config-file change on /etc/default/rcS, while file didn't change
On Mon, Dec 03, 2012 at 01:20:50PM +, Ben Hutchings wrote: On Mon, 2012-12-03 at 00:44 +, Roger Leigh wrote: On Sun, Dec 02, 2012 at 11:49:44PM +, Roger Leigh wrote: On Sun, Dec 02, 2012 at 11:47:37PM +, Roger Leigh wrote: clone 694928 -1 reassign -1 initscripts thanks On Sun, Dec 02, 2012 at 12:23:07PM +0100, Martin Zobel-Helas wrote: Please find attached an example patch for flash-kernel to support old and new (rcS and fsck) locations for FSCKFIX as discussed on #debian-devel earlier. Hmm, actually attached now. Slight update to cope with commented-out lines (as provided by default). This should really be the default for everyone... how many people know their filesystem well enough to answer fsck prompts intelligently? I would personally be happy with it being set by default. However, the few times this has been brought up, there have been a number of examples where this might result in filesystem corruption. I think the main argument was that the admin might want to take an image before fsck ran, in case fsck caused further problems. I'd have to check, but IIRC other issues included checking parts of unreconstructed RAID arrays and/or LVM PVs, but I don't think this is very likely. I'd be tempted to enable it by default across the board, and require admins who want this extra safety to explicitly disable checking. The vast majority of users will benefit from this, since they can't intelligently answer the prompts as you say. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20121203135743.gz14...@codelibre.net
Bug#694928: asks for confirmation on config-file change on /etc/default/rcS, while file didn't change
clone 694928 -1 reassign -1 initscripts thanks On Sun, Dec 02, 2012 at 12:23:07PM +0100, Martin Zobel-Helas wrote: Please find attached an example patch for flash-kernel to support old and new (rcS and fsck) locations for FSCKFIX as discussed on #debian-devel earlier. Please don't apply it just yet--we'll presumably need to get approval from the release team to change this in initscripts at the same time. I'll have a patch for initscripts shortly; might be a bit later in the week to allow for comprehensive testing. Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20121202234737.gt14...@codelibre.net
Bug#694928: asks for confirmation on config-file change on /etc/default/rcS, while file didn't change
On Sun, Dec 02, 2012 at 11:47:37PM +, Roger Leigh wrote: clone 694928 -1 reassign -1 initscripts thanks On Sun, Dec 02, 2012 at 12:23:07PM +0100, Martin Zobel-Helas wrote: Please find attached an example patch for flash-kernel to support old and new (rcS and fsck) locations for FSCKFIX as discussed on #debian-devel earlier. Hmm, actually attached now. -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 From 300eb0dcd6abc4ced0596f87a33d3165d46779e5 Mon Sep 17 00:00:00 2001 From: Roger Leigh rle...@debian.org Date: Sun, 2 Dec 2012 23:34:57 + Subject: [PATCH] debian: Update /etc/default/fsck in flash-kernel-installer postinst --- debian/changelog | 10 ++ debian/flash-kernel-installer.postinst |7 ++- 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index 68c673b..526f1ec 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,13 @@ +flash-kernel (3.4) UNRELEASED; urgency=low + + [ Roger Leigh ] + * flash-kernel-installer postinst: Update FSCKFIX in +/etc/default/fsck as well as /etc/default/rcS for backward +compatibility. The purpose is to use /etc/default/fsck for +new installations. + + -- Roger Leigh rle...@debian.org Sun, 02 Dec 2012 23:33:24 + + flash-kernel (3.3) unstable; urgency=low * Replace XC-Package-Type by Package-Type diff --git a/debian/flash-kernel-installer.postinst b/debian/flash-kernel-installer.postinst index c07dee5..311615d 100755 --- a/debian/flash-kernel-installer.postinst +++ b/debian/flash-kernel-installer.postinst @@ -35,7 +35,12 @@ db_progress INFO flash-kernel-installer/prepare # Stop fsck from prompting the user for input since most users don't # have a serial console. -sed -i s/^FSCKFIX=no$/FSCKFIX=yes/ /target/etc/default/rcS || true +if [ -e /target/etc/default/rcS ]; then + sed -i -e s/^FSCKFIX=no$/FSCKFIX=yes/ /target/etc/default/rcS || true +fi +if [ -e /target/etc/default/fsck ]; then + sed -i -e s/^FSCKFIX=no$/FSCKFIX=yes/ /target/etc/default/fsck || true +fi if ! apt-install flash-kernel; then error apt-install flash-kernel failed -- 1.7.10.4
Bug#694928: asks for confirmation on config-file change on /etc/default/rcS, while file didn't change
On Sun, Dec 02, 2012 at 11:49:44PM +, Roger Leigh wrote: On Sun, Dec 02, 2012 at 11:47:37PM +, Roger Leigh wrote: clone 694928 -1 reassign -1 initscripts thanks On Sun, Dec 02, 2012 at 12:23:07PM +0100, Martin Zobel-Helas wrote: Please find attached an example patch for flash-kernel to support old and new (rcS and fsck) locations for FSCKFIX as discussed on #debian-devel earlier. Hmm, actually attached now. Slight update to cope with commented-out lines (as provided by default). -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 From 4db3a50a7bd6b11f3a4fa425e5e2c9b7cf1c9673 Mon Sep 17 00:00:00 2001 From: Roger Leigh rle...@debian.org Date: Sun, 2 Dec 2012 23:34:57 + Subject: [PATCH] debian: Update /etc/default/fsck in flash-kernel-installer postinst --- debian/changelog | 10 ++ debian/flash-kernel-installer.postinst |7 ++- 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index 68c673b..526f1ec 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,13 @@ +flash-kernel (3.4) UNRELEASED; urgency=low + + [ Roger Leigh ] + * flash-kernel-installer postinst: Update FSCKFIX in +/etc/default/fsck as well as /etc/default/rcS for backward +compatibility. The purpose is to use /etc/default/fsck for +new installations. + + -- Roger Leigh rle...@debian.org Sun, 02 Dec 2012 23:33:24 + + flash-kernel (3.3) unstable; urgency=low * Replace XC-Package-Type by Package-Type diff --git a/debian/flash-kernel-installer.postinst b/debian/flash-kernel-installer.postinst index c07dee5..e9b88c7 100755 --- a/debian/flash-kernel-installer.postinst +++ b/debian/flash-kernel-installer.postinst @@ -35,7 +35,12 @@ db_progress INFO flash-kernel-installer/prepare # Stop fsck from prompting the user for input since most users don't # have a serial console. -sed -i s/^FSCKFIX=no$/FSCKFIX=yes/ /target/etc/default/rcS || true +if [ -e /target/etc/default/rcS ]; then + sed -i -e s/^FSCKFIX=no$/FSCKFIX=yes/ /target/etc/default/rcS || true +fi +if [ -e /target/etc/default/fsck ]; then + sed -i -e s/^#FSCKFIX=no$/FSCKFIX=yes/ -e s/^FSCKFIX=no$/FSCKFIX=yes/ /target/etc/default/fsck || true +fi if ! apt-install flash-kernel; then error apt-install flash-kernel failed -- 1.7.10.4
Bug#674481: partman-target: Please remove /proc from generated fstab for wheezy
Package: partman-target Version: 77 Severity: important Tags: patch /proc has been created as part of the default /etc/fstab for some time. However, this is not needed, and has been found to be detrimental in some cases. /proc is mounted by the initramfs (if used), or else by the mountkernfs init script, making the fstab entry redundant. If the naming of the filesystem differs to the name used in the initramfs or init scripts, this can cause the mountall script to fail. #425199 is an example of this. Note this obsoletes #378984; mountkernfs now uses the mount options from /etc/fstab for all filesystems /if present/, meaning that no special support is required on the part of the installer, given that the regular initscripts handle this job in the general case--no special /proc support is required. In short, removing /proc has zero downside--it's all handled outside fstab by default, and has been since forever, and we pick up the settings from /proc should there be an entry there, so we're both backward compatible /and/ customisable by the admin. Regards, Roger -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (550, 'unstable'), (500, 'testing'), (400, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash From 5da5941d594e4d02054d9f14549e70e8af87f0fd Mon Sep 17 00:00:00 2001 From: Roger Leigh rle...@debian.org Date: Fri, 25 May 2012 00:05:52 +0100 Subject: [PATCH] create_fstab_header: Drop /proc /proc has been created as part of the default /etc/fstab for some time. However, this is not needed, and has been found to be detrimental in some cases. /proc is mounted by the initramfs (if used), or else by the mountkernfs init script, making the fstab entry redundant. If the naming of the filesystem differs to the name used in the initramfs or init scripts, this can cause the mountall script to fail. Signed-off-by: Roger Leigh rle...@debian.org --- finish.d/create_fstab_header |2 -- 1 file changed, 2 deletions(-) diff --git a/finish.d/create_fstab_header b/finish.d/create_fstab_header index 8aece0d..e99fa5e 100755 --- a/finish.d/create_fstab_header +++ b/finish.d/create_fstab_header @@ -13,8 +13,6 @@ case `udpkg --print-os` in # EOF printf %-15s %-15s %-7s %-15s %-7s %s\n '# file system' 'mount point' 'type' 'options' 'dump' 'pass' /target/etc/fstab - - printf %-15s %-15s %-7s %-15s %-7s %s\n proc /proc proc defaults 0 0 /target/etc/fstab ;; kfreebsd) -- 1.7.10
Bug#660093: clock-setup: Please support /etc/adjtime in addition to /etc/default
On Thu, Feb 16, 2012 at 11:10:42AM +, Roger Leigh wrote: The following patch is also required to remove the use of /etc/default/hwclock given that we never used it for the UTC setting, since we moved it to /etc/adjtime directly. Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. From c21d1791ae7a34ea85bcd9544bf811b944fc2777 Mon Sep 17 00:00:00 2001 From: Roger Leigh rle...@debian.org Date: Mon, 21 May 2012 20:06:26 +0100 Subject: [PATCH] 10clock-setup: Revert use of /etc/default/hwclock This was never used for the UTC setting given that we migrate it directly from /etc/default/rcS, so it's no longer needed it clock-setup. --- debian/changelog |7 ++- finish-install.d/10clock-setup |6 +- 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/debian/changelog b/debian/changelog index 3e627c7..3b3912a 100644 --- a/debian/changelog +++ b/debian/changelog @@ -6,7 +6,12 @@ clock-setup (0.111) UNRELEASED; urgency=low [ Joey Hess ] * Set UTC or LOCAL in /etc/adjtime for systemd. Closes: #660093 - -- Samuel Thibault sthiba...@debian.org Sun, 12 Feb 2012 23:05:52 +0100 + [ Roger Leigh ] + * Migrate UTC setting from /etc/default/rcS; revert use of +/etc/default/hwclock, which is not used for holding the UTC +setting. + + -- Roger Leigh rle...@debian.org Mon, 21 May 2012 20:03:36 +0100 clock-setup (0.110) unstable; urgency=low diff --git a/finish-install.d/10clock-setup b/finish-install.d/10clock-setup index 4e52af5..42c9a08 100755 --- a/finish-install.d/10clock-setup +++ b/finish-install.d/10clock-setup @@ -92,11 +92,7 @@ if ! db_go; then fi # Update target system configuration for utc/localtime selection -if [ -f /target/etc/default/hwclock ]; then - utcfile=/target/etc/default/hwclock -else - utcfile=/target/etc/default/rcS -fi +utcfile=/target/etc/default/rcS db_get clock-setup/utc if [ $RET = true ]; then -- 1.7.10 signature.asc Description: Digital signature
Bug#672160: Directory /boot/console-setup
On Thu, May 10, 2012 at 07:43:46PM +0300, Anton Zinoviev wrote: [Please preserve the CC to 672...@bugs.debian.org because I am not subscribed to debian-devel.] First the problem in few words. The package console-setup needs an access to a directory similar to /var very early during the boot process - when /var is not yet mounted. Currently it creates files in the directory /etc/console-setup. We created /run for exactly this purpose. Create /run/console-setup and put what you need inside there. You'll need to follow the advice in http://wiki.debian.org/ReleaseGoals/RunDirectory . You basically just need to have a Depends on initscripts (= 2.88dsf-13.3) and you're good to go. Don't store megabytes of data in here though, since it's stored in virtual memory on most systems. Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120510174518.gk23...@codelibre.net
Bug#660093: clock-setup: Please support /etc/adjtime in addition to /etc/default
Package: clock-setup Version: 0.110 Severity: normal Tags: patch Hi, This is similar to the patch for hwclock support last week, but solves a different problem, namely supporting systemd in d-i, and (potentially) allowing migration of the UTC setting in /etc/default into the native configuration file for this option. Many thanks, Roger -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (550, 'unstable'), (500, 'testing'), (400, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash From 8ca1790120e851c34e5dffa7adb20322ef6c970a Mon Sep 17 00:00:00 2001 From: Roger Leigh rle...@debian.org Date: Thu, 16 Feb 2012 10:41:03 + Subject: [PATCH] 10clock-setup: Support /etc/adjtime Set UTC or LOCAL in /etc/adjtime in addition to UTC= in /etc/default. This is because /etc/adjtime is the configuration file for hwclock, and the systemd init daemon uses the configuration file directly, thus this change makes it possible for d-i to support installations which use systemd in place of sysvinit. This change does not affect sysvinit users, because /etc/adjtime is updated when hwclock is run. --- finish-install.d/10clock-setup |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/finish-install.d/10clock-setup b/finish-install.d/10clock-setup index 4bde2c4..4e52af5 100755 --- a/finish-install.d/10clock-setup +++ b/finish-install.d/10clock-setup @@ -101,9 +101,15 @@ fi db_get clock-setup/utc if [ $RET = true ]; then sed -i -e 's:^UTC=no:UTC=yes:' -e 's:^UTC=no:UTC=yes:' $utcfile + if [ -e /target/etc/adjtime ]; then + sed -i -e 's:^LOCAL$:UTC:' /target/etc/adjtime + fi OPT=--utc else sed -i -e 's:^UTC=yes:UTC=no:' -e 's:^UTC=yes:UTC=no:' $utcfile + if [ -e /target/etc/adjtime ]; then + sed -i -e 's:^UTC$:LOCAL:' /target/etc/adjtime + fi OPT=--localtime fi -- 1.7.9
Bug#659611: clock-setup: Please support /etc/default/hwclock
Package: clock-setup Version: 0.109 Severity: important Tags: patch Hi, In order to resolve bugs including #659451 and permit /etc/default/rcS to become a regular conffile, I'd like to move the UTC variable from /etc/default/rcS to /etc/default/hwclock. This would require clock-setup to be patched before this can be fixed in initscripts, to avoid breakage. A patch is attached which makes clock-setup use /etc/default/hwclock, but fall back to /etc/default/rcS for backward compatibility if not present. I'd appreciate it if you would consider applying it. Regards, Roger -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (550, 'unstable'), (500, 'testing'), (400, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash From a3878e9c14e4283a43afd34cefbf88e8fa36fa2f Mon Sep 17 00:00:00 2001 From: Roger Leigh rle...@debian.org Date: Sun, 12 Feb 2012 14:41:59 + Subject: [PATCH] 10clock-setup: Support /etc/default/hwclock /etc/default/hwclock supersedes /etc/default/rcS as the location for the UTC configuration option. Use /etc/default/hwclock, but fall back to /etc/default/rcS if it is not present, for backward compatibility. --- finish-install.d/10clock-setup | 10 +++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/finish-install.d/10clock-setup b/finish-install.d/10clock-setup index f825bb8..c80f1dd 100755 --- a/finish-install.d/10clock-setup +++ b/finish-install.d/10clock-setup @@ -92,14 +92,18 @@ if ! db_go; then fi # Update target system configuration for utc/localtime selection -rcsfile=/target/etc/default/rcS +if [ -f /target/etc/default/hwclock ]; then + utcfile=/target/etc/default/hwclock +else + utcfile=/target/etc/default/rcS +fi db_get clock-setup/utc if [ $RET = true ]; then - sed -i -e 's:^UTC=no:UTC=yes:' -e 's:^UTC=no:UTC=yes:' $rcsfile + sed -i -e 's:^UTC=no:UTC=yes:' -e 's:^UTC=no:UTC=yes:' $utcfile OPT=--utc else - sed -i -e 's:^UTC=yes:UTC=no:' -e 's:^UTC=yes:UTC=no:' $rcsfile + sed -i -e 's:^UTC=yes:UTC=no:' -e 's:^UTC=yes:UTC=no:' $utcfile OPT=--localtime fi -- 1.7.9
Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
On Fri, Dec 16, 2011 at 07:34:16AM +0100, Christian PERRIER wrote: (reducing CC as I guess that most are subscribed to -devel) Quoting Russ Allbery (r...@debian.org): I don't think these things are alike. Separating /var and /tmp from the rest of the file systems is done because those partitions contain varying amounts of data and often fill if something goes wrong, but can fill without impacting the rest of the system and allowing easy recovery if they're not on the same partition as everything else. Separating /var continues to be good and recommended practice if you're running anything that's likely to produce a lot of output, IMO. (/tmp should probalby just be tmpfs, but that's another discussion.) I'm inclined to follow this advice and would indeed propose that the atomic partman-auto recipe is kept, however without a separate /usr partition (discussions on -devel and the current practice convinced me that a separate /usr is seomthing that probably belongs to the former century..:-) So, would it be OK for participants in this discussion is we, in the installer, just drop separate /usr but keep the atomic recipe (which is not the default choice, by the way)? Dropping /usr is a good idea, I think, and continuing to keep /var separate would also be sensible. Regarding /tmp, we're now defaulting to a tmpfs for new installs, so I'm not certain if having a separate /tmp by default is a good idea or not. I would certainly like for /tmp in particular (and tmpfses in general) to become configurable through the partitioner, which would then also check that sufficient swap is also allocated at the same time. Once we have /etc/fstab.d fully supported by mount (with the next util-linux release, probably in early January), I will be looking at making all the initscripts mountpoints currently hardcoded in the init scripts like mountkernfs etc. into conffiles in fstab.d. It would then be possible for the installer to edit these files quite simply to change the defaults, perhaps using the partitioner as a frontend. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- 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/20111216103012.gm17...@codelibre.net
Re: Switching /etc/mtab to symlink to /proc/mounts
On Sat, Jul 09, 2011 at 11:26:58AM +0100, Roger Leigh wrote: On Sat, May 14, 2011 at 02:02:01PM -0400, Joey Hess wrote: Roger Leigh wrote: /etc/mtab - symlink to /proc/self/mounts (494001) debootstrap (but seems ok; only removes file not symlink) busybox Not configured to use or write /etc/mtab AFAICT (CONFIG_FEATURE_MTAB_SUPPORT is not set) lilo-installer aboot-installer debian-installer-utils grub-installer arcboot-installer palo-installer elilo-installer Any of these could break even with the symlink if, for example, /target/proc is not mounted when they try to use /target/etc/mtab. Several I've looked at (lilo-installer and grub-installer) try to overwrite /etc/mtab. I've had a look at all of these, and they all contain logic to check for a symlink, and abort if one is present. Some would try to read the symlink, so it looks like the main cause of breakage would be (as you said avoid) if /target/proc is not mounted. Surely /target/proc can be mounted prior to any of the above being run? I'm not too familiar with the installer, but I thought this was already the case? As far as I can tell, we now only have two blockers preventing switching /etc/mtab to symlink to /proc/mounts: #620818 cifs-utils #622693 libpam-mount preventing us fixing #494001. Are there any other known issues which would prevent us from making the switch? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: /run in *unstable*: migration of /lib/init/rw, /dev/.*
On Sat, May 14, 2011 at 02:02:01PM -0400, Joey Hess wrote: Roger Leigh wrote: /etc/mtab - symlink to /proc/self/mounts (494001) debootstrap (but seems ok; only removes file not symlink) busybox Not configured to use or write /etc/mtab AFAICT (CONFIG_FEATURE_MTAB_SUPPORT is not set) lilo-installer aboot-installer debian-installer-utils grub-installer arcboot-installer palo-installer elilo-installer Any of these could break even with the symlink if, for example, /target/proc is not mounted when they try to use /target/etc/mtab. Several I've looked at (lilo-installer and grub-installer) try to overwrite /etc/mtab. I've had a look at all of these, and they all contain logic to check for a symlink, and abort if one is present. Some would try to read the symlink, so it looks like the main cause of breakage would be (as you said avoid) if /target/proc is not mounted. Surely /target/proc can be mounted prior to any of the above being run? I'm not too familiar with the installer, but I thought this was already the case? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Bug#633299: debian-installer: Feature request: please support tmpfs filesystems in partitioner
Package: debian-installer Version: 20110106+squeeze3 Severity: normal Hi, This was briefly discussed on #debian-boot. I'm writing this report to record that. The recent changes to support /run in wheezy/unstable have added the following mounts: tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=10%,mode=755 0 0 tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5m 0 0 tmpfs /run/shm tmpfs rw,nosuid,nodev,relatime,size=20% 0 0 tmpfs /tmp tmpfs rw,nosuid,nodev,relatime,size=20% 0 0 Like the UTC=yes parameter the installer sets in /etc/default/rcS to configure the hardware clock, these filesystems may be enabled or disabled by setting RAMLOCK=yes RAMSHM=yes RAMTMP=yes in /etc/default/rcS. Currently, the initscripts defaults these all to yes. However, it may make sense for the installer to give the user the option of disabling them. /run is always mounted (not configurable). Additionally, the mount options and size of the tmpfs may be configured by adding an entry to /etc/fstab, such as shown above. If not present, defaults from /lib/init/tmpfs.sh will be used instead (the fstab settings supersede the defaults). I was thinking of how this could be cleanly added into the installer, and the best idea I've come up with so far is to add it directly into the partitioner, so you don't need to provide any special support for the feature (such as asking additional questions). If support for the tmpfs filesystem was added (similar to how LVM and RAID are supported), one could add a tmpfs mount to the filesystem list, which would then permit configuration of its size, mount options etc. using the existing interface. It could default to having entries for /run, /run/lock, /run/shm and /tmp, and this would permit the user to modify them or delete them entirely. If deleted, you could then set RAMxxx=no in /etc/default/tmpfs. And if the options differ from the default, you can then write an fstab entry for the mount. The interface would also permit the addition of new tmpfs mounts as well. It would also be possible to only expose this in expert mode, if desirable, so that normal installs wouldn't have increased complexity, and the package defaults would simply be used instead. We made the options in /etc/default/rcS and /etc/fstab configurable in this way so that it fitted in with how the installer was already configuring things, but equally this was already how the package was set up (RAMLOCK was repurposed from /var/lock to /run/lock, and fstab was already used to store options; RAMSHM and RAMTMP are simply extending the existing conventions in use). Regards, Roger -- 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/20110709111018.20468.21255.report...@ravenclaw.codelibre.net
Bug#633049: debootstrap: /run transition: Please switch use of /lib/init/rw to /run
On Thu, Jul 07, 2011 at 09:48:20PM -0400, Joey Hess wrote: Roger Leigh wrote: Your package is currently using /lib/init/rw/ which is now deprecated and pending removal. Please update your package to use /run/ with a versioned dependency on initscripts, as detailed below. debootstrap's entire use of /lib/init/rw is to umount it if the directory exists. AFAICS the only impact could be a warning message if the directory is not found or mounted. I don't know if /run would get mounted during a debootstapping and also need to be unmounted. We do take care to only mount /run at boot time, so it should never be mounted in a chroot. When migrating from /var/run in a chroot, we also take care to not do any bind mounting. In consequence, it should never be mounted during a debootstrap, but it certainly wouldn't hurt for debootstrap to attempt to umount it just in case something else does mount it. And, debootstrap needs to keep umounting the directory if it exists, since it supports debootstapping old versions of debian. ACK. I already discussed this, and other stuff in d-i that will probably actually be broken by /run in 20110514180201.ga28...@gnu.kitenet.net. Has anything been done about that stuff? Not that I can see from what's in git for eg, grub-installer. This is regarding making /etc/mtab a symlink? This is still a work in progress; I haven't yet got around to looking at what needs fixing. It's also blocked on libmount support being added to nfs-utils. Thanks for the list of packages though--I'll look at them in more detail and file bugs when I have time. Sorry about the sendsigs bit, that was not relevant for debootstrap. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Bug#633049: debootstrap: /run transition: Please switch use of /lib/init/rw to /run
Source: debootstrap Version: 1.0.32 Severity: important User: rle...@debian.org Usertags: run-transition Your package is currently using /lib/init/rw/ which is now deprecated and pending removal. Please update your package to use /run/ with a versioned dependency on initscripts, as detailed below. An overview of the /run transition and its current progress is available at http://wiki.debian.org/ReleaseGoals/RunDirectory Basically, it's now in both testing and unstable, and the next phase of the transition is to migrate all users of /lib/init/rw over to /run and then remove /lib/init/rw entirely for wheezy (as soon as this transition is complete). Your package is one of the users of sendsigs.omit.d listed here: http://wiki.debian.org/ReleaseGoals/RunDirectory#Packages_using_.2BAC8-lib.2BAC8-init.2BAC8-rw Recommendations for how to do the transition may be found here: http://wiki.debian.org/ReleaseGoals/RunDirectory#How_to_transition_from_.2BAC8-lib.2BAC8-init.2BAC8-rw_to_.2BAC8-run.3F For transitioning from /lib/init/rw to /run, we would recommend that you: * Depend on initscripts (= 2.88dsf-13.3) * Replace all usage of /lib/init/rw with /run * Move all files in /lib/init/rw to /run in the package postinst Regards, Roger -- 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/20110707230843.15006.20151.report...@ravenclaw.codelibre.net
Bug#578927: debian-installer: No kernel driver for powerpc mac mini ethernet (Sun GEM)
Package: debian-installer Version: daily-image powerpc netinst ISO 2010-0419 Severity: normal During the installer check for an ethernet interface prior to bringing up the network, it fails to find an ethernet interface. lspci -v reports: 0002:20:0f.0 Ethernet controller: Apple Computer Inc. UniNorth 2 GMAC (Sun GEM) (rev ff) (prog-if ff) !!! Unknown header type 7f This worked just fine for earlier Debian releases; maybe it's just missing the appropriate kernel module? Regards, Roger -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.31.3-bytemark-kvm-2009-10-19 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- 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/20100423163344.25652.72926.report...@nagini.codelibre.net
Bug#494001: debian-installer: /etc/mtab must be a symlink to /proc/mounts with linux = 2.6.26
On Thu, Aug 07, 2008 at 02:19:33PM +0200, Radim X. wrote: [please CC the submitter as well as the bug number, or else they don't get a reply!] Are you sure that this won't break things elsewhere? Yes; the whole point of this change is to stop breaking things that are currently broken, including a whole plethora of bugs in mount(1). Other packages might use /etc/mtab with inotify to watch mount events (especially for removable media). They would have to switch to a different method, since /proc does not support inotify and udev doesn't help either. Do you have any examples of packages which use /etc/mtab in this way? I checked KDE 3.5.5 and it seems to be working fine. Note that inotify is very new, is Linux-specific, and all of the common desktop environments are portable to many different platforms and hence will detect changes using mechanisms other than inotify. IMO this is not a stopper for moving to a symlink. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Bug#494001: debian-installer: /etc/mtab must be a symlink to /proc/mounts with linux = 2.6.26
Package: debian-installer Severity: important /etc/mtab can be either a regular file updated by mount/umount, or a symlink to /proc/mounts. Currently, it is a regular file, though the user can change this by hand. With linux 2.6.26, /proc/mounts lacks information present in /etc/mtab such as additional mount options. Thus a symlink breaks things like discquotas which rely on parsing the additional mount options. As a result, we are mostly all still using it as a plain file. With linux = 2.6.26, /proc/mounts contains all of the information in /etc/mtab, plus more. The mount system call can now pass all of the mount options to the kernel, so no information is missing in /proc/mounts. This has obviously useful benefits such as read-only root, and the state in /etc/mtab never gets out of sync with reality (there are a number of open bugs against mount where this occurs). Additionally, with the addition of per-process namespaces with CLONE_NEWNS to clone(2), each process has its own set of mounts, and as such a system-wide /etc/mtab is useless: it's only valid in one of the potentially many namespaces and can quickly get into a horrible mess. At this point, /etc/mtab *must* be a symlink to avoid breakage. Note that /proc/mounts is now a symlink to /proc/self/mounts for this reason: each process has potentially different mounts. After discussion on #debian-devel, we came up with these points: - we could detect the kernel version on boot, and set up a file or a symlink as needed. However, this breaks read-only root. - we could change on upgrades rather than boot, but because it's dependent upon the kernel version, breakage could result if an older kernel is booted. - doing it at install time if a kernel = 2.6.26 is installed is the most robust solution. I had a look at a number of sources (debootstrap, base-files, debian-installer), but I have yet to find the code that initially creates /etc/mtab (if any). Some of the init scripts will re-create it if not present (and these could do with updating too for Lenny+1), but ideally if d-i installs a kernel = 2.6.26, it should just ensure that /etc/mtab is a symlink during the install. If we could get this change made for Lenny, that would be great. Thanks for your time, Roger -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.20.3-bytemark-uml-2 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: grub2 on powerpc
Robert Millan [EMAIL PROTECTED] writes: As you might know, experimental grub2 support has been added to d-i when using the expert mode, but it is only yet available on i386/amd64. I think powerpc support might be a bit premature. The powerpc code upstream is a bit lagging compared with i386/amd64, and depends on tools not in Debian. For example, changed to the i386 shell scripts have not been made to the corresponding powerpc scripts; this really needs to be made into common code, to avoid this needless effort. The same also applies to some of the C source. It's not a great deal of work to fix these issues, but I am currently lacking sufficient time to do it myself. This may be outdated though--I haven't checked out grub2 for a couple of months, so it may have already been rectified. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpJTz6CpulaA.pgp Description: PGP signature
Re: grub2 on powerpc
Robert Millan [EMAIL PROTECTED] writes: This is strange. I know one of the core grub2 maintainers is using powerpc regularly (with code from CVS). It certainly works--I've used it myself. But there is so much duplicated, common, code between the ports, it really is asking for splitting into separate arch-specific and generic parts, rather than duplicating the entirety for each port. As for tools not in Debian, you mean ofpathname? Yes. Is the grub2 debian package usable at all without ofpathname? (I understand that at least grub-install won't work, making d-i support impossible). It's just grub-install that breaks. Installing by hand works. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgplQZqfgZibR.pgp Description: PGP signature
Re: grub2 on powerpc
Sven Luther [EMAIL PROTECTED] writes: As for tools not in Debian, you mean ofpathname? Is the grub2 debian package usable at all without ofpathname? (I understand that at least grub-install won't work, making d-i support impossible). ofpathname is part of the ibm-powerpc-utils package (not the same as the package currently in debian), and Aurelien Gerome is packaging it, since yaboot also needs it over the kind-of-broken ofpath found in the yaboot code, so this should be less an issue than you think. While ofpathname uses sysfs, and supports a wider range of devices, it doesn't support partitions on devices (needed by yaboot), and also has a different output format than yaboot. yaboot would need updating to support it. IMO ofpathname really does need fixing to support partitions of devices. $ /usr/sbin/ofpath /dev/hda /[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]: $ /home/rleigh/powerpc-utils-1.0.2/scripts/ofpathname /dev/hda /[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED] $ /usr/sbin/ofpath /dev/hda4 /[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]:4 $ /home/rleigh/powerpc-utils-1.0.2/scripts/ofpathname /dev/hda4 /home/rleigh/powerpc-utils-1.0.2/scripts/ofpathname: line 237: cd: /sys/block/hda4: No such file or directory ofpathname: Could not find sysfs information for logical device /dev/hda4. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpByp7oLcAMN.pgp Description: PGP signature
