Bug#944102: create sources.list with signed-by
Hi, I think this proposal to use "signed-by" is a good idea. But if you ever make such support, please consider to use deb822 style file instead of one-line old style. This way, we can avoid creating a source list configuration file with insanely long line can be avoided. (I don't know which key is the best choice though.) My local /etc/apt/sources.list.d/debian.sources types: deb deb-src uris: http://deb.debian.org/debian/ suites: bookworm components: main non-free-firmware contrib non-free signed-by: /usr/share/keyrings/debian-archive-bookworm-automatic.gpg #Signed-By: /usr/share/keyrings/debian-archive-bookworm-stable.gpg #Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg types: deb deb-src uris: http://security.debian.org/debian-security/ suites: bookworm-security components: main non-free-firmware contrib non-free signed-by: /usr/share/keyrings/debian-archive-bookworm-security-automatic.gpg #Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg Osamu
Bug#1017762: incompatible after "btrfs subvolume set-default ..."
Source: partman-btrfs Version: 55 Severity: normal It is great to have btrfs support with @rootfs. Thanks. I wish if it is a bit more verbose on what it does in installer dialogue. This is more important if we want to use existing btrfs with something like @home-uid1000 in it ;-) Anyway, I experienced an unsuccessful install to the existing btrfs partition. I had @rootfs-broken-backup in it and I set "btrfs subvolume set-default ..." to it. Don't ask me why I did. But this caused d-i to stop installation without much error report. EXPECTED BEHAVIOR: 1. Clearly mention the use of subvolume @rootfs in d-i dialogue. (This is for both fsck or fsck-less install cases.) 2. Check "btrfs subvolume get-default " to be "ID 5 (FS_TREE)". If not, * stop installation with clear message or (reasonable?) * set-default to fix this. (better?) (This is for fsck-less install) 3. Check existance of @rootfs. If exists, * stop installation with clear message or (simple) * make a backup snapshot of @rootfs to some other name and remove @rootfs to have clean start. (better) (This is for fsck-less install) -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-4-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1012041: Patch: debian/control
Hi > And the patch needs to be actually tested. Very true. Excuse me. I think what you suggests is the way to go. Thanks Osamu
Bug#1012041: Patch: debian/control
Control: tags + patch -1
thanks
From 980e431896d4442142bf480b14abd0049208861f Mon Sep 17 00:00:00 2001
From: Osamu Aoki
Date: Tue, 31 May 2022 14:28:00 +0900
Subject: [PATCH] Ensure update upon xkb-data update
Signed-off-by: Osamu Aoki
---
debian/control | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/control b/debian/control
index 1bd81cc..1af1fc6 100644
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,7 @@ Vcs-Git: https://salsa.debian.org/installer-team/console-setup.git
Package: keyboard-configuration
Architecture: all
Multi-Arch: foreign
-Depends: ${misc:Depends}, liblocale-gettext-perl
+Depends: ${misc:Depends}, liblocale-gettext-perl, xkb-data (= ${source:Version})
Pre-Depends: debconf (>= 1.5.34)
Breaks: console-setup (<< 1.71), console-setup-mini (<< 1.47)
Replaces: console-setup (<< 1.47), console-setup-mini (<< 1.47)
--
2.35.1
Bug#1012041: KeyboardNames.pl is out-of-sync with xkeyboard-config
Source: console-setup Version: 1.205 Severity: normal Problem symptom: I was looking at "dpkg-reconfigure keyboard-configuration" under Japanese locale and testing. Although Generic 101 and 104 keyboards are translated properly, Generic 102 and 105 keyboards were not translated properly. Resolution proposal: Please place some kind of version skew avoidance measure by specifying xkb-data as binary dependence with exact version value for keyboard-configuration. This dependency is because of gettext/po data used. Technical analysis: As I looked into problem, kbdnames-maker + KeyboardNames.pl was using po from xkeyboard-config: my $mo () As I checked xkeyboard-config.po, its string obtained for msgid for 102 and 105 keyboards has been changed. If we want to fix this issue, KeyboardNames.pl needs to be updated at least: ``` $ diff -u KeyboardNames.pl.orig KeyboardNames.pl --- KeyboardNames.pl.orig 2022-05-29 14:36:14.940304836 +0900 +++ KeyboardNames.pl2022-05-29 15:02:29.524014093 +0900 @@ -71,10 +71,10 @@ 'FL90' => 'compalfl90', 'Fujitsu-Siemens Amilo laptop' => 'fscaa1667g', 'Generic 101-key PC' => 'pc101', -'Generic 102-key PC' => 'pc102', +'Generic 102-key (Intl) PC' => 'pc102', 'Generic 104-key PC' => 'pc104', 'Generic 104-key PC with L-shaped Enter key' => 'pc104alt', -'Generic 105-key PC' => 'pc105', +'Generic 105-key (Intl) PC' => 'pc105', 'Generic 86-key PC' => 'pc86', 'Genius Comfy KB-12e' => 'geniuscomfy', 'Genius Comfy KB-16M/Multimedia KWD-910' => 'genius', ``` But this KeyboardNames.pl is a generated file so simple patch is not the answer. This file is generated by console-setup/Keyboard/Makefile . Testing had old console-setup from Nov./2021 while xkb-data was updated in April (testing migration on 2022-04-10) Of course, console-setup 1.208 (uploaded to unstable on 2022-05-26) solve the issue when it reaches testing in a few days this time. (But this was broken for about a month unnoticed.) It would be nice if we can avoid this version skew to happen in testing by adding binary package dependency for PO file. Regards, Osamu -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-1-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages keyboard-configuration depends on: ii debconf 1.5.79 ii liblocale-gettext-perl 1.07-4+b2 Versions of packages console-setup-linux depends on: ii init-system-helpers 1.63 ii kbd 2.3.0-3 ii keyboard-configuration 1.207 console-setup-linux suggests no packages. Versions of packages console-setup is related to: pn console-common pn console-data pn console-tools ii gnome-control-center 1:42.1-2 ii kbd 2.3.0-3 ii systemd 250.4-1
Bug#983107: os-prober: generic subvolume support for btrfs
Hi,
Speaking of btrfs integration to grub, I noticed some strange cruft
code in /etc/grub.d/30_os-prober. (grub-common package) Maybe this is
some backward compatibility feature code to address older os-prober.
We may need to be careful around here or this may be an non-issue.
In /etc/grub.d/30_os-prober
---
BTRFS="`echo ${OS} | cut -d ':' -f 5`"
if [ "x$BTRFS" = "xbtrfs" ]; then
BTRFSuuid="`echo ${OS} | cut -d ':' -f 6`"
BTRFSsubvol="`echo ${OS} | cut -d ':' -f 7`"
fi
---
${OS} is basically 's/\s/^/g' on os-prober output. But there should be
only 4 fields. So this yield BTRFS="" etc.
So the following code
---
linux)
if [ "x$BTRFS" = "xbtrfs" ]; then
LINUXPROBED="`linux-boot-prober btrfs ${BTRFSuuid}
${BTRFSsubvol} 2> /dev/null | tr ' ' '^' | paste -s -d ' '`"
else
LINUXPROBED="`linux-boot-prober ${DEVICE} 2> /dev/null | tr '
' '^' | paste -s -d ' '`"
fi
---
So always *else* side is executed with the current os-prober.
Current linux-boot-prober in os-prober has its internal FS detection
for btrfs where Ubuntu's patch (and my improvement suggestion patch)
uses and make bind mount subvolume.
On Sat, 2021-02-20 at 07:19 +0100, Cyril Brulebois wrote:
> loop += Nicholas, who has been working on btrfs integration.
>
> Cheers,
Bug#983107: os-prober: generic subvolume support for btrfs
Hi, Knowing bulleseye 11 release is near and this issue may stay, people may need to work around this issue of btrfs subvolume as root partition. Here is my WORKAROUND suggestion. (Please note that my patch proposal in my original bug report is not- yet tested well.) The current Debian Grub2 code at /etc/grub.d/30_os-prober requires to access some root partion contents from the btrfs ID 5 (FS_TREE) to function well. (subvol=/) If you want to use timeshift (Ubuntu origin?) or snapper (Suse origin ?), they seem to use non-ID-5 subvol for the system install, i.e., root-FS. People use these tools on Debian too. https://qa.debian.org/popcon-graph.php?packages=timeshift+snapper+snapper-gui+btrbk+btrfsmaintenance+duperemove&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 === WORKAROUND === Let's suppose your another linux installation on another formatted in btrfs at partion "/dev/nvme1n1p1" has its root-FS content in "subvol=@", please perform followings: - $ sudo mount -t btrfs -o subvol=/,defaults /dev/nvme1n1p1 /mnt $ cd /mnt $ sudo ln -sf @/boot boot $ sudo ln -sf @/etc etc $ sudo ln -sf @/usr usr $ sudo ln -sf @/lib lib $ sudo ln -sf @/initrd.img initrd.img $ sudo ln -sf @/vmlinuzvmlinuz $ sudo ln -sf @/initrd.img.old initrd.img.old $ sudo ln -sf @/vmlinuz.oldvmlinuz.old $ sudo btrfs subvol set-default /mnt/@ $ cd / $ sudo umount /mnt - This assumes you do not have conflicting contents in subvol=/. If you happen to use other subvol for the root-FS content, replace its subvol name in place of "@". === Additional Tips === You can convert a system from EXT2/3/4 to btrfs as follows by booting system from another system on the multiboot set-up. File system conversion is trivial as described in https://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3 - $ sudo fsck.ext3 -f /dev/xxx $ sudo btrfs-convert /dev/xxx $ sudo mount -t btrfs /dev/xxx /mnt - You need to make some adjustment to cope with new filesystem ant its new blkid by adjustng at least /etc/fstab and /boot/grub/grub.cfg . Please note UUID of partition changes after btrfs-convert. Please check - --- fstab.orig 2021-02-19 14:49:32.768895933 +0900 +++ fstab 2021-02-19 14:49:19.860921576 +0900 @@ -6,6 +6,6 @@ # # # / was on /dev/nvme1n1p1 during installation -UUID=491a357c-822f-4f38-b56e-b998baea81a5 / ext4 errors=remount-ro 0 1 +UUID=9be0d928-5892-4cdd-a647-1e8cce937b2e / btrfs defaults 0 1 # /boot/efi was on /dev/nvme0n1p1 during installation - Also, you need to update many relevant parts of grub.cfg, too. Roughly as ... - --- grub.cfg-orig 2021-02-17 09:32:35.855910912 +0900 +++ grub.cfg2021-02-19 14:26:12.728005239 +0900 ... -insmod ext2 +insmod btrfs ... - search --no-floppy --fs-uuid --set=root 491a357c-822f-4f38-b56e- b998baea81a5 + search --no-floppy --fs-uuid --set=root 9be0d928-5892-4cdd-a647- 1e8cce937b2e ... - linux /boot/vmlinuz-5.10.0-3-amd64 root=UUID=491a357c-822f- 4f38-b56e-b998baea81a5 ro quiet + linux /boot/vmlinuz-5.10.0-3-amd64 root=UUID=9be0d928-5892- 4cdd-a647-1e8cce937b2e ro quiet ... - The UUID change to the "linux ..." line is important since it will affect how this alternative partion update is grub configuration. If you wish to move all this nely migrated system to a subvolume, just snapshot it to "@" or anything you like using "btrfs subvolume snapshot /mnt /@" command. Of course, if your new system is at subvol=@, you need to adjust /etc/fstab as; - --- fstab.orig 2021-02-19 14:49:32.768895933 +0900 +++ fstab 2021-02-19 14:49:19.860921576 +0900 @@ -6,6 +6,6 @@ # # # / was on /dev/nvme1n1p1 during installation -UUID=491a357c-822f-4f38-b56e-b998baea81a5 / ext4 errors=remount-ro 0 1 +UUID=9be0d928-5892-4cdd-a647-1e8cce937b2e / btrfs subvol=@,defaults 0 1 # /boot/efi was on /dev/nvme0n1p1 during installation - And then move on to use WORKAROUND as described in the above. On Fri, 2021-02-19 at 14:12 +, Debian Bug Tracking System wrote: > ... > You can follow progress on this Bug here: 983107: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983107.
Bug#983107: os-prober: generic subvolume support for btrfs
Package: os-prober Version: 1.78 Severity: normal Issue: Currently Debian os-prober support only btrfs root-filesystem on the root of the btrfs, i.e., ID 5 (FS_TREE). This makes auto generated grub.cfg to miss Linux install to btrfs for some Ubuntu and Suse since they put root-system under @ subvolume. Existing patch in other distro: Ubuntu ships patched os-prober 1.77 to address its subvolume use (@ as root- filesystem) with hardcoded path and very rudamental check for /lib directory. diff -pruN 1.77/linux-boot-probes/common/50mounted-tests 1.77ubuntu1/linux- boot-probes/common/50mounted-tests --- 1.77/linux-boot-probes/common/50mounted-tests 2018-08-10 19:23:18.0 + +++ 1.77ubuntu1/linux-boot-probes/common/50mounted-tests2020-11-02 11:12:51.0 + @@ -54,6 +54,19 @@ if type grub-mount >/dev/null 2>&1 && \ mounted=1 type="$(grub-probe -d "$partition" -t fs)" [ "$type" ] || type=fuseblk + + case "$type" in + btrfs) + if [ -x "$tmpmnt/@/lib" ] && \ + ! mount --bind "$tmpmnt/@" "$tmpmnt"; then + warn "failed to mount btrfs subvolume @ on $partition" + if ! umount $tmpmnt; then + warn "failed to umount $tmpmnt" + fi + mounted= + fi + ;; + esac fi if [ "$mounted" ]; then -- Discussion: Since we should offer the choice for the subbvolume name, this hardcoding "@" here is not elegant. We should get it as: - RSUBVOL=$(btrfs subvolume get-default $tmpmnt |cut -d' ' -f 9) - Proposed fix: So updated patch should be more like --- + case "$type" in + btrfs) + RSUBVOL=$(btrfs subvolume get-default $tmpmnt |cut -d' ' -f 9) + if [ -n "$RSUBVOL" ] && [ -x "$tmpmnt/$RSUBVOL/lib" ] && \ + ! mount --bind "$tmpmnt/$RSUBVOL" "$tmpmnt"; then + warn "failed to mount btrfs subvolume $RSUBVOL on $partition" + if ! umount $tmpmnt; then + warn "failed to umount $tmpmnt" + fi + mounted= + fi + ;; + esac --- This is much simpler patch than ones discussed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688336 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699189 Since we expect any sane person set-default to the root-filesystem. You could add fall-back with "elif" to use Ubuntu specific hardcoded subvolume name. This should make Debian friendly to older Ubuntu with btrfs. What do you think? Osamu -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-3-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages os-prober depends on: ii grub-common 2.04-15 ii libc62.31-9 os-prober recommends no packages. os-prober suggests no packages. -- no debconf information
Bug#925391: task-japanese-desktop and others: Gnome-wayland compatible input method
Package: tasksel Version: 3.51 Severity: normal We will ship wayland enabled Gnome as the default for Buster! So we need to adjust to this environment. Trying to enable current default input method for Japanese under wayland caused big side effect. So the feature to enable uim requires user to manually enable this work around intentionally (this still needs to be unblocked) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925160 So for default install, it is essential to use ibus family which is upstream supported. im-config doesn't need to do anything. gnome takes catrare by gnome-session in main.c which hard codes ibus there. (I know, japanese liek uim, Chinese like fcitx) Proposed task data == In light of this, I propose to change task-japanese-desktop to the following: task-japanese-desktop (kmuto) --\ Depends (1) --- tasksel (= 3.50) --\ Recommends (11) --- ibus-mozc | ibus-anthy | ibus-skk | ibus-kkc --- firefox-esr-l10n-ja | firefox-l10n-ja --- fonts-ipafont --- fonts-vlgothic --- libreoffice-help-ja --- libreoffice-l10n-ja --- poppler-data Here, simply picking one of the ibus-* pulls in all you need via recommends. Configuration utility is gnome-shell script provided by Gnome. gnome-shell already requires gir1.2-ibus-1.0 thus installs libibus-1.0-5. So going with ibus is upstream choice. FYI: OLD SETTINGS are the following task-japanese-desktop --\ Depends (1) --- tasksel (= 3.50) --\ Recommends (11) --- anthy --- firefox-esr-l10n-ja | firefox-l10n-ja --- fonts-ipafont --- fonts-vlgothic --- libreoffice-help-ja --- libreoffice-l10n-ja --- mozc-utils-gui --- poppler-data --- uim --- uim-anthy --- uim-mozc Other consideration: Traditional DMs on X: = im-config pulled in by the dependency will automatically set up system including configuration dialog. So this change has minimal impact. Why ibus-mozc as the first choice? == I know anthy currently suffers conversion errors. I suspect inconsistent encoding of its dictionary data is the root cause. It looks like the conversion to UTF-8 had errors. (This is not ibus problem. It is same under uim or fcitx. KDE seems to chose SCIM? Should we care? = plasma-desktop depends on libscim8v5 from SCIM family. Should we care like what we do for Gnome? I have no answer. All I know is KDE doesn't play nice with ibus. You can kill ibus icon program with mouse click. No easy way to get back. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922334 I wonder these input methods may better move to task such as task-japanese-gnome-desktop task-japanese-kde-desktop Then they can have their own way. (Of course, we may leave out other DM people.) What is going to happen on Chinese tasks They love fcitx. Does anyone know what they do. we may have answer there too. Long term: == If we can use trigger to update choice of configuration im-config calcurate when user process starts in advance, then enabling im-config even for wayland may be an option. But it's too late for buster. Also, I think if someone knows better than me and have time, make current ibus related code in gnome-session/gnome-shell to be patched/extended to allow other input methods to be used. We need volunteer for it. (Including option to replace im-config input method configuration system to Ubuntu equivalent, if that solves.) -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (10, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tasksel depends on: ii apt 1.8.0 ii debconf [debconf-2.0] 1.5.71 ii liblocale-gettext-perl 1.07-3+b4 ii perl-base 5.28.1-4 ii tasksel-data3.51 tasksel recommends no packages. tasksel suggests no packages. -- debconf information: tasksel/tasks: tasksel/desktop: tasksel/title: tasksel/first: standard
Bug#907970: Please stop using debiandoc-sgml (deprecated)
Hi, On Tue, Sep 04, 2018 at 04:33:54PM +0100, Ben Hutchings wrote: ... > > --- a/doc/devel/partman/Makefile > > +++ b/doc/devel/partman/Makefile > [...] > > +all: *.xsl *.dbk > > + @./build.sh > [...] > > make doesn't expand wildcards automatically; you need to use the > $(wildcard) function to do that. Good catch. Thanks. This calls for 2 fixes ;-) Updated patch attached. Osamu PS: I copied Makefile from "doc/devel/internals" with funny feeling... From 6304f8e283e742b3b2831ca1f62a390621b76503 Mon Sep 17 00:00:00 2001 From: Osamu Aoki Date: Fri, 31 Aug 2018 10:54:10 + Subject: [PATCH] partman-doc: Convert to DocBook XML 4.5 Convert with: $ debiandoc2dbk -1 partman-doc.sgml Build script are from internals (some symlink) Also update .gitignore to match all *.html Signed-off-by: Osamu Aoki --- debian/control |4 +- debian/rules |2 +- doc/devel/internals/.gitignore |2 +- doc/devel/internals/Makefile |2 +- doc/devel/partman/.gitignore |2 +- doc/devel/partman/Makefile | 27 +- doc/devel/partman/build.sh | 16 + doc/devel/partman/internals.css|1 + doc/devel/partman/partman-doc.dbk | 1751 doc/devel/partman/partman-doc.sgml | 1507 doc/devel/partman/style-common.xsl |1 + doc/devel/partman/style-html.xsl |1 + 12 files changed, 1778 insertions(+), 1538 deletions(-) create mode 100755 doc/devel/partman/build.sh create mode 12 doc/devel/partman/internals.css create mode 100644 doc/devel/partman/partman-doc.dbk delete mode 100644 doc/devel/partman/partman-doc.sgml create mode 12 doc/devel/partman/style-common.xsl create mode 12 doc/devel/partman/style-html.xsl diff --git a/debian/control b/debian/control index f903622e2..686a5ef6d 100644 --- a/debian/control +++ b/debian/control @@ -24,12 +24,10 @@ Build-Depends: # Used to test validity of mirrors. bc, # Used for some image size calculations. - debiandoc-sgml, -# partman's manual is in debiandoc. xsltproc, docbook-xml, docbook-xsl, -# The d-i internals manual is in DocBook XML. +# The d-i partman-doc and internals manual is in DocBook XML 4.x. libbogl-dev, # For bdftobogl used in font reduction. # diff --git a/debian/rules b/debian/rules index e4f417dfd..63ae420d5 100755 --- a/debian/rules +++ b/debian/rules @@ -75,7 +75,7 @@ binary-arch: install dh_testroot dh_installchangelogs dh_installdocs doc/* -X Makefile -X build.sh -X .xsl \ - -X internals.xml -X partman-doc.sgml -X .gitignore + -X internals.xml -X partman-doc.dbk -X .gitignore dh_compress dh_fixperms diff --git a/doc/devel/internals/.gitignore b/doc/devel/internals/.gitignore index eb6fe0602..3432c3fd8 100644 --- a/doc/devel/internals/.gitignore +++ b/doc/devel/internals/.gitignore @@ -1,2 +1,2 @@ -index.html +*.html diff --git a/doc/devel/internals/Makefile b/doc/devel/internals/Makefile index 27a89b8c1..2629d1c6a 100644 --- a/doc/devel/internals/Makefile +++ b/doc/devel/internals/Makefile @@ -1,4 +1,4 @@ -all: *.xsl *.xml +all: @./build.sh clean: diff --git a/doc/devel/partman/.gitignore b/doc/devel/partman/.gitignore index ca2b6c7a2..3432c3fd8 100644 --- a/doc/devel/partman/.gitignore +++ b/doc/devel/partman/.gitignore @@ -1,2 +1,2 @@ -partman-doc.html +*.html diff --git a/doc/devel/partman/Makefile b/doc/devel/partman/Makefile index b9cbcc66c..2629d1c6a 100644 --- a/doc/devel/partman/Makefile +++ b/doc/devel/partman/Makefile @@ -1,26 +1,5 @@ -SHELL=bash -name=partman-doc - -$(name).html/: $(name).sgml - debiandoc2html $(name).sgml - -%.txt: %.sgml - debiandoc2text $< - -%.pdf: %.sgml - debiandoc2pdf $< - -%.dvi: %.sgml - debiandoc2dvi $< - -%.info: %.sgml - debiandoc2info $< - -%.ps: %.sgml - debiandoc2ps $< - -%.tov: %.sgml - debiandoc2textov $< +all: + @./build.sh clean: - rm -rf $(name).html + @rm -f *.html diff --git a/doc/devel/partman/build.sh b/doc/devel/partman/build.sh new file mode 100755 index 0..a5e8e7816 --- /dev/null +++ b/doc/devel/partman/build.sh @@ -0,0 +1,16 @@ +#!/bin/sh + +xsltproc=`which xsltproc` +stylesheet=/usr/share/sgml/docbook/stylesheet/xsl/nwalsh/html/chunk.xsl + +if [ -n "$xsltproc" ] ; then +if [ -e "$stylesheet" ]; then + $xsltproc --xinclude style-html.xsl partman-doc.dbk +else + echo "stylesheet missing; please install the docbook-xsl Debian package" + exit 1 +fi +else +echo "xsltproc not found; please install the xsltproc Debian package" +exit 1 +fi diff --git a/doc/devel/partman/internals.css b/doc/devel/partman/internals.css new file mode 12 index 0..44d290828 --- /dev/null +++ b/doc/devel/partman/internals.css @@ -0,0 +1 @@ +../internals/internals.css \ No newline at end of file diff --git a/doc/devel/partman/partman-doc.dbk b/doc/devel/partman/partman-
Bug#907970: Please stop using debiandoc-sgml (deprecated)
Package: debian-installer Version: 20180610 Severity: normal Tags: patch I am in process of dropping debiandoc-sgml. So please convert partman-doc to DocBook XML with attached patch. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (10, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled From 9e165a7690557672fcba4278894858b0badc789f Mon Sep 17 00:00:00 2001 From: Osamu Aoki Date: Fri, 31 Aug 2018 10:54:10 + Subject: [PATCH] partman-doc: Convert to DocBook XML 4.5 Convert with: $ debiandoc2dbk -1 partman-doc.sgml Build script are from internals (some symlink) Also update .gitignore to match all *.html Signed-off-by: Osamu Aoki --- debian/control |4 +- debian/rules |2 +- doc/devel/internals/.gitignore |2 +- doc/devel/partman/.gitignore |2 +- doc/devel/partman/Makefile | 27 +- doc/devel/partman/build.sh | 16 + doc/devel/partman/internals.css|1 + doc/devel/partman/partman-doc.dbk | 1751 doc/devel/partman/partman-doc.sgml | 1507 doc/devel/partman/style-common.xsl |1 + doc/devel/partman/style-html.xsl |1 + 11 files changed, 1777 insertions(+), 1537 deletions(-) create mode 100755 doc/devel/partman/build.sh create mode 12 doc/devel/partman/internals.css create mode 100644 doc/devel/partman/partman-doc.dbk delete mode 100644 doc/devel/partman/partman-doc.sgml create mode 12 doc/devel/partman/style-common.xsl create mode 12 doc/devel/partman/style-html.xsl diff --git a/debian/control b/debian/control index f903622e2..686a5ef6d 100644 --- a/debian/control +++ b/debian/control @@ -24,12 +24,10 @@ Build-Depends: # Used to test validity of mirrors. bc, # Used for some image size calculations. - debiandoc-sgml, -# partman's manual is in debiandoc. xsltproc, docbook-xml, docbook-xsl, -# The d-i internals manual is in DocBook XML. +# The d-i partman-doc and internals manual is in DocBook XML 4.x. libbogl-dev, # For bdftobogl used in font reduction. # diff --git a/debian/rules b/debian/rules index e4f417dfd..63ae420d5 100755 --- a/debian/rules +++ b/debian/rules @@ -75,7 +75,7 @@ binary-arch: install dh_testroot dh_installchangelogs dh_installdocs doc/* -X Makefile -X build.sh -X .xsl \ - -X internals.xml -X partman-doc.sgml -X .gitignore + -X internals.xml -X partman-doc.dbk -X .gitignore dh_compress dh_fixperms diff --git a/doc/devel/internals/.gitignore b/doc/devel/internals/.gitignore index eb6fe0602..3432c3fd8 100644 --- a/doc/devel/internals/.gitignore +++ b/doc/devel/internals/.gitignore @@ -1,2 +1,2 @@ -index.html +*.html diff --git a/doc/devel/partman/.gitignore b/doc/devel/partman/.gitignore index ca2b6c7a2..3432c3fd8 100644 --- a/doc/devel/partman/.gitignore +++ b/doc/devel/partman/.gitignore @@ -1,2 +1,2 @@ -partman-doc.html +*.html diff --git a/doc/devel/partman/Makefile b/doc/devel/partman/Makefile index b9cbcc66c..2e36b62b3 100644 --- a/doc/devel/partman/Makefile +++ b/doc/devel/partman/Makefile @@ -1,26 +1,5 @@ -SHELL=bash -name=partman-doc - -$(name).html/: $(name).sgml - debiandoc2html $(name).sgml - -%.txt: %.sgml - debiandoc2text $< - -%.pdf: %.sgml - debiandoc2pdf $< - -%.dvi: %.sgml - debiandoc2dvi $< - -%.info: %.sgml - debiandoc2info $< - -%.ps: %.sgml - debiandoc2ps $< - -%.tov: %.sgml - debiandoc2textov $< +all: *.xsl *.dbk + @./build.sh clean: - rm -rf $(name).html + @rm -f *.html diff --git a/doc/devel/partman/build.sh b/doc/devel/partman/build.sh new file mode 100755 index 0..a5e8e7816 --- /dev/null +++ b/doc/devel/partman/build.sh @@ -0,0 +1,16 @@ +#!/bin/sh + +xsltproc=`which xsltproc` +stylesheet=/usr/share/sgml/docbook/stylesheet/xsl/nwalsh/html/chunk.xsl + +if [ -n "$xsltproc" ] ; then +if [ -e "$stylesheet" ]; then + $xsltproc --xinclude style-html.xsl partman-doc.dbk +else + echo "stylesheet missing; please install the docbook-xsl Debian package" + exit 1 +fi +else +echo "xsltproc not found; please install the xsltproc Debian package" +exit 1 +fi diff --git a/doc/devel/partman/internals.css b/doc/devel/partman/internals.css new file mode 12 index 0..44d290828 --- /dev/null +++ b/doc/devel/partman/internals.css @@ -0,0 +1 @@ +../internals/internals.css \ No newline at end of file diff --git a/doc/devel/partman/partman-doc.dbk b/doc/devel/partman/partman-doc.dbk new file mode 100644 index 0..fafd15c73 --- /dev/null +++ b/doc/devel/partman/partman-doc.dbk @@ -0,0 +1,1751 @@ + + +http://www.oasis-open.org/docbook/xml/4.5/docbookx.
installation-guide: USB boot
Hi, Installation guide on USB boot is a bit outdated and may need some touch up. (I could not find package to file bug report.) === USB-HDD and USB Legacy === http://d-i.debian.org/manual/en.i386/apas02.html#howto-getting-images-usb A.2.2. USB memory stick | Some BIOSes can boot USB storage directly, and some cannot. You may need | to configure your BIOS to boot from a “removable drive” or even a | “USB-ZIP” to get it to boot from the USB device. For helpful hints and | details, see Section 5.1.5, “Booting from USB Memory Stick”. I think this can be: | Some BIOSes can boot USB storage directly, and some cannot. You may need | to configure your BIOS to set "USB legacy support". The boot device | selection menu should show “removable drive”, "USB-HDD", or even | “USB-ZIP” to get it to boot from the USB device. For helpful hints and | details, see Section 5.1.5, “Booting from USB Memory Stick”. The rationale is: Since current document focus is on iso image copied onto USB, this is confusing to have USB-ZIP and not USB-HDD. Many new BIOSs have USB-HDD boot support if USB legacy support is enabled. USB-HDD installation is quite easy, it is usable and intuitive from the HDD image and documented in: 4.3.2. Manually copying files to the USB stick 4.3.3. Manually copying files to the USB stick — the flexible way These seems to be complete. === USB-ZIP === USB-ZIP is said to require special partition and use /de/sd?4 for the data as documented in the syslinux documentation: /usr/share/doc/syslinux-common/txt/usbkey.txt So adding pointer to this is needed somewhere on the document is desirable (Probably at the bottom of 4.3.) === USB Legacy and interfarence === http://d-i.debian.org/manual/en.amd64/ch03s06.html#boot-dev-select 3.6.2. Boot Device Selection Here, mention that you may need to enable "USB legacy support" to get USB memory stick to become bootable. (I have been bitten several times. So I am sure on this.) 3.6.4. Disabling the Windows 8 “fast boot” feature Here, mention that enabling "USB legacy support" may interfare with booting of Windows 8. (This is what I saw on the net.) Regards, Osamu -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140619154742.GA31387@goofy
Bug#600320: Migration from Ubuntu to Debian
Hi, As Otavio pointed out, d-i is meant to install system to fresh formatted partition. This does not mean that you can not use d-i to migrate your system to new Debian with some skill. Since you are an experienced admin, I suspect you were doing this fresh install to an empty partition while copying many configuration files and data from old system partition. Are you sure you did this configuration data migration properly? It does take careful attention to the detail. As I vaguely remember, Some Ubuntu installations do no set up root password but lets user login via sudo as default. Debian does not set up sudo as installed. So if you copied /etc/passwd and /etc/shadow from old Ubuntu to new Debian system, you are likely loose password login to root since Ubuntu file is missing it and you do not have sudo and its required setup. FYI: you must be careful about variable system group ID between 101-999 when migrating system with manual copying. I just got hit by this from lenny to squeeze upgrade. Osamu (You may be able to upgrade Ubuntu to Debian without d-i but toth dist-upgrade by pointing URL in /etc/apt-sources.list to newer Debian version. This Ubuntu->Debian conversion method is not guaranteed nor supported to work.) -- 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/20101016045143.ga27...@debian.org
Re: is lilo ever installed by default anymore?
On Tue, Sep 21, 2010 at 10:24:29AM +0200, posion bit wrote: > On Tue, Sep 21, 2010 at 9:38 AM, Christian Perrier wrote: > >>> So, I would say that LILO is no longer the default installer for some > >>> installations of lenny. > >> > >> Do you mean Squeeze? > > > > Yes, Squeeze > > > >> What if /boot is on LVM (can happen with manual partitioning)? Grub2 > >> can (at least in principle) handle this, but I've never seen that in > >> action. > > > > Probably needs to be checked..:) > > Hi, > > I don't know If this may help, but I can say that the thinkpad where I > tested squeeze, all the disk is a single partition defined as LVM > volume group, and my logical volume /boot is into. D-I choosed grub2 > (and worked). > > Time ago, when you choosed /boot into LVM, lilo was choosed by d-i I think. > > And If I don't remember bad, lilo was "auto" choosed in eFi hardware > (intel iMac), but I can't say if squeeze does the same, because I need > to track stable on my imac. I have MacBook here :-) FYI: * Even for lenny d-i as I checked just before release Normal MBR system (amd64/i386): grub (GRUB 1) MacBook EFI system (amd64/i386): grub-pc (GRUB 2) * squeeze d-i Both are grub-pc (GRUB 2). Early lenny testing d-i chose grub (GRUB 1) and I had to chose manually lilo to get it installed and going. Osamu -- 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/20100921134136.gc3...@debian.org
Re: Some kFreeBSD port of Installation manual
Hi, On Tue, Aug 24, 2010 at 12:54:53PM +0200, Samuel Thibault wrote: > Miguel Figueiredo, le Tue 24 Aug 2010 11:02:15 +0100, a écrit : > > On 24-08-2010 01:18, Samuel Thibault wrote: > > >+Debian GNU/kFreeBSD is a Debian GNU system that replaces the Linux > > >+kernel with the kFreeBSD kernel. This port of Debian is currently > > >+only being developed for the i386 and amd64 architectures, although > > >+ports to other architectures is possible. > > > > +Debian GNU/kFreeBSD is a Debian GNU system with the kFreeBSD kernel. > > > > Removed "replaces Linux kernel". > > Why removing it? I feel it's quite important to underline that Debian > GNU/kFreeBSD is not a Linux distribution, to reduce the number of users > installing it by error and wondering why a lot of tutorials don't work > with their installation. I think both have good points. Definition of "Debian GNU/kFreeBSD" does not need to be destructed by excuse of not-being-Linux. But the waring for non-Linux should remain. What about text along: | Debian GNU/&arch-kernel; is a Debian GNU system with the &arch-kernel; kernel. | | This port of Debian is currently only being developed for the i386 and | amd64 architectures, although ports to other architectures is possible. | | Please note that Debian GNU/&arch-kernel; is not a Linux system thus some | information on Linux system may not apply to it. Of course the second and last should be arch specific. HURD may be able to share some text, too :-) -- 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/20100824153923.ga3...@debian.org
Bug#526862: console-setup: fail to configure Japanese keyboard
Hi, On Mon, May 04, 2009 at 04:53:07PM +0300, Anton Zinoviev wrote: > severity 526862 grave > thanks > > On Mon, May 04, 2009 at 12:54:37PM +0900, Osamu Aoki wrote: > > > > After upgrading to sid from lenny, keyboard under X started acting like US > > 101 > > variants even though it should be OADG109A layout as Japanese. > > Thanks for your bug report - this is a realy serious problem caused by > the Debconf part of console-setup (it expects to find jp(latin) layout > that existed in the old times of etch). For now I can recommend you to > change /etc/default/console-setup to contain lines like these two: > > XKBLAYOUT="us,jp" > XKBVARIANT=",OADG109A" This worked as work around. > After this change X should be usable again. Well, it was sort of usable if I blind touch ... > > Here is details: > > Thanks, sometimes such information is really necessary. It will help if > you send also your /etc/X11/xorg.conf and /etc/default/console-setup > files (before the changes you make in the second file). I have simple /etc/X11/xorg.conf under fresh install or upgrade after "sudo dpkg-reconfigure -plow xserver-xorg". These /etc/X11/xorg.conf as: -- Section "Device" Identifier "Configured Video Device" EndSection -- I also had problem when keeping my keyboard related part of lenny /etc/X11/xorg.conf configuration as: -- Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" Option "XkbRules" "xorg" Option "XkbModel" "jp106" Option "XkbLayout" "jp" EndSection -- As for /etc/default/console-setup of fresh install and after modification (original state is commented out): -- # A configuration file for setupcon # Change to "yes" and setupcon will explain what is being doing VERBOSE_OUTPUT=no # Setup these consoles. Most people do not need to change this. ACTIVE_CONSOLES="/dev/tty[1-6]" # Put here your encoding. Valid charmaps are: UTF-8 ARMSCII-8 CP1251 # CP1255 CP1256 GEORGIAN-ACADEMY GEORGIAN-PS IBM1133 ISIRI-3342 # ISO-8859-1 ISO-8859-2 ISO-8859-3 ISO-8859-4 ISO-8859-5 ISO-8859-6 # ISO-8859-7 ISO-8859-8 ISO-8859-9 ISO-8859-10 ISO-8859-11 ISO-8859-13 # ISO-8859-14 ISO-8859-15 ISO-8859-16 KOI8-R KOI8-U TIS-620 VISCII CHARMAP="UTF-8" # The codeset determines which symbols are supported by the font. # Valid codesets are: Arabic Armenian CyrAsia CyrKoi CyrSlav Ethiopian # Georgian Greek Hebrew Lao Lat15 Lat2 Lat38 Lat7 Thai Uni1 Uni2 Uni3 # Vietnamese. Read README.fonts for explanation. CODESET="Uni1" # Valid font faces are: VGA (sizes 8, 14 and 16), Terminus (sizes # 12x6, 14, 16, 20x10, 24x12, 28x14 and 32x16), TerminusBold (sizes # 14, 16, 20x10, 24x12, 28x14 and 32x16), TerminusBoldVGA (sizes 14 # and 16), Fixed (sizes 13, 14, 15, 16 and 18), Goha (sizes 12, 14 and # 16), GohaClassic (sizes 12, 14 and 16). FONTFACE="VGA" FONTSIZE="16" # You can also directly specify nonstandard font and ACM to load. # Use space as separator if you want to load more than one font. # FONT='lat9w-08.psf.gz /usr/local/share/brailefonts/brl-08.psf' # ACM=/usr/local/share/consoletrans/my_special_encoding.acm # The following variables describe your keyboard and can have the same # values as the XkbModel, XkbLayout, XkbVariant and XkbOptions options # in /etc/X11/xorg.conf. XKBMODEL="jp106" ## # generated by debconf as reported for 526862 #XKBLAYOUT="jp,jp" #XKBVARIANT="latin,OADG109A" # manually set per Anton Zinoviev XKBLAYOUT="us,jp" XKBVARIANT=",OADG109A" ## XKBOPTIONS="grp:alt_shift_toggle,grp_led:scroll" -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#526862: console-setup: fail to configure Japanese keyboard
Package: console-setup Version: 1.32 Severity: normal After upgrading to sid from lenny, keyboard under X started acting like US 101 variants even though it should be OADG109A layout as Japanese. This maybe the same problem as bug#524233 since I had console-tools installed. Here is details: My system is Japanese, Linux console is still working fine. But under X: Shift-2 under Japanese should be " while under X, it is @ like US. Shift-; under Japanese should be + while under X, it is : like US. ... I tried to fix it from Gnome GUI interface, it print error message and reuse to change keyboad type. I initially tried to reconfigure X itself but it did not work and realized console-setup maybe the cause. Since it is quite difficult to use system to report bug under sid, I booted from lenny system and run reportbug and dpkg-reconfigure as chroot. chroot $ sudo dpkg-reconfigure -plow console-setup Cannot find /proc/version - is /proc mounted? invoke-rc.d: invoke-rc.d: WARNING: invoke-rc.d called during shutdown sequence invoke-rc.d: enabling safe mode: initscript policy layer disabled invoke-rc.d: WARNING: Can not find "latin" in "jp". Cannot find /proc/version - is /proc mounted? invoke-rc.d: invoke-rc.d: WARNING: invoke-rc.d called during shutdown sequence Here, you can see 'Can not find "latin" in "jp"'. This is the error I saw under real sid too. This X problem seems to be rooted from console-setup and its database. (I remember dialogue under real unstable complained jp,jp does not exist blah, blah,... before this message. ) Since I could not find quick fix, I downgraded system since then. Following are taken under chroot with -p option. -- System Information: (obtained in sid chroot, I have not downgraded yet) Debian Release: squeeze/sid APT prefers stable (not yet used, it was unstable) APT policy: (1100, 'stable') (not used) Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages console-setup depends on: ii console-terminus 4.26-2.1 Fixed-width fonts for fast reading ii debconf [debconf-2.0] 1.5.26 Debian configuration management sy ii xkb-data 1.5-2 X Keyboard Extension (XKB) configu Versions of packages console-setup recommends: ii console-tools1:0.2.3dbs-65.1 Linux console and font utilities Versions of packages console-setup suggests: ii locales 2.9-8 GNU C Library: National Language ( ii lsb-base 3.2-22 Linux Standard Base 3.2 init scrip -- debconf information: * console-setup/variant: Japan - OADG 109A console-setup/unsupported_options: true * console-setup/fontsize-text: 16 * console-setup/compose: No compose key console-setup/modelcode: jp106 * console-setup/switch: No temporary switch * console-setup/unsupported_config_layout: true console-setup/fontsize: 16 console-setup/unsupported_layout: true * console-setup/charmap: UTF-8 console-setup/layoutcode: jp,jp console-setup/optionscode: grp:ctrl_shift_toggle,grp_led:scroll debian-installer/console-setup/title: console-setup/unsupported_config_options: true * console-setup/layout: Japan console-setup/variantcode: latin,OADG109A console-setup/codesetcode: Lat15 * console-setup/altgr: No AltGr key * console-setup/ttys: /dev/tty[1-6] * console-setup/model: Japanese 106-key console-setup/fontsize-fb: 16 * console-setup/codeset: # Latin1 and Latin5 - western Europe and Turkic languages * console-setup/toggle: Control+Shift * console-setup/fontface: Fixed -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#502446: debian-installer: grub-installer is not updated for grub-pc introduction
Hi, Thanks for interesting comment. On Sun, Nov 16, 2008 at 12:40:12PM +0100, Robert Millan wrote: > On Sun, Nov 16, 2008 at 07:36:52PM +0900, Osamu Aoki wrote: > > > > I wonder why we offer to install grub-pc to non-MBR locations in lenny. > > For me, disabling that is an option. But fixing it is even nicer. > > Erm, we shouldn't be doing this. When installing in a partition head, you > can't really check if there will be enough space. It depends on how much is > reserved by your filesystem of choice, which is often not enough anyway. > > And even if it is, it's an ugly hack to reuse a partition for two different > things at the same time. Hmmm... interesting thought. If this is true, I agree we should drop asking non MBR location. But many Linux distros allow us to install boot loader in chain-loading mode at MBR or head of partition of ext2/3 as I remember. I thought for modern HDD with LBA, there is always first track = 63 sectors = 31.5KiB available in MBR and partition head (formatted with ext2/ext3/vfat/... at least) which grub assumes to use for GRUB Stage 1.5. (I know there were days when I envyed HDD with 10 MB capacity and only 17 sector per track. Then grub should have problem istalling it to it.) > > > This is something we already solved in GRUB 2 (by using UUIDs). > > > > I wonder if GRUB2's /etc/grub.d/30_os-prober can be used from > > grub-installer in squeeze. > > Should be no problem. It just takes installing os-prober in the target > system before update-grub is run. I thought so too and tried it. But as I tried update-grub command in chroot at /target while having os-prober installed in chroot from installer, it did not find other partitions. /chroot/dev directory did not have /chroot/dev/sda etc. /dev/sda etc. were there but could not be seen from chroot. > > I guess chroot does not have appropriate > > devices to get this script to produce right result. > > I don't think so. If devices were missing, grub-probe / grub-setup wouldn't > work in this environment, and installation wouldn't be possible. Device was not missing. /dev/sda exists. But issuing chroot /target without appropriate care in advance caused problem. Thus there is need to write code :-) Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#502446: debian-installer: grub-installer is not updated for grub-pc introduction
Hi, On Sat, Nov 15, 2008 at 12:26:43PM +0100, Robert Millan wrote: > > Hi, > > Otavio asked me to comment on this. > > Notice that I maintain grub/grub2, not grub-installer. In fact, my > recommendations as grub maintainer are often dismissed here, so take > this with a grain of salt. Thanks. > On Thu, Oct 16, 2008 at 11:41:22PM +0900, Osamu Aoki wrote: > > > > But if you do, you must take care critical diffrences of these 2 > > programs. > > > > For /dev/hda3, grub legacy used (hd0,2) while grub 2 use (hd0,3). > > > > The template file in grub-installer needed to be updated not to mislead > > users. Template: grub-installer/bootdev needs to be updated > > "(hd0,1)" --> "(hd0,2)" > > "(hd2,4)" --> "(hd2,5)" > > as: > > It's not critical, and I don't think it's worth it. It just affects a > template > description, and this particular problem is hopefully going away post-Lenny as > soon as GRUB Legacy is completely deprecated. I agree it is not a critical bug since if grub-pc is installed to MBR per default, this problem be will not be seen. Problem is not just description inconsistency. If you chose to install to (hd0,2) or /dev/hda3, grub-pc is currently installed to /dev/hda2 overwriting whatever is there. This was not something I appreciated. It may kill some existig boot data. That is not so nice thing to do. That is why I was concerned. I wonder why we offer to install grub-pc to non-MBR locations in lenny. For me, disabling that is an option. But fixing it is even nicer. My patch is updated and factorized: http://people.debian.org/~osamu/ I now use Robert's fix as a part since I think that is better fix for the problem. My string updates covers all language. As far as lenny is concerned, we are supporting GRUB Legacy and 2 for different case. Neglecting this fact is not good for lenny. But I am not pushing this to delay release nor pushing this for squeeze. > #473401 OTOH has a real effect in end usability, and should be taken into > consideration for Lenny. I agree it is quite annoying. This has to be fixed more. I do not expect users has to use interactive mode to edit grub menu. His patch makes sense too. > > The device can be specified using GRUB's "(hdn,m)" notation, or as a device > > in /dev. Below are some examples: > > - "(hd0)" or "/dev/hda" will install GRUB to the master boot record > > of your first hard drive (IDE); > > This paragraph leads user to think there's a 1:1 correspondence between GRUB > drives (which are enumerated by BIOS) and Linux devices (which are enumerated > by Linux itself). However, it's really a game of gambling. E.g. "/dev/hda" > is "(hd0)" _most of the time_, but not always. I agree. > This is something we already solved in GRUB 2 (by using UUIDs). I wonder if GRUB2's /etc/grub.d/30_os-prober can be used from grub-installer in squeeze. I guess chroot does not have apropriate devices to get this script to produce right result. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#502446: update on grub-installer
As I check after good night sleep, I realize my previous patch should have been not: +frgrubroot=$(($frbootpart - $grub_part_offset)) but should have been: +frgrubroot=$(($frgrubroot - $grub_part_offset)) if this should also work for Serial ATA multipath which I do not use. (RAID should have been OK.) Other than this, I like Robert Millan's patch and integrated it to mine which address more issues. I still think making 30_otheros is ugly hack and if possible should be replaced with grub's code itself. After installing os-prober with "apt-install os-prober" , running $chroot $ROOT update-grub should create entry but it doesn't as now. It could likely be availability of /dev/hd? /dev/sd? etc in chroot. Osamu PS: bug in my earlier patch thought was: s/grub_vrsion/grub_version/ +case $grub_vrsion in + grub) frgrubroot=$(($frbootpart - 1)) ;; + grub2) frgrubroot=$frbootpart ;; + *) exit 1 ;; +esac This part again hit me when I changed style. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#473401: grub2 related patch
Hi, Roert's patch certainly address issue of grub 2 partition number elegantly, it does not address wrong text presented to the user as d-i interaction. I made similar patch but with all the text and its translations. See it at http://bugs.debian.org/502446 I also made beta2 netinst with corrected package. It fix situation for me but can you test them too. http://people.debian.org/~osamu/grub-installer_1.35.all.diff.gz http://people.debian.org/~osamu/d-i-osamu-grub2-all-translation-amd64.iso It will be easier to check diff w/o po: http://people.debian.org/~osamu/grub-installer_1.35.all-but-po.diff.gz Osamu PS: My patch is less logical change within grub-installer. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#502446: grub-installer patch with complete po file updates :-)
Hi, Current grub-installer script will overwrite boot sector of wrong partition for Intel based Mac users. This is not so nice thing to have for release. I now have tested and updated patch for this bug and test d-i image at: http://people.debian.org/~osamu/d-i-osamu-grub2.iso http://people.debian.org/~osamu/grub-installer_1.35.all-but-po.diff.gz It works! I also made full patch including translated text for all languages and put at: http://people.debian.org/~osamu/grub-installer_1.35.all.diff.gz (No code change but just po and comment out of set -x.) So this patch will not degrade translation status, and please consider this fr inclusion. Patch is based on unstable 1.35 package. --- Here is details. Since my bug report and my patch concept, I spend some time to recall d-i testing tricks. (I made diunpk and dipk script: http://wiki.debian.org/DebianInstaller/Modify/CD ) My initial patch had typo but my idea was confirmed right. 1) GRUB2 device name has no offset and need adjustment as proposed. 2) rescue mode now offer boot loader installation on GRUB 2 too. 3) 30_os-prober script of grub-pc is fine but it must be run after rebooting system to be more useful. (see below) 4) gptsync needs to be installed and run from shell console in chroot but this can be done by rEFIt chain bootloader side too. Thus d-i is usable on MacTel (Intel Macs). I intentionally left not-so-precise statement of "first extended partition" under GPT. This is because this will create translation headache. Osamu FYI: If os-prober package is initially installed and a post reboot hook script is made to run update-grub script, grub.cfg is generated correctly without 30_otheros from grub-installer. This will make cleaner installation code. This should be post-lenny thing. grub-installer_1.35.all-but-po.diff.gz Description: Binary data
Bug#502446: debian-installer: grub-installer is not updated for grub-pc introduction
Hi, As I looked more in detail, debian-installer works fine (does not over write unrelated data) and usable if MBR is used as BIOS emultion mode boot loader. (I.e., installed to /dev/sda (hd0) So problem is when installing to /dev/sda3 or in other word to (hd0,3). Since this causes data loss, this could be considered grave. But changing d-i this late may not be good idea. If so reminder not to install to places such as /dev/sda3. Anyway, installation needs to do few manual tricks including gptsync. http://wiki.debian.org/MacBook/DebianInstallTutorial Documenting this as short comments in release note is good idea. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#502446: patch second try... Bug#502446: grub-installer
Hi,
For Bug #502446: http://bugs.debian.org/502446
Here is updated patch which takes care odd partition offset of grub
legacy. Around frdev, I may have been too aggressive
I will test this later ...
Osamu
diff -Nru grub-installer-1.35/debian/changelog grub-installer-1.35+nmu2/debian/changelog
--- grub-installer-1.35/debian/changelog 2008-09-30 03:31:13.0 +0900
+++ grub-installer-1.35+nmu2/debian/changelog 2008-10-19 15:08:37.0 +0900
@@ -1,3 +1,17 @@
+grub-installer (1.35+nmu2) experimental; urgency=low
+
+ * more hacking ... this should fix boot partition calculation
+but it may be over correction for some RAID thingy.
+
+ -- Osamu Aoki <[EMAIL PROTECTED]> Sun, 19 Oct 2008 15:07:24 +0900
+
+grub-installer (1.35+nmu1) experimental; urgency=low
+
+ * Non-maintainer upload. (I will not do it)
+ * support grub2 with correct message on device name convention
+
+ -- Osamu Aoki <[EMAIL PROTECTED]> Sun, 19 Oct 2008 12:00:26 +0900
+
grub-installer (1.35) unstable; urgency=low
* Add support for MMC/SD card devices (mmcblkX).
diff -Nru grub-installer-1.35/debian/grub-installer.templates grub-installer-1.35+nmu2/debian/grub-installer.templates
--- grub-installer-1.35/debian/grub-installer.templates 2008-04-28 17:38:06.0 +0900
+++ grub-installer-1.35+nmu2/debian/grub-installer.templates 2008-10-19 10:52:13.0 +0900
@@ -95,6 +95,26 @@
your third drive (SCSI here);
- "(fd0)" or "/dev/fd0" will install GRUB to a floppy.
+Template: grub-installer/bootdev2
+Type: string
+# :sl2:
+_Description: Device for boot loader installation:
+ You need to make the newly installed system bootable, by installing
+ the GRUB boot loader on a bootable device. The usual way to do this is to
+ install GRUB on the master boot record of your first hard drive. If you
+ prefer, you can install GRUB elsewhere on the drive, or to another drive,
+ or even to a floppy.
+ .
+ The device can be specified using GRUB's "(hdn,m)" notation, or as a device
+ in /dev. Below are some examples:
+ - "(hd0)" or "/dev/hda" will install GRUB to the master boot record
+of your first hard drive (IDE);
+ - "(hd0,2)" or "/dev/hda2" will use the second partition of your
+first IDE drive;
+ - "(hd2,5)" or "/dev/sdc5" will use the first extended partition of
+your third drive (SCSI here);
+ - "(fd0)" or "/dev/fd0" will install GRUB to a floppy.
+
Template: grub-installer/password
Type: password
# :sl2:
diff -Nru grub-installer-1.35/grub-installer grub-installer-1.35+nmu2/grub-installer
--- grub-installer-1.35/grub-installer 2008-09-30 03:24:48.0 +0900
+++ grub-installer-1.35+nmu2/grub-installer 2008-10-19 15:16:43.0 +0900
@@ -148,14 +148,14 @@
# GRUB's syntax
case "$host_os" in
linux*)
- echo "$tmp_drive" | sed "s%)$%,`expr $tmp_part - 1`)%"
+ echo "$tmp_drive" | sed "s%)$%,`expr $tmp_part - $grub_part_offset`)%"
;;
gnu*)
if echo $tmp_part | grep "^s" >/dev/null; then
tmp_pc_slice=$(echo $tmp_part | \
sed "s%s\([0-9]*\)[a-g]*$%\1%")
tmp_drive=$(echo "$tmp_drive" | \
- sed "s%)%,\`expr "$tmp_pc_slice" - 1\`)%")
+ sed "s%)%,\`expr "$tmp_pc_slice" - $grub_part_offset\`)%")
fi
if echo $tmp_part | grep "[a-g]$" >/dev/null; then
tmp_bsd_partition=$(echo "$tmp_part" | \
@@ -170,7 +170,7 @@
tmp_pc_slice=$(echo $tmp_part | \
sed "s%s\([0-9]*\)[a-h]*$%\1%")
tmp_drive=$(echo "$tmp_drive" | \
- sed "s%)%,\`expr "$tmp_pc_slice" - 1\`)%")
+ sed "s%)%,\`expr "$tmp_pc_slice" - $grub_part_offset\`)%")
fi
if echo $tmp_part | grep "[a-h]$" >/dev/null; then
tmp_bsd_partition=$(echo "$tmp_part" | \
@@ -279,7 +279,6 @@
if echo "$disc_offered" | grep -q "/$frdisk[0-9]\+"; then
frdev=/dev/mapper/$frdisk
frbootpart=${disc_offered#$frdev}
- frgrubroot=$(($frbootpart - 1))
frtype=sataraid
break
fi
@@ -292,7 +291,6 @@
grep -q "^/dev/mapper/${frdisk}-part[0-9]\+"; then
frdev=/dev/mapper/$frdisk
frbootpart=${disc_offered#$frdev}
- frgrubroot=$((${frbootpart#-part} - 1))
frtype=multipath
break
fi
@@ -369,10 +367,12 @@
grub)
grub_version="grub"
menu_file="menu.lst"
+ grub_part_offset="1"
;;
*)
grub_version="grub2"
menu_file="grub.cfg"
+ grub_part_offset="0"
;;
esac
@@ -477,7 +477,7 @@
if [ "$frdev" ]; then
if [ -e $ROOT$frdev ] && [ -e $ROOT$frdev$frbootpart ] && \
- [ $frgrubroot -ge 0 ]; then
+ [ $frgrubroot -ge 1 ]; then
db_subst gr
Bug#502446: Patch for Bug#502446: grub-installer is not updated for grub-pc introduction
tags 502446 patch
thanks
Just get my point clear, I am submitting untested patch as reference.
Once tested to be good, it is technically trivial (but time consuming)
to add po files for most European languages and CJK as long as po files
are in UTF-8. So this will not make much regression.
My work on rescue scripts are pure guessing work (but simple one.)
Osamu
diff -Nru grub-installer-1.35/debian/changelog grub-installer-1.35+nmu1/debian/changelog
--- grub-installer-1.35/debian/changelog 2008-09-30 03:31:13.0 +0900
+++ grub-installer-1.35+nmu1/debian/changelog 2008-10-19 12:01:59.0 +0900
@@ -1,3 +1,10 @@
+grub-installer (1.35+nmu1) experimental; urgency=low
+
+ * Non-maintainer upload. (I will not do it)
+ * support grub2 with correct message on device name convention
+
+ -- Osamu Aoki <[EMAIL PROTECTED]> Sun, 19 Oct 2008 12:00:26 +0900
+
grub-installer (1.35) unstable; urgency=low
* Add support for MMC/SD card devices (mmcblkX).
diff -Nru grub-installer-1.35/debian/grub-installer.templates grub-installer-1.35+nmu1/debian/grub-installer.templates
--- grub-installer-1.35/debian/grub-installer.templates 2008-04-28 17:38:06.0 +0900
+++ grub-installer-1.35+nmu1/debian/grub-installer.templates 2008-10-19 10:52:13.0 +0900
@@ -95,6 +95,26 @@
your third drive (SCSI here);
- "(fd0)" or "/dev/fd0" will install GRUB to a floppy.
+Template: grub-installer/bootdev2
+Type: string
+# :sl2:
+_Description: Device for boot loader installation:
+ You need to make the newly installed system bootable, by installing
+ the GRUB boot loader on a bootable device. The usual way to do this is to
+ install GRUB on the master boot record of your first hard drive. If you
+ prefer, you can install GRUB elsewhere on the drive, or to another drive,
+ or even to a floppy.
+ .
+ The device can be specified using GRUB's "(hdn,m)" notation, or as a device
+ in /dev. Below are some examples:
+ - "(hd0)" or "/dev/hda" will install GRUB to the master boot record
+of your first hard drive (IDE);
+ - "(hd0,2)" or "/dev/hda2" will use the second partition of your
+first IDE drive;
+ - "(hd2,5)" or "/dev/sdc5" will use the first extended partition of
+your third drive (SCSI here);
+ - "(fd0)" or "/dev/fd0" will install GRUB to a floppy.
+
Template: grub-installer/password
Type: password
# :sl2:
diff -Nru grub-installer-1.35/grub-installer grub-installer-1.35+nmu1/grub-installer
--- grub-installer-1.35/grub-installer 2008-09-30 03:24:48.0 +0900
+++ grub-installer-1.35+nmu1/grub-installer 2008-10-19 11:27:42.0 +0900
@@ -512,7 +512,11 @@
state=2
fi
else
- db_input critical grub-installer/bootdev || true
+ if [ "$grub_version" = "grub" ]; then
+ db_input critical grub-installer/bootdev || true
+ else
+ db_input critical grub-installer/bootdev2 || true
+ fi
if ! db_go; then
if [ "$q" ]; then
state=1
@@ -522,6 +526,11 @@
exit 10
fi
else
+ if [ "$grub_version" = "grub" ]; then
+db_get grub-installer/bootdev
+ else
+db_get grub-installer/bootdev2
+ fi
db_get grub-installer/bootdev
bootdev=$RET
if echo "$bootdev" | grep -qv '('; then
diff -Nru grub-installer-1.35/rescue.d/80grub-reinstall grub-installer-1.35+nmu1/rescue.d/80grub-reinstall
--- grub-installer-1.35/rescue.d/80grub-reinstall 2006-09-23 22:23:38.0 +0900
+++ grub-installer-1.35+nmu1/rescue.d/80grub-reinstall 2008-10-19 11:57:34.0 +0900
@@ -7,14 +7,22 @@
db_progress START 0 2 grub-installer/progress/title
db_progress INFO grub-installer/progress/step_bootdev
-db_input critical grub-installer/bootdev
+if [ -f /target/boot/grub/menu.lst ]; then
+ db_input critical grub-installer/bootdev
+else
+ db_input critical grub-installer/bootdev2
+fi
if ! db_go; then
# back up to menu
db_progress STOP
exit 10
fi
-db_get grub-installer/bootdev
+if [ -f /target/boot/grub/menu.lst ]; then
+ db_get grub-installer/bootdev
+else
+ db_get grub-installer/bootdev2
+fi
bootdev="$RET"
if echo "$bootdev" | grep -qv '('; then
mappedbootdev="$(mapdevfs "$bootdev")" || true
diff -Nru grub-installer-1.35/rescue.d/80grub-reinstall.tst grub-installer-1.35+nmu1/rescue.d/80grub-reinstall.tst
--- grub-installer-1.35/rescue.d/80grub-reinstall.tst 2006-07-26 07:50:27.0 +0900
+++ grub-installer-1.35+nmu1/rescue.d/80grub-reinstall.tst 2008-10-19 11:52:18.0 +0900
@@ -1,2 +1,2 @@
#! /bin/sh -e
-[ -f /target/boot/grub/menu.lst ]
+[ -f /target/boot/grub/menu.lst ] || [ -f /target/boot/grub/grub.cfg ]
Bug#502446: debian-installer: grub-installer is not updated for grub-pc introduction
Hi, I guess it is now reassigned grub-installer. Not just my emperical experience, here is rational for this bug report. http://grub.enbug.org/grub.cfg --- NOTE: you can use the update-grub utility to generate a grub.cfg file for you GRUB 2 uses new bashish scripting language that is used to build menus. At startup file grub.cfg will be read and executed. Please note that partition numbering has been changed to start from 1 (in grub legacy it started from 0). --- As I looked around, here is other issues wth grub-pc install in rc2. Issuing grub-install /dev/sd? with right install device did not fix my situation completely. Editting /boot/grub/grub.cfg with right root device for booting fixed the situation. Since this is generated file, root cause is its generation. Generation script is update-grub. Its /etc/grub.d/30_os-prober is the source of the problem. It calls commands packaged in os-prober. Most related parts of os-prober is its backend script: /usr/lib/linux-boot-probes/mounted/40grub /usr/lib/linux-boot-probes/mounted/40grub2 Since all these scripts seems to assume that grub legacy and grub 2 to use the same device name, they are in trouble and needs to be fixed in sync. I also do not know how we should deal with this at this late stage of release. I hope to get some response from maintainers involved. (os-prober is also d-i team pakage) If time is too late, we should document it in release note at least. To wrap up: Overwriting unrelated partition's boot sector qualifies as "critical" bug since this makes unrelated software (i.e. other OS's boot sector) on the system break where you install the package. Other issue like having broken multiboot is just annoiance. For now, I keep this as "important" bug. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#502446: debian-installer: grub-installer is not updated for grub-pc introduction
Package: debian-installer Version: rc2 Severity: important rc2 comes with grub-pc in its initramfs /pool directory. So d-i team decided to offer not only grub (grub legacy) but also grub-pc (grub 2). Good for you. grub-installer_1.32_i386.udeb grub-pc_1.96+20080512-1_i386.deb grub_0.97-39_i386.deb But if you do, you must take care critical diffrences of these 2 programs. For /dev/hda3, grub legacy used (hd0,2) while grub 2 use (hd0,3). The template file in grub-installer needed to be updated not to mislead users. Template: grub-installer/bootdev needs to be updated "(hd0,1)" --> "(hd0,2)" "(hd2,4)" --> "(hd2,5)" as: Template: grub-installer/bootdev Type: string Description: Device for boot loader installation: You need to make the newly installed system bootable, by installing the GRUB boot loader on a bootable device. The usual way to do this is to install GRUB on the master boot record of your first hard drive. If you prefer, you can install GRUB elsewhere on the drive, or to another drive, or even to a floppy. . The device can be specified using GRUB's "(hdn,m)" notation, or as a device in /dev. Below are some examples: - "(hd0)" or "/dev/hda" will install GRUB to the master boot record of your first hard drive (IDE); - "(hd0,2)" or "/dev/hda2" will use the second partition of your first IDE drive; - "(hd2,5)" or "/dev/sdc5" will use the first extended partition of your third drive (SCSI here); - "(fd0)" or "/dev/fd0" will install GRUB to a floppy. This should be easy to do for all languages and reduce confusion. Question is how to impliment it without breaking grub legacy. Maybe you create "Template: grub2-installer/bootdev" and adjust script based on boot loader used. I think this is one of the root cause of problem people are reporting such as: 501942. The other issue may be around 30_os-prober script in grub-pc package. I need to check more but this is less problematic since at least main OS will boot from right boot sector. (If I am pedantic, I can say that "/dev/sdc5" may not be the first extended partition but simply 5th partition in GPT. But this issue can be ignored since it is unlikely to cause any major cofusion.) -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (800, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413250: tasksel-data should be installable without tasksel
Package: tasksel-data Version: 2.66 Severity: wishlist This is not about http://bugs.debian.org/176089 . The heart of the tasksel-data is debian-tasks.desc and it seems to be used by gnome-tasksel and aptitude for creating tasklist. (If I am wrong here, please close this bug.) tasksel-data is a data so should not force to install one command tool (tasksel) which accesses it while the others (aptitude, gnome-tasksel, ...) may be the one accesing it for some people. So removing "Depends: tasksel" from tasksel-data package seems to be the right thing to do. I know if you do this right now, it will be a mess since currently gnome-tasksel is depending on tasksel instaed of tasksel-data and aptitude is recommending tasksel instaed of tasksel-data. So this needs to be cordinated with gnome-tasksel, aptitude, and As I speak about "Depends:" line in tasksel-data, laptop-detect is another one which looked odd. But this is OK since these are the system guessing criteria data in the form of small architectue independent codes which may be used by others. Osamu -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages tasksel-data depends on: ii laptop-detect 0.12.1 attempt to detect a laptop ii tasksel 2.66 Tool for selecting tasks for insta tasksel-data recommends no packages. -- no debconf information -- ~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ + Osamu Aoki <[EMAIL PROTECTED]> Yokohama Japan, GPG-key: A8061F32 .''`. Debian Reference: post-installation user's guide for non-developers : :' : http://qref.sf.net and http://people.debian.org/~osamu `. `' "Our Priorities are Our Users and Free Software" --- Social Contract -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404567: patch for traditional Chinese desktop task
Hi,
On Wed, Dec 27, 2006 at 08:36:25PM +, Wen-Yen Chuang wrote:
> > - m17n-env
> > + im-switch
I was going to request this too. (As the person who made the m17n-env package
and as the one who have been the de-facto current maintainer of
im-switch by most of recent updates/uploads.)
I have already removed features covered by im-switch from m17n-env and
almost all CJK-IM tools work with im-switch only.
Osamu
--
~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ +++++
Osamu Aoki <[EMAIL PROTECTED]> Yokohama Japan, GPG-key: A8061F32
.''`. Debian Reference: post-installation user's guide for non-developers
: :' : http://qref.sf.net and http://people.debian.org/~osamu
`. `' "Our Priorities are Our Users and Free Software" --- Social Contract
signature.asc
Description: Digital signature
Re: Default locale policy
On Sun, Nov 12, 2006 at 02:13:35AM -0800, Steve Langasek wrote: > On Sun, Nov 12, 2006 at 06:36:37PM +0900, Osamu Aoki wrote: > > I think this is what we should expect under UTF-8 encoding: > > > Console and daemon should run under: > > --> For en_* and all non-latain character countrues: > >en_US.UTF-8 > > --> For non-english latain character countries may choose: > >*.UTF-8 (Fr, De, It,...) but I think en_US.UTF-8 is OK too. > > > Then X applications should run under locale: > >*.UTF-8 ... > No, this is inappropriate. The reason /etc/default/locale was split from > /etc/environment is because /etc/environment is always intended to be used > by (and owned by) PAM, but /etc/default/locale is intended as a > general-purpose file, guaranteed to be parseable as a simple shell > assignment, that tells applications what the "system" locale is. > > If there is a need for a different "system" locale between the console and > X, then some other method would need to be devised. Please do not attempt > to overload the existing files for this. OK. Then that is what is needed. I am not particuar about how you do it but I care about result. Now it is clear For problematic locales, /etc/default/locale should contain en_US.UTF-8 while gdm, kdm, wdm, and xdm (probably) need to be started with a different file used by PAM which installer writes debconf chosen locale which used to be written to /etc/default/locale. Do any of you think appropriate to have /etc/default/locale-dm or somethig like it? It may be too late for etch to get all together but it is a thought. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Default locale policy
Hi, Here is my thought on locale set up after default installation should be. (This is with gdm 2.16.1-1) Currently, default locale valure as installed on my system is: LANG="en_US.UTF-8" This was selected not to get in troble with Japanese characters under console. That thought of UTF-8 itransition itself is good idea but it is not simple. I am wondering how best installer set up system. Unless one is as expert as the installer team to set up console UTF-8 environment under non-X situation (i.e.,Linux console), you will likely to get negative effect of screenfull of unreadable display if you are in locale where characters not covered by ISO-8859-1 or similar. This happens in places such as Japan, China, Russia, Thailand(I am guessing), ... (We do not set up UTF-8 framebuffer console as default by the installer) I think this is what we should expect under UTF-8 encoding: Console and daemon should run under: --> For en_* and all non-latain character countrues: en_US.UTF-8 --> For non-english latain character countries may choose: *.UTF-8 (Fr, De, It,...) but I think en_US.UTF-8 is OK too. Then X applications should run under locale: *.UTF-8 I see 2 critical files: /etc/environment /etc/default/locale The use is kind of mixed. And: from my "grep pam_env /etc/pam.d/*": | atd:auth required pam_env.so | cron:auth required pam_env.so | gdm:auth required pam_env.so read_env=1 | gdm:auth required pam_env.so read_env=1 envfile=/etc/default/locale | gdm-autologin:auth required pam_env.so read_env=1 | gdm-autologin:auth required pam_env.so read_env=1 envfile=/etc/default/locale | login:session required pam_env.so readenv=1 | login:session required pam_env.so readenv=1 envfile=/etc/default/locale | ssh:auth required pam_env.so # [1] | ssh:auth required pam_env.so envfile=/etc/default/locale | su:session required pam_env.so readenv=1 | su:session required pam_env.so readenv=1 envfile=/etc/default/locale I think changing as following will help: | atd:auth required pam_env.so | cron:auth required pam_env.so | gdm:auth required pam_env.so read_env=1 | gdm:auth required pam_env.so read_env=1 envfile=/etc/default/locale | gdm-autologin:auth required pam_env.so read_env=1 | gdm-autologin:auth required pam_env.so read_env=1 envfile=/etc/default/locale | login:session required pam_env.so readenv=1 | ssh:auth required pam_env.so # [1] | ssh:# auth required pam_env.so envfile=/etc/default/locale | su:session required pam_env.so readenv=1 /etc/environment LANG=en_US.UTF-8 /etc/default/locale LANG=ja_JP.UTF-8 This way we use /etc/default/locale for GDM while others use default /etc/environment. (Thanks to recent bug #361090 fix which some people oppose and reopened bug.) For French etc, maybe both /etc/default/locale and /etc/environment can be fr_FR.UTF-8 too. This way, we ensure GDM talks the local language while X is run under ones preffered locale set by GDM. At the same time, console, ssh and su are run under barebone so vt-100 terminal will not be surprized by Japanese characters. (SSH may bebetter to leave commented out line.) I do not care the use of these 2 files are swapped as long as gdm is started under *.utf-8 while console stays under en_US.utf-8. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFR] Manual - new section on CD (resend)
Hi, On Fri, Nov 03, 2006 at 07:39:01PM +0100, Frans Pop wrote: > On Friday 03 November 2006 09:54, Osamu Aoki wrote: > > I think it may be good idea to remind easy/quick fix solution before > > giving elaborate solution. So I suggest following as the starting > > section. > > Yes, I see your point. I have done that, though is a slightly different > way from what you suggested. Looks good to me. Then I have comment on other parts :-) As for 6.3.5.2.1. Configuring Your Mail Transport Agent | If none of these scenarios suits your needs, or if you need a finer | setup, you will need to edit configuration files under the /etc/exim4 | directory after the installation is complete. More information about | exim4 may be found under /usr/share/doc/exim4. Since there are too many files in /usr/share/doc/exim4 for people to read, it may be good idea to point people to the most important document. Somethink along: | If none of these scenarios suits your needs, or if you need a finer | setup, you will need to edit configuration files under the /etc/exim4 | directory after the installation is complete. Essential information about | exim4 is found in README.Debian.html (or README.Debian.gz) and other | files under /usr/share/doc/exim4. Smarthost is the most common case and many ISP requires SMTP-AUTH and use of mesage submidssion port (587), this doc is "MUST READ" for novice users to get them started. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFR] Manual - new section on CD (resend)
Since I do not see it on ML., resend... - Hi, On Tue, Oct 24, 2006 at 11:33:42PM +0200, Frans Pop wrote: > (Resending this mail as it hasn't reached the list after about 24 hours) > > Hi all, > > I've written a new section for the manual on how to deal with CD-ROM > problems (inspired by Osamu). > I'd appreciate a review/comments before I commit it. > > A preview is available from: > http://people.debian.org/~fjp/d-i/ch05s03.html I think it may be good idea to remind easy/quick fix solution before giving elaborate solution. So I suggest following as the starting section. | 5.3.1. CD-ROM Reliability | | Sometimes the installer may fail to boot from a CD-ROM. In this case, | we suggest you clean CD and try again first. It may be just due to | CD being dirty or loose. | | The installer may also — even after booting successfully from CD-ROM — | fail to recognize the CD-ROM or return errors while reading from it | during the installation. In this case, we suggest you to try mounting | CD from the installation menu shown right after error message first. | Some DMA related isses with older CD-ROM drive are known to be resolved | easily in this way. | | If you still face issues, there are a many different possible causes for | these problems. We can only list some common issues and provide general | suggestions on how to deal with them. The rest is up to you. | | If you cannot get the installation working from CD-ROM, try one of the | other installation methods that are available. As I understand, linux kernel switches automagically to non-DMA mode once it finds device does working with DMA mode. Somehow, in this case, symlink on CD does not come out OK on my old machine. Maybe some kernel issue on rockridge file system while kernel reconfiguring itself automagically to non-DMA. As for the non-IDE CD-ROM controller, I think that is less common than non-DMA IDE CD-ROM drive. So common issues may be better to be rearranged as: | 5.3.1.1. Common issues | | * Some older CD-ROM drives do not support reading from discs that were | burned at high speeds using a modern CD writer. | * Some older CD-ROM drives do not work correctly if “direct memory access” | (DMA) is enabled. | * If your system boots correctly from the CD-ROM, it does not necessarily | mean that Linux also supports the CD-ROM (or, more correctly, the | controller that your CD-ROM drive is connected to). I was wondering your use of "head -c" instad of "dd" with "count", but I guess that may be the busybox tool limitation. -- I hope thsi helps. Osamu
Bug#267168: after thought on patch
After thinking a bit more, I realized adding a bit more information
serves better for logging. Here is an updated patch which adds more
logging message in the fail function.
Osamu
--- cdrom-detect.postinst.orig 2006-10-09 19:31:46.0 +0900
+++ cdrom-detect.postinst 2006-10-09 22:21:28.0 +0900
@@ -9,7 +9,9 @@
}
fail () {
- log "CDROM-detect failed."
+ log "CDROM-detect failed: device=$device"
+ log "Unmounting CD just to be sure."
+ umount /cdrom 2>/dev/null || true
exit 1
}
@@ -38,21 +40,6 @@
mounted=1
db_set cdrom-detect/cdrom_device $device
break
- else
- log "CDROM-mount failed (error=$?): device=$device"
- log "Unmounting CD just to be sure."
- umount /cdrom 2>/dev/null || true
- log "Trying it again."
- if mount -t iso9660 -o ro,exec $device /cdrom; then
- log "CDROM-mount succeeded: device=$device"
- mounted=1
- db_set cdrom-detect/cdrom_device $device
- break
- else
- log "CDROM-mount failed again (error=$?):
device=$device"
- log "Unmounting CD just to be sure and giving
it up."
- umount /cdrom 2>/dev/null || true
- fi
fi
done
@@ -66,6 +53,8 @@
db_go
db_get cdrom-detect/retry
if [ "$RET" = "true" ]; then
+ log "Unmounting CD just to be sure."
+ umount /cdrom 2>/dev/null || true
continue
else
fail
@@ -116,9 +105,7 @@
mounted=1
break
else
- log "CDROM-mount failed (error=$?): device=$device"
- log "Unmounting CD just to be sure and giving it up."
- umount /cdrom 2>/dev/null || true
+ fail
fi
else
fail
@@ -130,10 +117,9 @@
log "Detected CD '$CDNAME'"
else
log "The available CD is not a Debian CD!"
- umount /cdrom
db_input critical cdrom-detect/wrong-cd || [ $? -eq 30 ]
db_go
- exit 1
+ fail
fi
# Get all the pool directories into the dentry cache, to cut down on seek
@@ -173,7 +159,6 @@
log "Error reading Release file; unable to determine distribution"
db_input critical cdrom-detect/no-release || [ $? -eq 30 ]
db_go
- umount /cdrom
fail
fi
Bug#267168: cdrom-detect: How about changing to wishlist bugs
Package: cdrom-detect
Version: 1.17
Followup-For: Bug #267168
This bug and its friends which are still there as nomal bugs are now
almost finished for me in etch beta 3 release.
I am taliking:
#247960, #258316, #259264, #262140, #265636, #267168, #314163
Also, the following bug may be merged to above list.
#284455
I think these can be changed to a single wishlist bug for documentation
request to mention faulty CDROM hardware issue now. If you document
this, this closes half the normal bugs for this package :-)
Wishlist content:
In "Chapter 5.3 Troubleshooting the Installation Process" right after
"5.3.1. Floppy Disk Reliability", I sugest to include following
| 5.3.2. CD-ROM Reliability
|
| In some older faulty CD-ROM drives, detecting and reading CD-ROM during
| the boot process may fail in various funny ways. This can be worked
| around simply by detecting CD-ROM again after the fasilure incident.
I also attach a patch which clean code around this failed CD-ROM detect
situation. This removes my old workaround and always use "fail"
function with "unmount" in it under "exit 1" situation for cleaner
consistency. I also think failing soon when manual detection failed is
the better way than looping to execute autodetection again. (untested
patch).
Here is the background and explanation:
Essentially, the issue was how to work around faulty hardware which
kernel has diffuculty handling by itself. After you have implimented
if [ -z "$suite" ]
test in this program, there is no bug by this program from my
perspective.
All we need to do is restart instaler from cdrom-detect phase.
Bad hardware should suffer a bit. So what :-)
Let me review previous history by my vague memory and explain what I am
talking.
When trying to install to a machine with old CD-ROM drive on my old DELL
machine and others, CDROM mounts fails in many funny ways.
The first trial of working around this isuue was retry mounting.
Then with newer kernel, it seems the mounting itself happens after
several kernel error messages but no error from mount command. The
mounted contents of CD-ROM are not right. I mean that symlinks shows up
as zero length normal files. This cause read failure in the
for distlink in stable testing unstable
loop as expected. This leaves $suite unset.
Since there is unmount before fail there now, we can rerun cdrom-detect
without problem. That was headiache in RC1 days.
If this patch is too intrusive to your taste, please do not apply this
now. Since SVN repo and 1.17 seems to be the same or just white space
difference, I made patch from unstable source.
I have not tested this patch with actual installer. I attach here only
to indicate my point and wishing this be considered at least for the
post-etch release. This patch is at least more current to SVN version
than the old ones on BTS.
I hope this helps.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-1-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
--
~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ +
Osamu Aoki <[EMAIL PROTECTED]> Yokohama Japan, GPG-key: A8061F32
.''`. Debian Reference: post-installation user's guide for non-developers
: :' : http://qref.sf.net and http://people.debian.org/~osamu
`. `' "Our Priorities are Our Users and Free Software" --- Social Contract
--- cdrom-detect.postinst.orig 2006-10-09 19:31:46.0 +0900
+++ cdrom-detect.postinst 2006-10-09 21:46:37.0 +0900
@@ -10,6 +10,8 @@
fail () {
log "CDROM-detect failed."
+ log "Unmounting CD just to be sure."
+ umount /cdrom 2>/dev/null || true
exit 1
}
@@ -38,21 +40,6 @@
mounted=1
db_set cdrom-detect/cdrom_device $device
break
- else
- log "CDROM-mount failed (error=$?): device=$device"
- log "Unmounting CD just to be sure."
- umount /cdrom 2>/dev/null || true
- log "Trying it again."
- if mount -t iso9660 -o ro,exec $device /cdrom; then
- log "CDROM-mount succeeded: device=$device"
- mounted=1
- db_set cdrom-detect/cdrom_device $device
- break
- else
- log "CDROM-mount failed again (error=$?):
device=$device"
- log "Unmounting CD just to be sure and giving
it up."
-
Horrible performance: hdparm
Hi, On Sat, Jul 08, 2006 at 06:10:37PM -0400, Joey Hess wrote: > Rich Johnson wrote: > > Judging from the lackadaisical disk LED activity, I doubt it's the disk. > > Disk issues can lead to apparently low disk activity in some situations, > and it's the first thing I'd check: Make sure that DMA is on, make sure > that hdparm is optimally tuned, etc. > > -- > see shy jo If installation guru has to tell this, is not it time to make this as default? We have written out 386 machines. It may be a time to assume decent DMA support (Of couse with some boot option to disable it just in case.) What does people feel to make hdparm with DMA enabled to be default for etch? Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
http://www.debian.org/devel/debian-installer/svn contents
Hi, Question: Alioth README seems newer and correct for anonymous SVN checkout. Should I update Debian web site description? Background: I was wondering why I can not check out from SVN repository while others seems to have no issues. I was following Debian web page: http://www.debian.org/devel/debian-installer/svn This recommends: $ svn co svn://svn.debian.org:3691/d-i/trunk debian-installer I get svn: Can't connect to host 'svn.debian.org': Connection refused Then I checked README from August: http://svn.debian.org/viewcvs/d-i/trunk/README?view=markup&rev=20280 This recommends $ svn co svn://svn.debian.org/d-i/trunk d-i ... This worked. $ cvs ann svn.wml Annotations for svn.wml *** 1.1 (joeyh21-Mar-04): #use wml::debian::template title="Debian-Inst aller subversion Repository" 1.1 (joeyh21-Mar-04): #use wml::debian::recent_list 1.1 (joeyh21-Mar-04): 1.1 (joeyh21-Mar-04): 1.7 (kraai01-Jul-04): Debian-Installer uses subversion for source c ontrol. To check out the 1.7 (kraai01-Jul-04): installer use one of the commands below. 1.1 (joeyh21-Mar-04): 1.1 (joeyh21-Mar-04): 1.1 (joeyh21-Mar-04): Anonymous checkout 1.1 (joeyh21-Mar-04): 1.6 (tbm 16-May-04): svn co svn://svn.debian.org :3691/d-i/trunk debian-installer 1.1 (joeyh21-Mar-04): 1.1 (joeyh21-Mar-04): Checkout over ssh, for developers 1.1 (joeyh21-Mar-04): 1.3 (kubota 21-Mar-04): svn co svn+ssh://$user id@svn.debian.org/svn/d-i/trunk debian-installer 1.1 (joeyh21-Mar-04): (replace $userid with your http://alioth.debian.org";>Alioth user ID) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#267227: Minor efficiency improvement for scsi device search
reopen 267227 thanks Hi, (aside from my initial non-optimal code which misses USB-floppy which I do not have...) I think I was not verbose enough to point out the issues in the code first. The following are shell interaction record during RC1 booting process on my system where no floppy disk exists and USB memory key device is plugged in: ~ # echo /dev/floppy/? /dev/floppy/? ~ # find /dev/scsi /dev/scsi /dev/scsi/host0 /dev/scsi/host0/bus0 /dev/scsi/host0/bus0/target0 /dev/scsi/host0/bus0/target0/lun0 /dev/scsi/host0/bus0/target0/lun0/disc /dev/scsi/host0/bus0/target0/lun0/part1 ~ # Code is optimized not to look all the possible scsi devices but still has some useless devices listed, as I saw and played in the shell as above. After a while I also thought about possibility of USB floppy too and used following commanads to find he devices to store log with my version of bugreporter-udeb. ~ # find /dev/floppy -type b ~ # find /dev/scsi -type b /dev/scsi/host0/bus0/target0/lun0/disc /dev/scsi/host0/bus0/target0/lun0/part1 ~ # I think advantage of "find /dev/floppy -type b" over "echo /dev/floppy/?" is small but latter is good idea since we invoke "find" anyway. I did check udeb version of "find" having -type support as I indicated above. If mounting these entries like "/dev/floppy/?" and "/dev/scsi" was intentional KISS, please close this report again. On Fri, Aug 27, 2004 at 12:30:44PM -0400, Joey Hess wrote: > Osamu Aoki wrote: > > When playing with bugreporter-udeb, I had a good look at init code > > in this package's src-bootfloppy directory. > > > > find /dev/scsi > > > > This list many useless entries. Assuming no one wish to use partition > > after part9, changing above with > > > > find /dev/scsi -name 'part?'||true > > > > may improve code. (Or I should say, I did so in bugreporter-udeb.) > > > > Does this make sense or it is bad idea. If bad tell me so. Then I will > > fix bugreporter-udeb patch too. > > This won't work because floppies rarely have partitions on them at all. > Also, KISS applies. And since devfs only creates part* entries for > existing partitions, the code is already optimised. I overlooked USB floppy. > (I'd suggest testing code before sending in patches.) Sorry, I may have given impression like this but this is not the case for this one. I will be careful, though. Cheers, Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#267168: ohci1394 on Ricoh Co Ltd R5C552 with 2.4 kernel
On Fri, Aug 27, 2004 at 12:20:43PM -0400, Joey Hess wrote: > Osamu Aoki wrote: > > Hi, > > > > On Thu, Aug 26, 2004 at 02:54:18PM -0400, Joey Hess wrote: > > > Osamu Aoki wrote: > > > > Key points: > > > > * Successful cdrom-detect (w/ osamu fix) in normal IDE case. > > > > * Funny "modprobe -v ohci1394" message Aug 20 22:22:40 > > > > hw-detect: Detected module 'ohci1394' for 'Ricoh Co Ltd R5C552 > > > > IEEE 1394 Controller' > > > > > > > > The real module name is ochi1394. "h" <--> "c" > > > > > > The installer gets the module name right. > > > > Aha,.. so just message string is wrong? > > I'm sorry, but the only place I see the incorrect "ochi1394" is in > text you wrote above. "ohci1394" is correct, and is used by the > installer. Yes. You are correct. (Somehow I thought pop-up mesage said ochi1394 and I took note but as I double checked now, I must have been dreaming...) As you ponted out this seems kernel problem. Moreover, it seems this is a specific problem on 2.4 kernel. I do not see this problem booting with kernel 2.6 using expert26. The same was the case on my installed system with 2.4 and 2.6 kernels. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#265612: cdrom-detect: can we commit to svn?
Hi, Let's commit at least to svn for cdrom-detect. Vincent tested couple times with both latest code of cdrom-detect. How do I get svn write access to d-i? Should I send patch / file instead? My alioth account is "osamu" as you know. Can you add me to the group? Then we can test this more throughly. Handhacking CD image is not so easy and error prone. Oh, if possible, let's upload updated package after few days. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#267219: Bug to USB stick works !
Hi,
On Sun, Aug 22, 2004 at 01:07:08PM +0200, Osamu Aoki wrote:
> Here is the latest stable code for bugreporter-udeb.postinst with
> $REPORT_MEDIA_DEV support.
:-( Now I know why REPORT_MEDIA_DEV=nofloppy boot parameter did not
work. Because code was buggy just for this feature.
I changed it again and worked without exporting these with other
packages. Looks like all of these are exported. Nice.
Now you can store log to not only to normal floppy but also to
* USB memory stick
* USB HDD
* USB floppy
* IDE HDD
* IDE ZIP
* etc.
as long as there is a vfat partition.
Osamu
#!/bin/sh -e
. /usr/share/debconf/confmodule
log() {
logger -t bugreporter-udeb -p user.debug "$@"
}
# REPORT_MEDIA_DEV can be set to use non auto detected devices for report
NO_FLOPPY=0
if [ -n "$REPORT_MEDIA_DEV" ]; then
if [ "$REPORT_MEDIA_DEV" = "nofloppy" ]; then
NO_FLOPPY=1
DEVS=""
log "Do not search floppy devices"
else
DEVS="$REPORT_MEDIA_DEV"
log "Search a device from $REPORT_MEDIA_DEV"
fi
else
DEVS=""
fi
if [ "" = "$DILOGDIR" ]; then
DILOGDIR=/var/log/
fi
# make sure we have a directory
if [ ! -d $DILOGDIR ]; then
mkdir -p $DILOGDIR
fi
copy_cdebconf_db() {
destdir="$1"
# Save database to disk
# kill -?
cp -a /var/lib/cdebconf "$destdir"
}
db_input critical bugreporter-udeb/insert_floppy || [ $? -eq 30 ]
db_go
log "Genarate files with HW info, debconf database info etc. into $DILOGDIR"
db_progress START 0 7 debian-installer/bugreporter-udeb/title
/bin/package-versions > $DILOGDIR/package-versions
db_progress STEP 1
/bin/report-hw > $DILOGDIR/hardware-summary
db_progress STEP 1
# Idea from rootskel/src-bootfloppy. [2004-08-20]
mountfloppy() {
# Try mounting USB memory devices (how about firewire?)
if [ -x /usr/sbin/usb-discover ]; then
/usr/sbin/usb-discover
fi
# This is currently needed or usb-storage won't load (for ide_fix_driveid).
modprobe ide-core >/dev/null
modprobe usb-storage >/dev/null
modprobe sd_mod >/dev/null
log "Required modules activated."
if [ "$DEVS" = "" ]; then
# Find possible block devices on floppy
if [ -d /dev/floppy ] && [ "$NO_FLOPPY" = "0" ]; then
DEVS="$DEVS `find /dev/floppy -type b -name '?' || true`"
fi
# Find possible block devices on scsi (including USB floppy and stick)
if [ -d /dev/scsi ]; then
DEVS="$DEVS `find /dev/scsi -type b || true`"
#DEVS="$DEVS `find /dev/scsi -type b \( -name 'part*' -o -name '?' \)
||true`"
fi
fi
log "Devices found: $DEVS"
db_progress STEP 1
# Mount first vfat block device on /floppy even if USB storage.
MOUNTED=0
for dev in $DEVS; do
if [ -b "$dev" ] && mount $dev -o rw -tvfat /floppy 2>/dev/null; then
MOUNTED=1
break
else
log "This can not be mounted as vfat, rw: $dev"
umount /floppy 2>/dev/null || true
fi
done
if [ "$MOUNTED" = 0 ]; then
exit 1
fi
log "On /floppy, mounted a vfat/rw/block device: $dev"
return 0
}
if [ -d /floppy ]; then
umount /floppy 2>/dev/null || true
else
mkdir /floppy
fi
# Find a floppy or USB storage and mount it on /floppy
if mountfloppy ; then
db_progress STEP 1
# Let's try to save many several install logs.
for i in 00 01 02 03 04 05 06 07 08 09 \
10 11 12 13 14 15 16 17 18 19 \
20 21 22 23 24 25 26 27 28 29 END ; do
if [ "$i" = "END" ] ; then
log "No space in the storage media."
exit 1
fi
LOGDIR=debian${i}
if [ ! -e "/floppy/$LOGDIR" ] ; then
log "Found an unused directory name: $LOGDIR"
break
fi
done
db_progress STEP 1
log "Save d-i install logs to $LOGDIR"
mkdir /floppy/$LOGDIR
for file in \
/var/log/messages \
/var/log/syslog \
/var/log/partman \
$DILOGDIR/hardware-summary \
$DILOGDIR/package-versions; do
if [ -e $file ]; then
cp $file /floppy/$LOGDIR/
fi
done
db_progress STEP 1
umount /floppy 2>/dev/null || true
db_progress STEP 1
db_progress STOP
else
db_progress STEP 4
db_progress STOP
db_input critical bugreporter-udeb/no_floppy || [ $? -eq 30 ]
db_go
fi
Bug#267168: modprobe -v ohci1394 message, (successful RC1-osamu)
Hi, On Thu, Aug 26, 2004 at 02:54:18PM -0400, Joey Hess wrote: > Osamu Aoki wrote: > > Key points: > > * Successful cdrom-detect (w/ osamu fix) in normal IDE case. > > * Funny "modprobe -v ohci1394" message > > Aug 20 22:22:40 hw-detect: Detected module 'ohci1394' for 'Ricoh Co Ltd R5C552 > > IEEE 1394 Controller' > > > > The real module name is ochi1394. "h" <--> "c" > > The installer gets the module name right. Aha,.. so just message string is wrong? > [EMAIL PROTECTED]:/lib/modules/2.4.26-1-386>find |grep ohci1394 > ./kernel/drivers/ieee1394/ohci1394.o > [EMAIL PROTECTED]:/lib/modules/2.4.26-1-386>find |grep ochi1394 > zsh: done find | > > > :02:05.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller > > > Aug 20 22:22:40 hw-detect: Detected module 'ohci1394' for 'Ricoh Co Ltd R5C552 > > IEEE 1394 Controller' > > Aug 20 22:22:40 hw-detect: Trying to load module 'ohci1394' > > Aug 20 22:22:41 kernel: ohci1394: $Rev: 1045 $ Ben Collins <[EMAIL PROTECTED]> > > Aug 20 22:22:41 kernel: PCI: No IRQ known for interrupt pin C of device 02:05.2. > > Please try using pci=biosirq. > > Aug 20 22:22:41 kernel: ohci1394: Failed to allocate shared interrupt 0 > > Aug 20 22:22:41 hw-detect: Error loading 'ohci1394' > > > insmod: init_module: ohci1394: No such device > > insmodieee1394 > > insmodohci1394 > > modprobe: failed to load module ohci1394 > > You seem to have a firewire controller that the kernel does not > recognise. OK, here is my lspci/lspci -n :00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge (rev 04) :00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge (rev 04) :00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #1) (rev 02) :00:1d.1 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #2) (rev 02) :00:1d.2 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #3) (rev 02) :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 42) :00:1f.0 ISA bridge: Intel Corp. 82801CAM ISA Bridge (LPC) (rev 02) :00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02) :00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus Controller (rev 02) :00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97 Audio Controller (rev 02) :00:1f.6 Modem: Intel Corp. 82801CA/CAM AC'97 Modem Controller (rev 02) :01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] :02:05.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev a8) :02:05.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev a8) :02:05.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller :02:08.0 Ethernet controller: Intel Corp. 82801CAM (ICH3) PRO/100 VE (LOM) Ethernet Controller (rev 42) :00:00.0 0600: 8086:1a30 (rev 04) :00:01.0 0604: 8086:1a31 (rev 04) :00:1d.0 0c03: 8086:2482 (rev 02) :00:1d.1 0c03: 8086:2484 (rev 02) :00:1d.2 0c03: 8086:2487 (rev 02) :00:1e.0 0604: 8086:2448 (rev 42) :00:1f.0 0601: 8086:248c (rev 02) :00:1f.1 0101: 8086:248a (rev 02) :00:1f.3 0c05: 8086:2483 (rev 02) :00:1f.5 0401: 8086:2485 (rev 02) :00:1f.6 0703: 8086:2486 (rev 02) :01:00.0 0300: 1002:4c57 :02:05.0 0607: 1180:0476 (rev a8) :02:05.1 0607: 1180:0476 (rev a8) :02:05.2 0c00: 1180:0552 :02:08.0 0200: 8086:1031 (rev 42) Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#265612: cdrom-detect patch explanation (osamu)
On Wed, Aug 25, 2004 at 11:17:55PM +1000, Vincent McIntyre wrote: > Hello Osamu > > attached are another round of tests, using > http://people.debian.org/~osamu/pub/sarge-i386-netinst-bug.iso, > md5 f01dbaea95c0d8627951ab788c56e3d3 > > The hardware is the same d600 and cpia laptops as my previous tests. > > The cdrom drive detection succeeded. > It takes seems to take a long time in kernel 2.6, but does work > in the end. 2.6 kernel get different initrd which I did not change. So at least my latest script works on 2.4 kernel. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#265612: cdrom-detect patch explanation (osamu)
On Tue, Aug 24, 2004 at 07:24:47AM +1000, Vincent McIntyre wrote: > > Thanks. Just to be sure, can you veryfy the version? > > following output is a good start. > > > > grep -e "bugreporter-udeb.*udeb" < md5sum.txt > 7e7842077197b6936ed6be2b500b2df3 > ./pool/main/b/bugreporter-udeb/bugreporter-udeb_0.28_all.udeb [EMAIL PROTECTED]:cd-image$ grep reporter-udeb http://people.debian.org/~osamu/pub/ sarge-i386-netinst-bug.iso This one is the best which has Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#265612: cdrom-detect patch explanation (osamu)
On Mon, Aug 23, 2004 at 10:22:19PM +1000, Vincent McIntyre wrote: > tests with kernel 2.6: > > dell latitude d600 - cdrom detection ok > > dell lattude cpia - cdrom detection ok > > details in the tarball attached Thanks. Just to be sure, can you veryfy the version? following output is a good start. grep -e "bugreporter-udeb.*udeb" < md5sum.txt Also, I only hacked kernel 2.4 version of initrd so I do not think anything changed for 2.6. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#267531: Laptop freezes completely with further notice
Hi, On Mon, Aug 23, 2004 at 09:44:54AM +0200, Pablo de Vicente wrote: > cdimage-testing/sarge_d-i/i386/beta4/sarge-i386-netinst.iso) > uname -a: 2.6.5-1-386 > Date: 23-8-2004 > Method: Installation from a CD > > Machine: Dell D800 ^^ > Detecting hardware to find CD-ROM drives > Then a progress bar at 96 % > Starting PC Card services Can you try my modified RC1? This iso image has bug report to USB key feature and my cdrom-detect at: http://people.debian.org/~osamu/pub/ and use: sarge-i386-netinst-bug.iso new bugreport to floppy and USB with cdrom-detect fix Also try booting with not only linux but also expert mode too. Have fun. Osamu signature.asc Description: Digital signature
Errata page update, can I do this?
Hi, Here is my thought on errata page update/addition for RC1: * IDE CDROM: If normal IDE CDROM fails to mount CD automatically, go to console and umount /cdrom before running menu again. * Firewire CDROM: If firewire CDROM fails to mount CD automatically, boot with either "expert" or "expert26" and run followings before detect and mounting CDROM: modprobe ohci1394 modprobe sbp2 modprobe sr_mod * SSH: SSH is broken. (because libutil.so.1 is not installed anywhere.) -- I think all these have known solutions. What is the rule for updating this page. (I can but I have never touched this page.) Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#267410: discover1-data: Support Sony Vaio PCG-R505 Firewire CD
Package: discover1-data
Version: 1.2004.07.25 (One used in d-i RC1)
Severity: normal
Auto detection of harddisk fails for my sony PC. This has firewire
CDROM. My lspci;lspci -n are below.
---
Work around used for install:
1. Boot with expert
2. Go to console run following before detect and mount CDROM:
modprobe ohci1394
modprobe sbp2
modprobe sr_mod
Before you detect and mount CDROM, you may also want to change debconf
prioriy to medium or so.
HW data:
:00:00.0 Host bridge: Intel Corp. 82815 815 Chipset Host Bridge and Memory
Controller Hub (rev 11)
:00:02.0 VGA compatible controller: Intel Corp. 82815 CGC [Chipset Graphics
Controller] (rev 11)
:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 03)
:00:1f.0 ISA bridge: Intel Corp. 82801BAM ISA Bridge (LPC) (rev 03)
:00:1f.1 IDE interface: Intel Corp. 82801BAM IDE U100 (rev 03)
:00:1f.2 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #1) (rev 03)
:00:1f.3 SMBus: Intel Corp. 82801BA/BAM SMBus (rev 03)
:00:1f.4 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #2) (rev 03)
:00:1f.5 Multimedia audio controller: Intel Corp. 82801BA/BAM AC'97 Audio (rev 03)
:00:1f.6 Modem: Intel Corp. Intel 537 [82801BA/BAM AC'97 Modem] (rev 03)
:01:00.0 FireWire (IEEE 1394): Texas Instruments TSB43AA22 IEEE-1394 Controller
(PHY/Link Integrated) (rev 02)
:01:02.0 CardBus bridge: Ricoh Co Ltd RL5c475 (rev 80)
:01:08.0 Ethernet controller: Intel Corp. 82801BA/BAM/CA/CAM Ethernet Controller
(rev 03)
:00:00.0 0600: 8086:1130 (rev 11)
:00:02.0 0300: 8086:1132 (rev 11)
:00:1e.0 0604: 8086:2448 (rev 03)
:00:1f.0 0601: 8086:244c (rev 03)
:00:1f.1 0101: 8086:244a (rev 03)
:00:1f.2 0c03: 8086:2442 (rev 03)
:00:1f.3 0c05: 8086:2443 (rev 03)
:00:1f.4 0c03: 8086:2444 (rev 03)
:00:1f.5 0401: 8086:2445 (rev 03)
:00:1f.6 0703: 8086:2446 (rev 03)
:01:00.0 0c00: 104c:8021 (rev 02)
:01:02.0 0607: 1180:0475 (rev 80)
:01:08.0 0200: 8086:2449 (rev 03)
--
~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ +
Osamu Aoki <[EMAIL PROTECTED]> Brussels Belgium, GPG-key: A8061F32
.''`. Debian Reference: post-installation user's guide for non-developers
: :' : http://qref.sf.net and http://people.debian.org/~osamu
`. `' "Our Priorities are Our Users and Free Software" --- Social Contract
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#267168: Successful cdrom-detect (minimum impact patch)
Hi, FYI: The minimum impact patch can be found as attachment to my bug report to #265636 (Now merged with this bug number). You need to remove 2 commented out lines to get quiet and smooth install. So instead of: +# For some buggy CDROM drive, blindly mount and umount +# CDROM will avoid DMA issues with kernel. +#mount -t iso9660 -o ro,exec $device /cdrom || true +#umount /cdrom 2>/dev/null || true Do this. +# For some buggy CDROM drive, blindly mount and umount +# CDROM will avoid DMA issues with kernel. +mount -t iso9660 -o ro,exec $device /cdrom || true +umount /cdrom 2>/dev/null || true Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#267219: Bug to USB stick works !
Here is the latest stable code for bugreporter-udeb.postinst with
$REPORT_MEDIA_DEV support.
On Sun, Aug 22, 2004 at 04:13:11AM +0200, Osamu Aoki wrote:
>
> Please check test iso image which has USB bug report and my
> cdrom-detect at:
> http://people.debian.org/~osamu/pub/
> and use:
> sarge-i386-netinst-bug.iso new bugreport to floppy and USB
>with cdrom-detect fix
#!/bin/sh -e
. /usr/share/debconf/confmodule
log() {
logger -t bugreporter-udeb -p user.debug "$@"
}
# REPORT_MEDIA_DEV can be set to use non auto detected devices for report
NO_FLOPPY=0
if [ -n "$REPORT_MEDIA_DEV" ]; then
DEVS="$REPORT_MEDIA_DEV"
else
DEVS=""
if [ "$REPORT_MEDIA_DEV" = "nofloppy" ]; then
NO_FLOPPY=1
fi
fi
if [ "" = "$DILOGDIR" ]; then
DILOGDIR=/var/log/
fi
# make sure we have a directory
if [ ! -d $DILOGDIR ]; then
mkdir -p $DILOGDIR
fi
copy_cdebconf_db() {
destdir="$1"
# Save database to disk
# kill -?
cp -a /var/lib/cdebconf "$destdir"
}
db_input critical bugreporter-udeb/insert_floppy || [ $? -eq 30 ]
db_go
log "Genarate files with HW info, debconf database info etc. into $DILOGDIR"
db_progress START 0 7 debian-installer/bugreporter-udeb/title
/bin/package-versions > $DILOGDIR/package-versions
db_progress STEP 1
/bin/report-hw > $DILOGDIR/hardware-summary
db_progress STEP 1
# Idea from rootskel/src-bootfloppy. [2004-08-20]
mountfloppy() {
# Try mounting USB memory devices (how about firewire?)
if [ -x /usr/sbin/usb-discover ]; then
/usr/sbin/usb-discover
fi
# This is currently needed or usb-storage won't load (for ide_fix_driveid).
modprobe ide-core >/dev/null
modprobe usb-storage >/dev/null
modprobe sd_mod >/dev/null
log "Required modules activated."
if [ "$DEVS" = "" ]; then
# Find possible block devices on floppy
if [ -d /dev/floppy ] && [ "$NO_FLOPPY" = "0" ]; then
DEVS="$DEVS `find /dev/floppy -type b -name '?' || true`"
fi
# Find possible block devices on scsi (including USB floppy and stick)
if [ -d /dev/scsi ]; then
DEVS="$DEVS `find /dev/scsi -type b || true`"
#DEVS="$DEVS `find /dev/scsi -type b \( -name 'part*' -o -name '?' \)
||true`"
fi
fi
log "Devices found: $DEVS"
db_progress STEP 1
# Mount first vfat block device on /floppy even if USB storage.
MOUNTED=0
for dev in $DEVS; do
if [ -b "$dev" ] && mount $dev -o rw -tvfat /floppy 2>/dev/null; then
MOUNTED=1
break
else
log "This can not be mounted as vfat, rw: $dev"
umount /floppy 2>/dev/null || true
fi
done
if [ "$MOUNTED" = 0 ]; then
exit 1
fi
log "On /floppy, mounted a vfat/rw/block device: $dev"
return 0
}
if [ -d /floppy ]; then
umount /floppy 2>/dev/null || true
else
mkdir /floppy
fi
# Find a floppy or USB storage and mount it on /floppy
if mountfloppy ; then
db_progress STEP 1
# Let's try to save many several install logs.
for i in 00 01 02 03 04 05 06 07 08 09 \
10 11 12 13 14 15 16 17 18 19 \
20 21 22 23 24 25 26 27 28 29 END ; do
if [ "$i" = "END" ] ; then
log "No space in the storage media."
exit 1
fi
LOGDIR=debian${i}
if [ ! -e "/floppy/$LOGDIR" ] ; then
log "Found an unused directory name: $LOGDIR"
break
fi
done
db_progress STEP 1
log "Save d-i install logs to $LOGDIR"
mkdir /floppy/$LOGDIR
for file in \
/var/log/messages \
/var/log/syslog \
/var/log/partman \
$DILOGDIR/hardware-summary \
$DILOGDIR/package-versions; do
if [ -e $file ]; then
cp $file /floppy/$LOGDIR/
fi
done
db_progress STEP 1
umount /floppy 2>/dev/null || true
db_progress STEP 1
db_progress STOP
else
db_progress STEP 4
db_progress STOP
db_input critical bugreporter-udeb/no_floppy || [ $? -eq 30 ]
db_go
fi
signature.asc
Description: Digital signature
Re: firewire CD install
Hi, thanks Christian On Fri, Aug 20, 2004 at 11:57:59PM +0200, Osamu Aoki wrote: > On Thu, Aug 19, 2004 at 10:57:31PM +0200, Christian Perrier wrote: > > Quoting Osamu Aoki ([EMAIL PROTECTED]): > > > I have PC with firewire CDROM. ... > Hmmm. only these 2 do not detect it. I again modprobed all these: > I may have been tired... It works by douing following. I must have typed wrong. modprobe ohci1394 modprobe sbp2 modprobe sr_mod > > echo "scsi add-single-device 0 0 0 0" > /proc/scsi/scsi This was not needed since it is run by the script. Anyway, I filed bug report with lspci;lspci -n to discover1-data Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Question: Code update schedule, RC2 due date, etc.
Hi, I am wondering d-i code/package/RC2 update schedule (I know alioth is down now.) in light of following situation: cdrom-detect: There are few working options to solve DMA related instability. (debian/cdrom-detect.postinst is changed) 1) My old patch with dummy mount (small impact patch but not beautiful) 2) My new patch with completely reshuffled codes (major rewrite) I hope one of them should be deployed for RC2. Please tell me which one can be considered. Considering risks, I will not be surprised if you want to take simpler patch. But I like latter. bugreporter-udeb: I have done major overhaul and I verified it to work nicely. (debian/bugreporter-udeb.postinst is changed) Features: * USB stick (or any scsi vfat devices) can be used if vfat floppy is not available. * Now logs and hardware information are written under a new subdirectory and it does not overwrite previous reports any more. * This should fix 2 normal bugs: - #220306: cannot find usb floppy drives, etc - #221575: doesn't support USB floppy - I think even USB HDD may be used if it has vfat partition. * If bugreporter-udeb can get $REPORT_MEDIA_DEV exported from boot prompt parameters[*], we can skip slow (150 sec.) floppy check and go directly to USB key. Or you can specify exact devfs name on which you want the installation reports are written. (You need to format it as MSDOS vfat.) If we want to get decent bug report from problematic laptop PCs, I think this is very important one. I have seen many new laptop comes without floppy drive recently. Asking user to use SSH is not as easy as plugging USB storage devices such as vfat formatted USB stick. Since there is not much looping, I think code is quite stable now. I really want this to be in RC2. I have made functioning iso image (cdrom-detect option 2 + bugreporter): http://people.debian.org/~osamu/pub/ sarge-i386-netinst-bug.iso (I am overwriting above with latest $REPORT_MEDIA_DEV containing code. It will take 2 hours to upload now.) It was a nice weekend :-) Cheers, Osamu * Which package do we need to change to do this. cdrom-detect also has similar feature adjustment by environment. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#267219: Bug to USB stick works !
Hi, good news. Bug to USB stick works ! so does flakey CDROM works :-) My concept code has been debuged and working. I did some code cleaning so auto detected device nasme can be identified in the log in case it does not work. This should allow people to use any vfat formated USB device or normal floppy to be used for storing log and bug report. Please check test iso image which has USB bug report and my cdrom-detect at: http://people.debian.org/~osamu/pub/ and use: sarge-i386-netinst-bug.iso new bugreport to floppy and USB with cdrom-detect fix there is still: sarge-i386-netinst-hacked.iso old cdrom-detect fix only The only negative is if you do not have floppy, it is very slow to know it. It is defenately debconf question for etch but for now this gives exta option. Also logging is nicer too. Since string freeze exist, no text change done. Maybe I should add some way to disable floppy probing... But so much for tonight. > PPS: I guess I need to update Release file in CD too to get it working. > But what else is needed to replace udeb in netinst CD? Package Package.gz Release md5sum.txt I have semi automatic Makefile :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
"Change debconf priority" position in menu, why?
Hi, Why "Change debconf priority" in the menu is so low. Why not on the top (or at least before "detect and mount CD-ROM")? Then expert mode will be more natural. People should feel not asked too much by choosing medium in earlier time even if they do not know. Any previous discussion on this? As discussed many times, people who choose 'expert" are not d-i expert :-) Changing menu order seems least impact way to address this problem. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#267168: cdrom-detect patch explanation (osamu)
Hi,
Since my patch was not so simple but practically complete shuffle of
shell script, let me explain for the record.
Basically, old postinst script for cdrom-detect had scattered codes
failed CD mounting/umounting CD handling.
My patch send to this bug number reorders shell code to clean up this
situation with few things in mind.
Always exit with CD mounted when exit 0
Always exit with CD umounted when exit 1.
If mount error occurs, provide 2nd mount action.
(For DMA error, 2nd mount is successful if properly umounted after
initial try.)
First part of loop is long but the use of "continue" always returns
here and it makes consistenthandling within while-true-do-done loop
possible.
Osamu
--
~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ +
Osamu Aoki <[EMAIL PROTECTED]> Brussels Belgium, GPG-key: A8061F32
.''`. Debian Reference: post-installation user's guide for non-developers
: :' : http://qref.sf.net and http://people.debian.org/~osamu
`. `' "Our Priorities are Our Users and Free Software" --- Social Contract
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#267227: Minor efficiency improvement for scsi device search
Package: rootskel Version: 0.79 Severity: wishlist Tags: patch Hi, When playing with bugreporter-udeb, I had a good look at init code in this package's src-bootfloppy directory. find /dev/scsi This list many useless entries. Assuming no one wish to use partition after part9, changing above with find /dev/scsi -name 'part?'||true may improve code. (Or I should say, I did so in bugreporter-udeb.) Does this make sense or it is bad idea. If bad tell me so. Then I will fix bugreporter-udeb patch too. Osamu --- init.org2004-08-21 11:08:22.0 +0200 +++ init2004-08-21 11:09:51.0 +0200 @@ -96,7 +96,7 @@ DEVS=/dev/floppy/? fi if [ -d /dev/scsi ]; then - DEVS="$DEVS `find /dev/scsi`" + DEVS="$DEVS `find /dev/scsi -name 'part?' || true`" fi else DEVS="`find $INSTALL_MEDIA_DEV`"
Bug#267168: Successful cdrom-detect (w/ osamu fix)
tags 267168 patch
thanks
Since I posted many buggy codes :-( , I post the working one here.
(The bottom of BTS for cdrom-detect.)
This should solve most of cdrom-detect bug reports :-)
I reported success for Dell DMA case on 265636 using this patch.
Osamu
#! /bin/sh
set -e
. /usr/share/debconf/confmodule
#set -x
log() {
logger -t cdrom-detect "$@"
}
fail () {
log "$@"
db_input critical cdrom-detect/failure || [ $? -eq 30 ]
db_go
# redundant but to be sure
umount /cdrom 2>/dev/null || true
exit 1
}
hw-detect cdrom-detect/detect_progress_title || true
maxmount=2 # max counts of the mounting tries
imount=0# mount counter
mounted=0 # 0=initial, 1=detection in progress, 2=mounted
while true
do
log "Searching for Debian installation media..."
if [ ! -e /cdrom ] ; then
mkdir /cdrom 2>/dev/null || true
elif [ "$mounted" = "1" ]; then
log "Cdrom device was detected but the mount failed."
db_input critical cdrom-detect/retry || [ $? -eq 30 ]
db_go
db_get cdrom-detect/retry
if [ "$RET" = "true" ]; then
mounted=0
continue
else
fail "Retry of cdrom detect refused."
fi
elif [ -e /cdrom/.disk/info ] ; then
log "Sanity check of CD before aproving mounted CD"
CDNAME=`cat /cdrom/.disk/info`
log "Detected CD '$CDNAME'"
# Set the suite used by base-installer and base-config to
# the suite that is on the CD from Release file.
for distlink in stable testing unstable ; do
relfile=/cdrom/dists/$distlink/Release
if [ -e $relfile ] ; then
suite=$(sed -n 's/^Suite: *//p' $relfile)
log "Detected CD with '$suite' distribution"
db_set mirror/suite $suite
break
fi
done
# For DMA related mount errors. (RR extension)
if [ "X" = "X${suite}" ]; then
log "Could not determine the package 'suite'. Is the cdrom OK?"
umount /cdrom 2>/dev/null || true
mounted=1
continue
elif [ ! -e "/cdrom/dists/$suite/Release" ]; then
log "No such file '/cdrom/dists/$suite/Release'. Is the cdrom OK?"
umount /cdrom 2>/dev/null || true
mounted=1
continue
fi
log "Exit main loop after approving mounted CD."
break
elif mount | grep -q 'on /cdrom ' ; then
log "The available CD is not a Debian CD!"
umount /cdrom 2>/dev/null || true
db_input critical cdrom-detect/wrong-cd || [ $? -eq 30 ]
db_go
imount=$((${imount}-1))
mounted=0
continue
fi
# Start detecting and mounting cdrom
if [ "$imount" -ge "$maxmount" ] ; then
fail "Tried to mount media $imount times and failed."
fi
imount=$((${imount}+1))
log "Loop $imount out of $maxmount"
mounted=1
log "Try to detect a cdrom automatically by devfs."
# This cdrom detection can be disabled by CDROM_DEVICES=none
if [ -n "$CDROM_DEVICES" ]; then
devices="$CDROM_DEVICES"
elif [ -d /dev/cdroms ]; then
devices=$(echo /dev/cdroms/*|grep -Fv '*' || true)
else
devices=""
fi
if [ -n "$devices" ] && [ "$devices" != "none" ]; then
for device in $devices
do
if mount -t iso9660 -o ro,exec $device /cdrom; then
log "Cdrom-mount succeeded: device=$device"
mounted=2
db_set cdrom-detect/cdrom_device $device
break # for device loop
else
log "Cdrom-mount failed (error=$?): device=$device"
umount /cdrom 2>/dev/null || true
mounted=0
fi
done
continue
fi
log "Try to mount a driver floppy since no auto-cdrom device found."
if [ -e /usr/lib/debian-installer/retriever/floppy-retriever ]; then
db_input critical cdrom-detect/load_floppy
db_go
db_get cdrom-detect/load_floppy
if [ "$RET" = true ]; then
anna floppy-retriever
hw-detect cdrom-detect/detect_progress_title || true
imount=$((${imount}-1))
mounted=2
continue
fi
fi
log "Try to mount a cdrom on old non-devfs hardwares manually."
db_input critical cdrom-detect/manual_config || [ $? -eq 30 ]
db_go
db_get cdrom-detect/manual_config
modules=none
for i in `ls -1 /lib/modules/*/kernel/drivers/cdrom/ | sed 's/\.ko$//' | sed
's/\.o$//'`
do
modules="$modules, $i"
done
if [ "$RET" = "true" ]; then
db_subst cdrom-detect/cdrom_module choices "$modules"
db_input critical cdrom-detect/cdrom_module || [ $? -eq 30 ]
db_go
db_get cdrom-detect/cdrom_module
module="$RET"
db_input critical cdrom-detect/cdrom_d
Bug#258316: cdrom-detect DMA issues: fixed image available.
Hi, I have made a new modified RC1 netinst image which should fix all DMA related issues when mounted CD has some flakey conditions. RC1 it self had some fix, but this is even better. http://people.debian.org/~osamu/pub/ Then download sarge-i386-netinst-hacked.iso Does this fix problem? Can I merge this bug with: Bug#265636: dma issues cause cdrom mount error -- ~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ + Osamu Aoki <[EMAIL PROTECTED]> Brussels Belgium, GPG-key: A8061F32 .''`. Debian Reference: post-installation user's guide for non-developers : :' : http://qref.sf.net and http://people.debian.org/~osamu `. `' "Our Priorities are Our Users and Free Software" --- Social Contract -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#265612: cdrom-detect DMA issues: fixed image available.
Hi, (Sorry to debian-boot) I have made a new modified RC1 netinst image which should fix all DMA related issues when mounted CD has some flakey conditions. RC1 it self had some fix, but this is even better. http://people.debian.org/~osamu/pub/ Then download sarge-i386-netinst-hacked.iso Does this fix problem? Can I merge this bug with: Bug#265636: dma issues cause cdrom mount error -- ~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ + Osamu Aoki <[EMAIL PROTECTED]> Brussels Belgium, GPG-key: A8061F32 .''`. Debian Reference: post-installation user's guide for non-developers : :' : http://qref.sf.net and http://people.debian.org/~osamu `. `' "Our Priorities are Our Users and Free Software" --- Social Contract -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#267219: Why just floppy, why not USB stick.
Package: bugreporter-udeb
Version: 0.27
Severity: wishlist
Tags: patch, d-i
Hi,
As you all know, there are more PC with USB port than one with floppy
drive these days. But, bugreporter-udeb try to save data in floppy.
As I start playing d-i, I realized pluging in empty vfat formatted USB
key before hw-detect was very convienient way to get log out. I just
mount a scsi device which happen to be USB key.
THis can be done with any USB storage such as USB HDD.
Can we do the same for bugreporter-udeb? I used init code from
rootskel/src-bootfloppy and updated bugreporter-udeb.postinst script (no
testing yet). This will not only mount floppy but any USB key (or USB
storage) devices formatted with vfat partition and save log there. Also
this now create new directory so old report will not be overwritte.
Code (untested) is short and attached.
Code review or your thought is appreciated.
This should address practical functional issues of "USB floppy not
detected" since you can plug in USB key to get data out. #220306, #221575
BTW, where the USB floppies show up? These bugs may even be taken care
with the followng code for current code:
find /dev/scsi -name 'part?'||true
(I am sure removing -name 'part?' will take care but makes less
efficient.) Hmmm... this seem to really fix these bugs too.
Osamu
PS: I found minor efficiency bug in rootskel/src-bootfloppy
PPS: I guess I need to update Release file in CD too to get it working.
But what else is needed to replace udeb in netinst CD? I need to test
this udeb. Doing upkg -i bugreporter-udeb* from console while $PWD on
/cdrom//bugreporter-udeb* is sufficient?
#!/bin/sh -e
. /usr/share/debconf/confmodule
log() {
logger -t bugreporter-udeb -p user.debug "$@"
}
if [ "" = "$DILOGDIR" ]; then
DILOGDIR=/var/log/
fi
# make sure we have a directory
if [ ! -d $DILOGDIR ]; then
mkdir -p $DILOGDIR
fi
copy_cdebconf_db() {
destdir="$1"
# Save database to disk
# kill -?
cp -a /var/lib/cdebconf "$destdir"
}
db_input critical bugreporter-udeb/insert_floppy || [ $? -eq 30 ]
db_go
# generate files with HW info, debconf database info etc, and store
# them in $DILOGDIR
db_progress START 0 3 debian-installer/bugreporter-udeb/title
/bin/package-versions > $DILOGDIR/package-versions
db_progress STEP 1
/bin/report-hw > $DILOGDIR/hardware-summary
db_progress STEP 1
# Mostly copied from rootskel/src-bootfloppy. [2004-08-20]
mountfloppy() {
# Try mounting USB memory key
if [ -x /usr/sbin/usb-discover ]; then
/usr/sbin/usb-discover
fi
# This is currently needed or usb-storage won't load (for ide_fix_driveid).
modprobe ide-core >/dev/null
modprobe usb-storage >/dev/null
modprobe sd_mod >/dev/null
MOUNTED=0
while [ "$MOUNTED" = 0 ]; do
DEVS=""
if [ -d /dev/floppy ]; then
# Should I keep /dev/floppy/?
DEVS=/dev/floppy/0
fi
# Assuming USB storage partition to be formated with vfat partition
if [ -d /dev/scsi ]; then
DEVS="$DEVS `find /dev/scsi -name 'part?'||true`"
fi
ERR=""
for dev in $DEVS; do
if [ "$MOUNTED" = 0 ] && [ -b $dev ]; then
# Use /floppy as mount point even if USB storage.
if mount $dev -o rw -tvfat /floppy 2>/dev/null; then
MOUNTED=1
else
ERR="$ERR $dev: cannot mount"
umount /floppy 2>/dev/null || true
fi
fi
done
if [ "$MOUNTED" = 0 ]; then
if [ -n "$ERR" ]; then
# ERR begins with a semicolon
log "Cannot find $ERR"
else
log "No devices found!"
fi
exit 1
fi
log "Mounted floppy: $dev"
return 0
}
test -d /floppy || mkdir /floppy
umount /floppy 2>/dev/null || true
if mountfloppy ; then
log "Floppy or USB storage mounted on /floppy"
# Since USB key is big, let's try to many several install logs there.
for i in
00 01 02 03 04 05 06 07 08 09 \
10 11 12 13 14 15 16 17 18 19 \
20 21 22 23 24 25 26 27 28 29 END ; do
LOGDIR=debian${i}
if [ ! -e "$LOGDIR" ] ; then
break
fi
if [ "$i" = "END" ] ; then
log "No space in the storage media."
exit 1
fi
done
log "Save d-i install logs to $LOGDIR"
mkdir /floppy/$LOGDIR
for file in \
/var/log/messages \
/var/log/syslog \
/var/log/partman \
$DILOGDIR/hardware-summary \
$DILOGDIR/package-versions; do
if [ -e $file ]; then
cp $file /floppy/$LOGDIR/
fi
done
umount /floppy 2>/dev/null || true
db_progress STEP 1
db_progress STOP
else
db_progress STEP 1
db_progress STOP
db_input critical bugreporter-udeb/no_floppy ||
Bug#267168: modprobe -v ohci1394 message, (successful RC1-osamu)
86/kernel/drivers/ide/pci/sis5513.o insmodsis5513 Using /lib/modules/2.4.26-1-386/kernel/drivers/ide/pci/siimage.o insmodsiimage Using /lib/modules/2.4.26-1-386/kernel/drivers/ide/pci/serverworks.o insmodserverworks Using /lib/modules/2.4.26-1-386/kernel/drivers/ide/pci/sc1200.o insmodsc1200 Using /lib/modules/2.4.26-1-386/kernel/drivers/ide/pci/rz1000.o insmodrz1000 Using /lib/modules/2.4.26-1-386/kernel/drivers/ide/pci/piix.o insmodpiix Using /lib/modules/2.4.26-1-386/kernel/drivers/ide/pci/pdc202xx_old.o insmodpdc202xx_old Using /lib/modules/2.4.26-1-386/kernel/drivers/ide/pci/opti621.o insmodopti621 Using /lib/modules/2.4.26-1-386/kernel/drivers/ide/pci/ns87415.o insmodns87415 Using /lib/modules/2.4.26-1-386/kernel/drivers/ide/ide-disk.o Using /lib/modules/2.4.26-1-386/kernel/drivers/ide/pci/hpt366.o insmodide-disk insmodhpt366 Using /lib/modules/2.4.26-1-386/kernel/drivers/ide/pci/hpt34x.o insmodhpt34x Using /lib/modules/2.4.26-1-386/kernel/drivers/ide/pci/generic.o insmodgeneric Using /lib/modules/2.4.26-1-386/kernel/drivers/ide/pci/cy82c693.o insmodcy82c693 Using /lib/modules/2.4.26-1-386/kernel/drivers/ide/pci/cs5530.o insmodcs5530 Using /lib/modules/2.4.26-1-386/kernel/drivers/ide/pci/cmd64x.o insmodcmd64x Using /lib/modules/2.4.26-1-386/kernel/drivers/ide/pci/cmd640.o insmodcmd640 Using /lib/modules/2.4.26-1-386/kernel/drivers/ide/pci/amd74xx.o insmodamd74xx Using /lib/modules/2.4.26-1-386/kernel/drivers/ide/pci/alim15x3.o insmodalim15x3 Using /lib/modules/2.4.26-1-386/kernel/drivers/ide/pci/aec62xx.o insmodaec62xx Using /lib/modules/2.4.26-1-386/kernel/drivers/ide/pci/adma100.o insmodadma100 Using /lib/modules/2.4.26-1-386/kernel/drivers/ide/pci/pdc202xx_new.o insmodpdc202xx_new Using /lib/modules/2.4.26-1-386/kernel/drivers/ide/ide-detect.o insmodide-detect Using /lib/modules/2.4.26-1-386/kernel/drivers/cdrom/cdrom.o Using /lib/modules/2.4.26-1-386/kernel/drivers/ide/ide-cd.o insmodcdrom insmodide-cd Using /lib/modules/2.4.26-1-386/kernel/fs/isofs/isofs.o insmodisofs Using /lib/modules/2.4.26-1-386/kernel/drivers/scsi/sd_mod.o insmodsd_mod Using /lib/modules/2.4.26-1-386/kernel/drivers/ieee1394/ohci1394.o insmod: init_module: ohci1394: No such device insmodohci1394 modprobe: failed to load module ohci1394 modprobe -v ohci1394 Using /lib/modules/2.4.26-1-386/kernel/drivers/ieee1394/ohci1394.o insmodohci1394 Using /lib/modules/2.4.26-1-386/kernel/drivers/ieee1394/ohci1394.o insmod: init_module: ohci1394: No such device modprobe: failed to load module ohci1394 ls -l /lib/modules/2.4.26-1-386/kernel/drivers/ieee1394/ -rw-rw-rw-1 root root17644 Jan 1 1970 eth1394.o -rw-rw-rw-1 root root 249267 Jan 1 1970 ieee1394.o -rw-rw-rw-1 root root31680 Jan 1 1970 ohci1394.o -rw-rw-rw-1 root root24204 Jan 1 1970 sbp2.o -- ~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ + Osamu Aoki <[EMAIL PROTECTED]> Brussels Belgium, GPG-key: A8061F32 .''`. Debian Reference: post-installation user's guide for non-developers : :' : http://qref.sf.net and http://people.debian.org/~osamu `. `' "Our Priorities are Our Users and Free Software" --- Social Contract signature.asc Description: Digital signature
Re: firewire CD install
On Thu, Aug 19, 2004 at 10:57:31PM +0200, Christian Perrier wrote: > Quoting Osamu Aoki ([EMAIL PROTECTED]): > > Hi, > > > > I have PC with firewire CDROM. > > > > Is there some established trick for firewire CD install? > > > > I could install by manually enabling required modules from console with > > modprobe sbp2 and seemingly related scsi devices. > > > > But hw-detect does not prompt me a thing? How the normal user are > > expected to do? > > After loading sbp2, try to add the sr_mod module, then > > echo "scsi add-single-device 0 0 0 0" > /proc/scsi/scsi Hmmm. only these 2 do not detect it. I again modprobed all these: ohci1394 sg sbp2 usb-storage sd_mod sr_mod h still did not. > Please send "lspci -v" and "lspci -n" as a bug report against > discover1 as obviously your IEEE controller is not detected... Oh, lspci is on CD. I will look for other boot disk. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#265636: hacked RC1 iso image fixing DELL mount issues.
On Thu, Aug 19, 2004 at 03:00:32AM +0200, Osamu Aoki wrote: > I found bug. > devices=$(echo /dev/cdroms/*|grep -v '*' || true) sigh grep -Fv and I found few more... I think I finally got it working as good as possible. This tries to unmount and detect again when mounted cdrom image is wrong. This new image allows not just auto-detect but all other forms to act the same. Anyway, can few of you test this image? I will put my new hacked RC1 image with bug fix (overwritten old one) http://people.debian.org/~osamu/pub/sarge-i386-netinst-rc1-hacked.iso I will test this few more times though ... Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
firewire CD install
Hi, I have PC with firewire CDROM. Is there some established trick for firewire CD install? I could install by manually enabling required modules from console with modprobe sbp2 and seemingly related scsi devices. But hw-detect does not prompt me a thing? How the normal user are expected to do? Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#265636: Idea for Dell CDROM detect issue
Hi, On Thu, Aug 19, 2004 at 03:00:32AM +0200, Osamu Aoki wrote: > I found bug. No more serious one. But I made a minor feature enhancement. If $CDROM_DEVICES is set to "none", there will be no cdrom auto detect. If $CDROM_DEVICES can be set to preseed cdrom device name. This will be handy for debug and using 2nd CDROM etc. I maintain string freeze limitation and basically reordered looping logic. I will not post here but does this kind of big reordering acceptable to d-i component at this stage? Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#265636: Idea for Dell CDROM detect issue
No, no. no. this was OK. Excuse me for noise.
On Thu, Aug 19, 2004 at 07:43:06AM +0200, Osamu Aoki wrote:
> On Thu, Aug 19, 2004 at 03:00:32AM +0200, Osamu Aoki wrote:
> > I found bug.
> one more
> >
> > log "main loop: $imount out of $maxmount"
> > # Is a cdrom (image) already mounted at /cdrom? Sanity check!
> > if [ ! -e /cdrom ] ; then
> I need to reorder
> > # First run of cdrom-detect
> > mkdir /cdrom 2>/dev/null || true
> > elif [ "$mounted" = "1" ]; then
> > # If a device was detected but the mount failed, ask for the CD.
> > log "CDROM device was detected but the mount failed."
> > db_input critical cdrom-detect/retry || [ $? -eq 30 ]
> > db_go
> > db_get cdrom-detect/retry
> > if [ "$RET" = "true" ]; then
> > imount=$((${imount}-1))
> > mounted=0
> > continue
> > else
> > fail "a device was detected but the mount failed."
> > fi
> > elif [ -e /cdrom/.disk/info ] ; then
> this is before /cdrom
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
>
>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#265636: Idea for Dell CDROM detect issue
On Thu, Aug 19, 2004 at 03:00:32AM +0200, Osamu Aoki wrote:
> I found bug.
one more
>
> log "main loop: $imount out of $maxmount"
> # Is a cdrom (image) already mounted at /cdrom? Sanity check!
> if [ ! -e /cdrom ] ; then
I need to reorder
> # First run of cdrom-detect
> mkdir /cdrom 2>/dev/null || true
> elif [ "$mounted" = "1" ]; then
> # If a device was detected but the mount failed, ask for the CD.
> log "CDROM device was detected but the mount failed."
> db_input critical cdrom-detect/retry || [ $? -eq 30 ]
> db_go
> db_get cdrom-detect/retry
> if [ "$RET" = "true" ]; then
> imount=$((${imount}-1))
> mounted=0
> continue
> else
> fail "a device was detected but the mount failed."
> fi
> elif [ -e /cdrom/.disk/info ] ; then
this is before /cdrom
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#265636: Idea for Dell CDROM detect issue
I will put my new hacked RC1 image with bug fix http://people.debian.org/~osamu/pub/sarge-i386-netinst-rc1-hacked-v2.iso -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#265636: Idea for Dell CDROM detect issue
I found bug.
If no IDE existed, it used to assign:
devices='/dev/cdroms/*'
That is bad. That section (needs to be)
# Auto detect CDROM by devfs
if [ -d /dev/cdroms ]; then
devices=$(echo /dev/cdroms/*|grep -v '*' || true)
else
devices=""
fi
Also
if [ -n "$devices" ]; then
needs to be moved up before
for device in $devices
Some more code cleanings ...
By the way, it does not detect firewire CD now.
Osamu
#! /bin/sh
set -e
. /usr/share/debconf/confmodule
#set -x
log() {
logger -t cdrom-detect "$@"
}
fail () {
log "$@"
db_input critical cdrom-detect/failure || [ $? -eq 30 ]
db_go
# redundant but to be sure
umount /cdrom 2>/dev/null || true
exit 1
}
hw-detect cdrom-detect/detect_progress_title || true
log "Searching for Debian installation media..."
maxmount=2 # max count of the mount try
imount=0# mount counter
mounted=0 # 0=initial, 1=detection in progress, 2=mounted
while true
do
if [ "$imount" -gt "$maxmount" ] ; then
fail "Tried to mount CD $maxmount times and failed."
fi
log "main loop: $imount out of $maxmount"
# Is a cdrom (image) already mounted at /cdrom? Sanity check!
if [ ! -e /cdrom ] ; then
# First run of cdrom-detect
mkdir /cdrom 2>/dev/null || true
elif [ "$mounted" = "1" ]; then
# If a device was detected but the mount failed, ask for the CD.
log "CDROM device was detected but the mount failed."
db_input critical cdrom-detect/retry || [ $? -eq 30 ]
db_go
db_get cdrom-detect/retry
if [ "$RET" = "true" ]; then
imount=$((${imount}-1))
mounted=0
continue
else
fail "a device was detected but the mount failed."
fi
elif [ -e /cdrom/.disk/info ] ; then
# Sanity check of CD before aproving mounted CD
CDNAME=`cat /cdrom/.disk/info`
log "Detected CD '$CDNAME'"
# Set the suite used by base-installer and base-config to
# the suite that is on the CD. This assumes that there will
# be no more than one distribution on the CD, and that one of the
# testing, stable, or unstable links will point to it. Since the
# CDs currently have many links, parse the Release file to get the
# actual suite name to use.
for distlink in stable testing unstable ; do
relfile=/cdrom/dists/$distlink/Release
if [ -e $relfile ] ; then
suite=$(sed -n 's/^Suite: *//p' $relfile)
log "Detected CD with '$suite' distribution"
db_set mirror/suite $suite
break # for distlink loop
fi
done
if [ "X" = "X${suite}" ]; then
log "Could not determine the package 'suite'. Is the cdrom OK?"
umount /cdrom 2>/dev/null || true
mounted=1
continue
elif [ ! -e "/cdrom/dists/$suite/Release" ]; then
log "No such file '/cdrom/dists/$suite/Release'. Is the cdrom OK?"
umount /cdrom 2>/dev/null || true
mounted=1
continue
fi
log "successful mount, exit main loop."
break
elif mount | grep -q 'on /cdrom ' ; then
log "The available CD is not a Debian CD!"
umount /cdrom 2>/dev/null || true
db_input critical cdrom-detect/wrong-cd || [ $? -eq 30 ]
db_go
imount=$((${imount}-1))
mounted=0
continue
fi
# mount CD
imount=$((${imount}+1))
mounted=1
# Auto detect CDROM by devfs
if [ -d /dev/cdroms ]; then
devices=$(echo /dev/cdroms/*|grep -v '*' || true)
else
devices=""
fi
if [ -n "$devices" ]; then
for device in $devices
do
if mount -t iso9660 -o ro,exec $device /cdrom; then
log "CDROM-mount succeeded: device=$device"
mounted=2
db_set cdrom-detect/cdrom_device $device
break # for device loop
else
log "CDROM-mount failed (error=$?): device=$device"
log "Unmounting CD just to be sure."
umount /cdrom 2>/dev/null || true
fi
done
continue
fi
# Mount floppy if CD auto detect fails
# If no device was detected, perhaps a driver floppy is needed.
if [ -e /usr/lib/debian-installer/retriever/floppy-retriever ]; then
db_input critical cdrom-detect/load_floppy
db_go
db_get cdrom-detect/load_floppy
if [ "$RET" = true ]; then
anna floppy-retriever
hw-detect cdrom-detect/detect_progress_title || true
mounted=2
continue
fi
fi
# Otherwise manual configuration may be needed
db_input critical cdrom-detect/manual_config || [ $? -eq 30 ]
db_go
db_get cdrom-detect/manual_config
modules=none
for i in `ls -1 /lib/modules/*/kernel/dri
Bug#265636: Idea for Dell CDROM detect issue
tags 265636 patch
On Tue, Aug 17, 2004 at 08:28:41AM +0100, Joey Hess wrote:
> Osamu Aoki wrote:
> > Proposed ERRATA:
...
> We have plenty of time to fix cdrom-detect before rc2 without resorting
> to ugly errata like that. I'd rather turn off DMA for all CDs than have
> that errata, personally.
OK. I was afraid of my TeX/LaTeX related FTBFS RC bugs burning my time.
I got patch from Atsuhito Kohda and I am happy :)
> > +elif [ ! -e "/cdrom/dists/$suite/Release" ]; then
> > + log "No such file '/cdrom/dists/$suite/Release'. Is the cdrom OK?"
> > + fail
> > +fi
>
> Couldn't it retry the mount if the Release file was not found, rather
> than immediatly failing?
If you want equivalent of such behaviour, just enable commented out
codes after applying patch. That is the low impact solution.
But this code is getting messy if I add code to loop for this.
On the other hand, proper solution seems clean up of existing while-loop
structure and error handling in a consistent way.
Since I moved many codes, patch is bigger than original file. So I
attach file itself.
This worked on my DELL and normal PC. Somehow DELL caused mount
error instead of quiet symlink failure. But code should detect it too.
Manual module and floppy has not been tested.
Quiet retry number can be adjusted but code around it needs careful
proofing since this is just my quick hack. Also some indentation clean
up will be nice.
Osamu
I will put my hacked RC1 image with this change in
http://people.debian.org/~osamu/pub/sarge-i386-netinst-rc1-hacked.iso
(Please wait for its upload in about 90 min.)
#! /bin/sh
set -e
. /usr/share/debconf/confmodule
#set -x
log() {
logger -t cdrom-detect "$@"
}
fail () {
log "$@"
db_input critical cdrom-detect/failure || [ $? -eq 30 ]
db_go
# redundant but to be sure
umount /cdrom 2>/dev/null || true
exit 1
}
hw-detect cdrom-detect/detect_progress_title || true
log "Searching for Debian installation media..."
maxmount=2 # max count of the mount try
imount=0# mount counter
while true
do
if [ "$imount" -gt "$maxmount" ] ; then
fail "Tried to mount CD $maxmount times and failed."
fi
# Is a cdrom (image) already mounted at /cdrom? Sanity check!
if [ ! -e /cdrom ] ; then
# First run of cdrom-detect
mkdir /cdrom 2>/dev/null || true
elif [ -e /cdrom/.disk/info ] ; then
# Second run or looped after cdrom mount
CDNAME=`cat /cdrom/.disk/info`
log "Detected CD '$CDNAME'"
# Sanity check of CD
# Set the suite used by base-installer and base-config to
# the suite that is on the CD. This assumes that there will
# be no more than one distribution on the CD, and that one of the
# testing, stable, or unstable links will point to it. Since the
# CDs currently have many links, parse the Release file to get the
# actual suite name to use.
for distlink in stable testing unstable ; do
relfile=/cdrom/dists/$distlink/Release
if [ -e $relfile ] ; then
suite=$(sed -n 's/^Suite: *//p' $relfile)
log "Detected CD with '$suite' distribution"
db_set mirror/suite $suite
break # for distlink loop
fi
done
if [ "X" = "X${suite}" ]; then
log "Could not determine the package 'suite'. Is the cdrom OK?"
umount /cdrom 2>/dev/null || true
continue
elif [ ! -e "/cdrom/dists/$suite/Release" ]; then
log "No such file '/cdrom/dists/$suite/Release'. Is the cdrom OK?"
umount /cdrom 2>/dev/null || true
continue
fi
# successful mount, exit while loop
break
elif mount | grep -q 'on /cdrom ' ; then
log "The available CD is not a Debian CD!"
umount /cdrom 2>/dev/null || true
db_input critical cdrom-detect/wrong-cd || [ $? -eq 30 ]
db_go
imount=$((${imount}-1))
continue
fi
# mount CD
imount=$((${imount}+1))
# Auto detect CDROM by devfs
if [ -d /dev/cdroms ]; then
devices="`echo /dev/cdroms/*`"
else
devices=""
fi
mounted=0 # flag for having mounted CD
for device in $devices
do
if mount -t iso9660 -o ro,exec $device /cdrom; then
log "CDROM-mount succeeded: device=$device"
mounted=1
db_set cdrom-detect/cdrom_device $device
break # for device loop
else
log "CDROM-mount failed (error=$?): device=$device"
log "Unmounting CD just to be sure."
Re: Bug#265636: Idea for Dell CDROM detect issue
On Tue, Aug 17, 2004 at 09:54:53AM +1000, [EMAIL PROTECTED] wrote:
> > 1. Patch by Vincent McIntyre (Bug#265636) has good intent but buggy
> >as is. (I wish this type of syntax exists for "fail" function.)
>
> That was only a sketch, as I don't have a good understanding of how such
> an error should be presented to the user by d-i.
> I think the problem with cdrom-detect.postinst is real and could be
> cleaned up quite quickly.
> I will study the code some more and try write a real patch.
> If the author would like to help, or take over, I'm happy for that too.
This part is basically your patch with fix.
+if [ "X" = "X${suite}" ]; then
+ log "Could not determine the package 'suite'. Is the cdrom OK?"
+ fail
+elif [ ! -e "/cdrom/dists/$suite/Release" ]; then
+ log "No such file '/cdrom/dists/$suite/Release'. Is the cdrom OK?"
+ fail
+fi
I changes this to elif for simplicity.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#265636: Idea for Dell CDROM detect issue
Hi,
Executive summary:
1. Patch by Vincent McIntyre (Bug#265636) has good intent but buggy
as is. (I wish this type of syntax exists for "fail" function.)
2. My previous patch was not general enough.
3. My new patch here should work but intrusive at this moment.
(This can be better. "fail" and "exit 1" need to be cleaned.)
4. I lack time to test throrouly for the release.
5. Realistically, ERRATA is the good aproach now considering release
schedule.
Proposed ERRATA:
--
In some CDROM drives such as the ones on the older Dell laptop PCs,
second detection may be successful. If you fail in mounting CD, you
simply run detect CDROM drive again from the menu. If reading CD fails
with installation log in vt4 indicating:
anna[4147]: /cdrom/dists//Release
anna[4147]: : No such file or directory
then, you need to go to console and run "umount /cdrom" before running
to detect CDROM drive from the menu.
My thoughts...
After some thought, I think situation of funny CDROM firmware/Linux
kernel interaction as followings.
In old tc1, buggy DELL CDROM drive DMA related initialization during
mount caused mount error but mounted CD halfway (no symlink).
In new rc1, buggy DELL CDROM drive the same DMA related initialization
during mount causes no mount error while still mounting CD halfway (no
symlink). agh.
My initial attempt to work around in RC1 relied on failed action of
mount.
My new thought is if HW is buggy, we should tell user about it and offer
way to proceed. Currently, you need to umount cd from the console
unless you are expert. This is not desirable. Centrarized automatic
umount should be implemented and easier to manage.
Also dummy mount/umount code in my previous mail was commented out now
so no one will use it unless you change source but as reminder. I also
removed section which is based on tc1 fix scenario.
Also I fixed funny confused use of fail/log functions in Vincent's
oroginal patch.
* Any opinion?
* Should dummy mount/umount be commented out?
* Is it worth patching now?
* I think reorganizing whole code makes it much more readable.
* Further code fix should be etch thing.
Osamu
--- cdrom-detect.postinst.old 2004-07-02 02:23:52.0 +0200
+++ cdrom-detect.postinst 2004-08-17 00:21:06.0 +0200
@@ -9,7 +9,9 @@
}
fail () {
-log "CDROM-detect failed."
+log "CDROM-detect failed. Unmounting cdrom just to be sure."
+umount /cdrom 2>/dev/null || true
+log "For buggy CDROM drive, you may try CDROM-detect again."
db_input critical cdrom-detect/failure || [ $? -eq 30 ]
db_go
exit 1
@@ -40,6 +42,10 @@
fi
for device in $devices
do
+# For some buggy CDROM drive, blindly mount and umount
+# CDROM will avoid DMA issues with kernel.
+#mount -t iso9660 -o ro,exec $device /cdrom || true
+#umount /cdrom 2>/dev/null || true
if mount -t iso9660 -o ro,exec $device /cdrom; then
log "CDROM-mount succeeded: device=$device"
mounted=1
@@ -49,18 +55,6 @@
log "CDROM-mount failed (error=$?): device=$device"
log "Unmounting CD just to be sure."
umount /cdrom 2>/dev/null || true
-log "Trying it again."
-if mount -t iso9660 -o ro,exec $device /cdrom
-then
-log "CDROM-mount succeeded: device=$device"
-mounted=1
-db_set cdrom-detect/cdrom_device $device
-break
-else
-log "CDROM-mount failed again (error=$?): device=$device"
-log "Unmounting CD just to be sure and giving it up."
-umount /cdrom 2>/dev/null || true
-fi
fi
done
@@ -161,6 +155,13 @@
break
fi
done
+if [ "X" = "X${suite}" ]; then
+ log "Could not determine the package 'suite'. Is the cdrom OK?"
+ fail
+elif [ ! -e "/cdrom/dists/$suite/Release" ]; then
+ log "No such file '/cdrom/dists/$suite/Release'. Is the cdrom OK?"
+ fail
+fi
# Ask for eject to be installed into /target/, to be able to use it in
# the prebaseconfig script.
Bug#263162: Please describe your tasksel policy, and re-add the tex task
Hi, On Mon, Aug 16, 2004 at 05:33:41PM +0200, Frank Küster wrote: > This is not what I learned tasksel to be, as a user years ago. However, > I have no good suggestion regarding TeX. Perhaps a meta-package is more > appropriate; however I am not sure what should be in it. Well, I think we should start with packages in the woody version's tasksel. > Although I question the usefulness of the criteria you use for tasksel > (or of a tasksel using those criteria), I don't mind very much, and I > will accept this as it is. Maybe sometime a meta package comes about. > > For me, I would close this bug - however, since other people took part > in the discussion, I will wait a couple of days. I think sensible solution is to carefully chack and maintain tetex-bin package's Depends:, Recommends:, Suggests:. If these are done well, then tex or latex virtual package will invite people to tetex-bin and installing all Depends:, Recommends:, Suggests: chain by aptitude will give decent tex+latex environment. I did not cross check this one with previous tasksel rersults. Considering tasksel is more general purpose machine set-up by popular functionarity, I can live with this new simplified memu. But I will certainly miss "educational" side of previous tasksel choices. TeX task had a good educational value. So had the "C programing" task. Osamu
Bug#265636: Errata alternative and patch
Hi, As I posted on d-boot, I think you can work around this problem by editing cdrom-detect.postinst script. I attache equivalent action patch here. -- ~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ + Osamu Aoki <[EMAIL PROTECTED]> Brussels Belgium, GPG-key: A8061F32 .''`. Debian Reference: post-installation user's guide for non-developers : :' : http://qref.sf.net and http://people.debian.org/~osamu `. `' "Our Priorities are Our Users and Free Software" --- Social Contract --- cdrom-detect.postinst.old 2004-07-02 02:23:52.0 +0200 +++ cdrom-detect.postinst 2004-08-16 02:33:38.0 +0200 @@ -40,6 +40,10 @@ fi for device in $devices do +# since some buggy CDROM drive caused initial mount problem +# just blindly mount and umount first to avoid issues. +mount -t iso9660 -o ro,exec $device /cdrom || true +umount /cdrom 2>/dev/null || true if mount -t iso9660 -o ro,exec $device /cdrom; then log "CDROM-mount succeeded: device=$device" mounted=1 @@ -49,18 +53,6 @@ log "CDROM-mount failed (error=$?): device=$device" log "Unmounting CD just to be sure." umount /cdrom 2>/dev/null || true -log "Trying it again." -if mount -t iso9660 -o ro,exec $device /cdrom -then -log "CDROM-mount succeeded: device=$device" -mounted=1 -db_set cdrom-detect/cdrom_device $device -break -else -log "CDROM-mount failed again (error=$?): device=$device" -log "Unmounting CD just to be sure and giving it up." -umount /cdrom 2>/dev/null || true -fi fi done
Re: RC1: anna started without dists name
On Mon, Aug 16, 2004 at 08:32:38AM +1000, [EMAIL PROTECTED] wrote: > > Sounds like a broken CD build without Rock Ridge extensions, perhaps. > I'm pretty sure the cd is ok. I checked by booting another machine. And > if I load the ide modules without dma for hdc, things work normally. I found another work around. Edit cdrom-detect.postinst just after reboot >> add unmount and mount with "|| true" right after normally >> finished mount. This means dummy mount action and unmount action was better patch. My previous patch remounted only for error case. But this new approach is not so aesthetically nice. Good night. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RC1: anna started without dists name
On Sun, Aug 15, 2004 at 03:22:57PM +0100, Colin Watson wrote:
> On Sat, Aug 14, 2004 at 02:02:52PM +1000, [EMAIL PROTECTED] wrote:
> > Colin Watson wrote:
> > > Where should I look into?
> > > Is there any work around? It look like missing dists name.
> >
> > The problem seems to be the symlinks on the cdrom
> > (/cdrom/dists/{stable,testing,unstable}) are interpreted as files,
> > and not as symlinks.
>
> Sounds like a broken CD build without Rock Ridge extensions, perhaps.
Even on these broken-Dell machine, these can be read OK if I manually
remount them later. So this is not CD problem. This is CD-ROM
drive/driver issue.
Osamu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RC1: anna started without dists name
On Sat, Aug 14, 2004 at 01:44:43AM +0100, Colin Watson wrote: > On Fri, Aug 13, 2004 at 07:16:55PM +0200, Osamu Aoki wrote: > > But my RC1 install fails on some machine (one which had hard time > > mounting CD initially) with; > > > > anna[4147]: /cdrom/dists//Release > > anna[4147]: : No such file or directory > > > > I have cdrom mounted and /cdrom/dists/*/RElease exist all right. > > > > Where should I look into? > > Is there any work around? It look like missing dists name. > > This kind of looks like a CD bug to me. I've seen it before, but I don't > remember how; I think I fixed it in whatever version of debian-cd I was > fiddling with at the time. What does /cdrom/dists/sarge/Release look > like? They have files. But as pointed out, others are zero content normal files. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RC1: anna started without dists name
On Sat, Aug 14, 2004 at 02:02:52PM +1000, [EMAIL PROTECTED] wrote:
> > I can not get exact log out due to missing libutil.so.1 :)
> > But my RC1 install fails on some machine (one which had hard time
> > mounting CD initially) with;
> >
> > anna[4147]: /cdrom/dists//Release
> > anna[4147]: : No such file or directory
> >
> > I have cdrom mounted and /cdrom/dists/*/RElease exist all right.
>
> I see this too, on Dell Latitude CPiA. This appears to be a reappearance
> of #250323.
>
> > Where should I look into?
> > Is there any work around? It look like missing dists name.
>
> The problem seems to be the symlinks on the cdrom
> (/cdrom/dists/{stable,testing,unstable}) are interpreted as files,
> and not as symlinks.
I see that to. I was wondering what are these files.
The thing seems to be mounting kernel error disapeared now as I
remember. That may be the source of problem. I think it should error
and reset kernel IDE driver to use non-DMA mode.
(So no need for my patch in a sense. This relied on kernel error and
remount.)
By the way, for boot-loader kernel, do we care about performance gain of
DMA? If not disable them all together for stability.
Or should we have sleep inserted after mount/umount to stabilize system?
Osamu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RC1: anna started without dists name
I can not get exact log out due to missing libutil.so.1 :) But my RC1 install fails on some machine (one which had hard time mounting CD initially) with; anna[4147]: /cdrom/dists//Release anna[4147]: : No such file or directory I have cdrom mounted and /cdrom/dists/*/RElease exist all right. Where should I look into? Is there any work around? It look like missing dists name. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Manual] installer-manual on the website (was: release plans for website?)
On Thu, Aug 05, 2004 at 04:11:50PM +0200, Frank Lichtenheld wrote: > On Mon, Aug 02, 2004 at 10:55:38PM -0400, Joey Hess wrote: > > Is there any plan for how the web site update will be handled for > > sarge's release? Besides just switching the names and links to sarge, > > I've been looking at what parts of the web site will need updating for > > the new installer and other missing bits. These include: > > > [...] > > - sarge/installmanual: doesn't exist. One possibility is to link to the > >sarge install manual in the debian archive on a mirror, which is > >updated whenever the images are updated. I don't know how the woody > >install manual is imported into the web site so maybe however it is > >manage is better. > > This is how the installation manual was handled for boot-floppies (i.e. > potato and woody): The sources where checked out from the > boot-floppies CVS and were build locally. ... Whatever final web page should look like, I really looking for the web page with URL reactivated: http://www.debian.org/releases/testing/installmanual http://www.debian.org/releases/testing/releasenotes This can be even a short sentence stating "it is not available on web but only as package." We seem to have simply removed them after woody release. Osamu signature.asc Description: Digital signature
OT: Automatic allocation of swap
On Tue, Aug 03, 2004 at 12:36:31AM +0200, Osamu Aoki wrote: > Really, Linux or Windows, it is bad idea to fill actively used disk up > to 98%. (For your case / partition. /boot may be OK since it is > practically read-only.) For Linux, 90-95%, for windows 60-70% is my > common sense usage. Oops. I am talking upper limit. My notebook now has: FilesystemSize Used Avail Use% Mounted on /dev/hda5 15G 5.5G 8.3G 40% / tmpfs 253M 0 253M 0% /dev/shm /dev/hda7 4.6G 33M 4.4G 1% /chroot/hda7 /dev/hda8 4.6G 33M 4.4G 1% /chroot/hda8 /dev/hda9 4.6G 33M 4.4G 1% /chroot/hda9 /dev/hda10 11G 2.6G 7.2G 27% /arc (I put backup here) FilenameTypeSizeUsedPriority /dev/hda6 partition 2048220 0 -1 I am lazy :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Automatic allocation of swap
On Mon, Aug 02, 2004 at 09:21:05AM +0800, John Summerfield wrote: > Osamu Aoki wrote: > >On Sun, Aug 01, 2004 at 09:04:50PM +0800, John Summerfield wrote: > By spreading data over multiple partitions with great gobs of free space > between small (after install) amounts of data, you're forcing longer seeks. Yes. We all know this. Let's not argue over belief. If you want us to change something, few ways to do this. 1. clear facts (bench mark result of different configurations) 2. reference some authoritative documents. and patch always help. Really, I did not say putting swap at the edge of disk is a good thing. I was annoyed by calling this "stupid". Please do not call action of DD stupid even if they are. > Here is my desktop pc. It's performance sucks bunnies through capilliary > tubes: > [EMAIL PROTECTED]:~/d-i$ /sbin/swapon -s > FilenameTypeSizeUsed > Priority > /var/swapfile file524280 455604 -1 > /var/swapfile2 file524280 69296 -2 > [EMAIL PROTECTED]:~/d-i$ df -lh > FilesystemSize Used Avail Use% Mounted on > /dev/hda3 29G 27G 639M 98% / ^ | no wonder, sigh. > tmpfs 189M 0 189M 0% /dev/shm > /dev/hda1 23M 21M 1.4M 94% /boot > [EMAIL PROTECTED]:~/d-i$ ... > That's almost certainly bad. You probably don't spend much time reading > program files and documentation in comparison with the time reading and > writing variable data. I have been reading and editing documentation a lot. Please install debian-reference-en package from Sarge :-) Then you know what. http://www.debian.org/doc/manuals/debian-reference/reference.en.html Oh, please read install guide too. That has good amount of partitioning etc. too. http://www.debian.org/releases/stable/installmanual > You're a software developer writing in C? Would you say, less than a > second to read gcc then a minute or so for a compile? Sure, it depends, > but the ratios will be somewhat like those. I usually do not write C nor compile it much. (With my old 386, I used to compile my kernel or patched-X for a day, though.) Really, Linux or Windows, it is bad idea to fill actively used disk up to 98%. (For your case / partition. /boot may be OK since it is practically read-only.) For Linux, 90-95%, for windows 60-70% is my common sense usage. Cheers, Osamu PS: FYI None of these habits should be carried over to Linux and ext2. Linux native file systems do not need defragmentation under normal use and this includes any condition with at least 5% of free space on a disk. There is a defragmentation tool for ext2 called defrag, but users are cautioned against casual use. .From: Linux Partitioning mini-FAQ http://pw1.netcom.com/~kmself/Linux/FAQs/partition.html He advocates 3x RAM for swap. signature.asc Description: Digital signature
Re: Automatic allocation of swap
Hi, On Sun, Aug 01, 2004 at 09:04:50PM +0800, John Summerfield wrote: > > I have just installed another system, and took the time to try to > familiarise myself with the partitioning tool. > > I was running a 2.6 kernel, and the install kernel's date is Jul 29 06:24. > > The install target was a Pentium II, 350 Mhz, 64 Mb RAM and 3.2 Gbytes > of disk. > > It seemed to me that the setup chosen for "multiuser" was entirely > impractical. Unfortunately, I was more interested in testing other > aspects, so I just wiped that one and tried some others. > > One aspect of that configuration I do recall. > > It allocate about 192 Mbytes of swap partition, right at the edge of the > disk. Hmm. put it to the edge may not be the best thing to do ... Does this have any real impact? > I have never thought swap partitions on single-disk systems are a good > idea, and here is why. > > 1. Performance > If there is little swapping, then any perfoemance benefit is immaterial. So do not complain swap is not at the center. > If swapping is severe (the system is thrashing), there is no good > alternative to more RAM. RAM is cheap. That is different problem. Swap will not be used unless RAM is used up. > That aside, the position of the swap area (in the d-i configuraton as > in most others) ensures the swap area is far from the data, ensuring > that operations such a opening an OOo document will send the disk heads > seeking far, back and forth, back and forth, back and forth, across > much, maybe most, of the disk surface. Then buy a RAM. Optimization you get with swap location is small. > In between, of course, is inbetween: bad sometimes, not so bad at others. > > In contrast, if I create a swap file, then it there is some prospect it > will be near at least some of the data I need to read. I do not understand... > 2 Flexibility. > The common Rule of Thumb (ROT) has the appropriate size of swap being > twice the amount of RAM installed (not three times!). I thought "at least 2 X RAM". So 3 X is OK. Besides, it is less than 10% of disk space. Who cares lost space. You can ajust it later if you care. > My own experience is that, mostly, system performance is pretty terrible > before it's used all the swap area. The sole counterexample I can think > of is using rsync to do backups. rsync can use enormous amounts of > virtual memory backing up whole disks, but its working set remains modest. ??? (Maybe you are talking bad swap logic of some 2.4 kernels. But this does not make us stop using swap.) > The stupidity of this ROT is illustrated when adding more RAM. If my > system is working moderately well with xMbytes of RAM and I, noting that > RAM is cheaper than formerly, decide to add 2x Mbytes of RAM, should I > also treble the amount of swap? Of course not, I may well decide I have > better uses for that disk space. I do not think adding ram later has negative impact and I do not call this setup stupid :) > Either way, the amount of swap is wrong, and recovering or enlarging the > amount of swap in a swap partition is not a trivial undertaking. I think it is trivial if you have empty unused diskspace. (I am comparing this to moving and resizing ext2 partition.) You can do swapoff then you can change swap partition to elsewhere. > Finally, the point that I installed a 2.6 kernel is an important one. > One of the changes I note in the new kernel is that there is no > performance benefit to using swap partitions. What? Try running a program which leaks memory. With swap, you will see slower degradation, thus enhancing your chance to avoid bad crash quickly. (I think you were annoyed some non-optimal swap usage in the previous kernels. That is different matter though.) > I recommend that, if there is one disk, a swap file be created rather > than a swap partition. Nay. Does this something other distribution zstarted to do with some reason. At least this was not normal thing. > And, if /home is a separate partition, then it should be on that > partition. That is where most I/O activity is likely to be on > single-user systems. Well I tend to partition / swap /usr /var /home in this order... but I do not think this order is something absolute. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
OT: ???? English
On Tue, Jul 27, 2004 at 12:54:37AM +0800, John Summerfield wrote: > peter green wrote: > > >im in england i selected english > >the language selection list makes no mention of American English or british > >english it just says english > > > I just ran the installer here. The _first_ screen gives a choice of > Australian English, UK English, US English and English for the rest. Wow. No Canada, No New Zealand, No South Africa, ... Hm interesting as a by stander. I'v got to check where Canada, and New Zealand belongs :-) Sorry, for noise. Osamu PS: I remember Canadians spell almost like American but not exactly. I kind of remember seeing "tyre" and "centre" more often in Canada. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#256547: lowmem and swap/fdisk (20 MB system)
Hi, just my thoughts (I am trying to install to 486/DX2 50 MHz with 20 MB of memory and PCMCIA ISA NIC without CD-ROM.) Summary: With minor change and text based prompting, d-i memory requirement can be lowered to 8-16 MB instead of current 32 MB. Details: Currently, 32 MB or so of RAM is needed for the normal debian-installer experience. Most of these new system with so much memory come with CD or network card as bootable media. But such huge needs for the memory is mostly because we run debian-installer root image on memory. As I booted from floppy, it seems much less than 16 MB is needed as long as we enable swap immediately after mounting root.img. I failed when partitioning started. (I think it was because partitioning disabled swap.) Better than original report but not good enough. http://bugs.debian.org/256547 In order to make lowmem install with floppy more usable, following action maybe desirable (no rush for immediate test release but we should think about it): (1) Include followings in the initial floppy boot.img. (Optional but this may bring memory requirement really low.) * (fdisk if possible) * swapon, (insmod is there already) * ide-disc.o ide-detect.o modules (maybe SCSI ones too) (2) Include followings in the floppy root.img. * fdisk * (swapon and insmod are there already) * ide-disc.o ide-detect.o modules (maybe SCSI ones too) If these are heavy, providing way to install them from floppies such as net-drives.img or cd-drivers.img when detecting lowmem condition automatically and prompt user to use them from vt2 to activate swap will be sufficient. (3) Add features to auto partition script. If active swap is detected, show warning and ask user to use fdisk for further partitioning carefully in vt2 if needed. Then just handle mounting only and do not touch swap situation from the partitioning script. If we do all (1) - (3), we may bring lowmem limit around 8MB. If we do (2) and (3), we may bring lowmem limit around 16MB. If fdisk (~80KB as is) in (1) is not possible as is, make an simple fdisk.img which has busybox and fdisk on interactive shell with ide-disc.o ide-detect.o modules (maybe SCSI ones too). Then we can just manually partition system before installation. Considering many odd configuration, these partitioning do not need to be menu driven, I think. I think 32MB is a bit too much for old system. If we insist, we may as well start compiling for 586 only (joking). I really hate to see d-i being more memory hungry than old woody-boot-floppies. Osamu PS: Different idea of lowmem is not to use RAMDISK for installer root. NSF mounted root image may be alternative way to install system on low memory system. After all, these lowmem installer are for experts anyway. (This may be easier if network is accessible. But my NIC is on PCMCIA which makes it impossible to have access in early phase. This is for old tower PC, I guess.) signature.asc Description: Digital signature
Re: [web] http://www.debian.org/devel/debian-installer/builds
On Sat, Jul 24, 2004 at 06:34:19AM -0400, Joey Hess wrote: > Osamu Aoki wrote: > > As I see http://www.debian.org/devel/debian-installer/builds page: > > > > The contents in English is good bat it lacks links to pertinent URL such > > as: > > > > http://www.debian.org/devel/debian-installer/ports-status";> > > a number of different builds of the Debian-Installer CD images > > > > > > http://cdimage.debian.org/pub/cdimage-testing/sid_d-i/";> > > sid_d-i > > > > > > http://cdimage.debian.org/pub/cdimage-testing/sarge_d-i/";> > > sarge_d-i > > > > > > http://cdimage.debian.org/pub/cdimage-testing/daily/";> > > daily > > > > > > in generated text will be nice. > > > > If pointing to other URL is better, please remind me here. > > (Thus I send this first to d-boot. I know this needs webwml write > > access and I have it but I think it is better done by someone knows > > better than me.) > > Your urls are fine, please go ahead. Done. signature.asc Description: Digital signature
[web] http://www.debian.org/devel/debian-installer/builds
As I see http://www.debian.org/devel/debian-installer/builds page: The contents in English is good bat it lacks links to pertinent URL such as: http://www.debian.org/devel/debian-installer/ports-status";> a number of different builds of the Debian-Installer CD images http://cdimage.debian.org/pub/cdimage-testing/sid_d-i/";> sid_d-i http://cdimage.debian.org/pub/cdimage-testing/sarge_d-i/";> sarge_d-i http://cdimage.debian.org/pub/cdimage-testing/daily/";> daily in generated text will be nice. If pointing to other URL is better, please remind me here. (Thus I send this first to d-boot. I know this needs webwml write access and I have it but I think it is better done by someone knows better than me.) Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problem formatting existing partitions
On Thu, Jul 15, 2004 at 03:14:47PM +0800, John wrote: ... > On a side note, can we have symlinks in /dev for those who like the > disks to appear in the traditional place and to munge them with more > user-friendly tools such as fdisk? I know the feelings :) But situation is not as bad as you think. d-i shell has [TAB] code enabled. fdisk /dev/[TAB][TAB] will list all device names and the rest is easy guess by the same [TAB][TAB] expansion. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#259040: Package: installation-reports
On Mon, Jul 12, 2004 at 04:15:54PM -0400, Tony D'Amato wrote: > Package: installation-reports > Comments/Problems: > > It took a while to get used to the partition system. Once I figured it > out, it was pretty straight forward. My only concern is that I was > unable to determine how to set up logical volumes and place my data on > them. Under Red Hat and SuSE, I've set up /boot as an ext3 partition, > and the rest of the system under logical volumes. Since Debian doesn't > use /boot as a separate partition with the kernel in it, I was just > wondering how to do the same using the new installer. Wait ... hmmm my Sarge (upgraded and fresh install) systems have kernels in /boot while symlink at / . Of course, unless you partition disk and mount one of it as /boot with ext3, you do not have /boot and / in separate partition. This is all possible in partition dialogue as I understand. What made you think otherwise??? > All in all, I like it a LOT! It'll be killer when the final release > comes out! Good luck! Yep. > -- > Tony. > > He that would make his own liberty secure must guard even his enemy > from oppression; for if he violates this duty he establishes a precedent > that will reach to himself. --Thomas Paine > > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > signature.asc Description: Digital signature
Bug#259017: IDE hard-drive not being detected
Hi, On Mon, Jul 12, 2004 at 02:41:12PM -0300, Margarita Manterola wrote: > Package: installation-reports > > A friend of mine just tried to install sarge from floppies, both beta4 > and daily build, into a Pentium II (Deschutes). > > He could not finish the installation because his hard drive could not be > detected, the /dev/ide directory was empty. Unless you tried to load cd-drivers.img or net-drivers.img, this may be normal if he tried to see them after mounting root.img. (At least that was true for TC1 version.) You need to load several udeb packages to have kernel modules such as ide-detect etc. This is current short coming of floppy root.img. This makes impossible to enable swap very early in install process. First round of udeb install action may crash low memory machines as my previous report: http://bugs.debian.org/256547 > What can be the reason for this? Unless you confirm how far he went to test this lack of access to ide devices, let's close this bug 259017. I just CCed this to bug 256547 as a record. Osamu signature.asc Description: Digital signature
Re: Help me test new pcmcia-cs
Hi, On Fri, Jul 09, 2004 at 11:13:46PM +0200, Per Olofsson wrote: > Hello, > > I have created a new version of pcmcia-cs now which defaults to not > bringing up new interfaces with ifup. Thanks ... but > However, I am not currently on > an ethernet connection, so I'm unable to test it. I'm therefore asking > for your help with this. The package is available at [1]. You'll have > to build it yourself because of my limited bandwith, but it hasn't too > many dependencies. You'll have purge the old version or remove > /etc/default/pcmcia to get the new default. Hmmm... Are you going to document this new feature in README.Debian? A bit awkward if one upgrades system and reads some other documentation on hotplug later documenting new setup. Can not we take care better in postinst? Minimal change option is as follows: --- pcmcia-cs.postinst.old 2004-07-10 14:33:27.0 +0200 +++ pcmcia-cs.postinst 2004-07-10 15:10:02.0 +0200 @@ -25,6 +25,15 @@ # network interfaces. They should be brought up by hotplug instead. REFRAIN_FROM_IFUP=yes EOF +else + if ! grep -q '^REFRAIN_FROM_IFUP=' $CFG ; then + cat >>$CFG < signature.asc Description: Digital signature
Re: Zip Disk installation....
Hi, On Sun, Jul 04, 2004 at 01:42:53AM +0200, Michelle Konzack wrote: > Am 2004-07-03 18:53:07, schrieb Bert Emert: > >Dear Debian... If you have NIC with fast net access, I recommend floppy(not exceeding 9 disks) + NIC (PCMCIA). It works (tested in Woody) > >Another is my Panasonic KXL-D720, PCMCIA CD/ROM Player. However, > >I have searched High and lo for a Linux disk that will boot and read > >this CD, without success. If you have Linux boot image to offer > >please let me know. If I remember product name correctly, you have the same Panasonic KXL-D720, PCMCIA CD/ROM Player as I had for my i486/50MHz :-) This is one of the rare CD not supported under Linux. I tossed it. Oh, you are posting debian-boot. This list is usually for debian-installer. This debian-installer is next generation installer for sarge but for old small memory machine, it is not very kind yet. If you have 48 MB or so, you may play with it for fun of debugging like us. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#255128: cdrom-detect: Bad handling of mount error
On Sun, Jun 27, 2004 at 01:12:11PM -0400, Joey Hess wrote: > Osamu Aoki wrote: > > Busybox does not have "sleep" on this version. (Why?) > > Just to save space, though I understand it's in sid now. > > > I will put updated patch, iso-image example, syslog-commented, etc at > > > > http://people.debian.org/~osamu/pub/d-i/ I have updated patch cosmetically and iso so md5sum.txt should be correct. (Put in tar.gz with quick build script Makefile.) CD integrity is good now. > > It works but I think following messages after Detecting CD needs to be > > understood before applying. > > > > | Jun 26 19:34:27 (none) user.notice cdrom-detect: Detected CD with 'testing' > > distribution > > | Jun 26 19:34:27 (none) user.info main-menu[297]: (process:454): mount: Mounting > > /dev/cdroms/cdrom0 on /cdrom failed: Not a directory > > | Jun 26 19:34:27 (none) user.info main-menu[297]: (process:454): umount: > > | Jun 26 19:34:27 (none) user.info main-menu[297]: (process:454): /cdrom > > | Jun 26 19:34:27 (none) user.info main-menu[297]: (process:454): : Invalid > > argument > > Hmm, I didn't think that main-menu did stderr interception and logging > any more. It should just be redirected to the messages file these days. Anyway these do not happen with this new patch. Let's apply. I am having good success. --- cdrom-detect.postinst.org 1970-01-01 01:00:00.0 +0100 +++ cdrom-detect.postinst 2004-06-29 23:29:06.0 +0200 @@ -42,9 +42,26 @@ do if mount -t iso9660 -o ro,exec $device /cdrom 2>/dev/null then +log "CDROM-mount succeeded: device=$device" mounted=1 db_set cdrom-detect/cdrom_device $device break +else +log "CDROM-mount failed (error=$?): device=$device" +log "Unmounting CD just to be sure." +umount /cdrom 2>/dev/null || true +log "Trying it again." +if mount -t iso9660 -o ro,exec $device /cdrom +then +log "CDROM-mount succeeded: device=$device" +mounted=1 +db_set cdrom-detect/cdrom_device $device +break +else +log "CDROM-mount failed again (error=$?): device=$device" +log "Unmounting CD just to be sure and giving it up." +umount /cdrom 2>/dev/null || true +fi fi done @@ -111,8 +128,13 @@ fi if mount -t iso9660 -o ro,exec $device /cdrom then +log "CDROM-mount succeeded: device=$device" mounted=1 break +else +log "CDROM-mount failed (error=$?): device=$device" +log "Unmounting CD just to be sure and giving it up." +umount /cdrom 2>/dev/null || true fi else fail Let's apply this patch. Osamu signature.asc Description: Digital signature
Re: ssh support for notebooks :) --> screen?
Hi, On Mon, Jun 28, 2004 at 01:07:21AM +0100, Colin Watson wrote: > On Mon, Jun 28, 2004 at 01:25:21AM +0200, Osamu Aoki wrote: > > On Sun, Jun 27, 2004 at 08:21:18PM +0100, Colin Watson wrote: > > > openssh-client-udeb. I didn't package scp because it's straightforward > > > to do the same thing with ssh and tar, but I suppose I could add it. > > > > openssh-client-udeb is sufficient for me. I only meant some SCP like > > functionality. I really doubt needs to login to another machine from a > > machine running on initrd. So really stripped down ssh shall be enough > > (no X forwarding etc.) > > Sure, although some people (e.g. me :-)) do like to be able to log into > other machines from the middle of a d-i install. You can use that > facility to ask for help, for instance. That is a very good point. There is no man nor info on d-i process. Hmmm... How come I missed it. I guess I was only looking for ssh-client-udeb. It did not hit me to look under "o". Thanks. > > Just nit pick. It is ssh+cat == scp. 'scp foo [EMAIL PROTECTED]:bar' is like > > 'bar"'. "tar" is a sepatete issue although > > it is an idiom used with ssh to move multiple files. (These files will > > not be concatenated if moved with ssh+tar in the famous way.) > > I beg to differ. scp preserves file modes, for instance, unlike ssh+cat. You got me. I should have said, for my requirements, I can do file transfer simply by ssh+cat. Use of tar looked overkill to me but tar and cat are already parts of busybox. No difference in binary size. > > By the way, speaking of basic functionality of initrd, I do not see > > "screen" command missing in initrd nor in pool/* as udeb. I wonder how > > you are handling some operations which kill the remote terminal > > connection used for the install. > > We don't perform such operations. :-) I do not have Big IBM here either. But someday when I want to boot broken LCD old notebook PC, I may need it. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#248071: TODO for hw-detect and/or pcmcia-cs
Hi, this bug is now filed to netcfg as I understand :) On Mon, Jun 28, 2004 at 07:45:38PM +0200, Thomas Hood wrote: > The upshot of this for hw-detect and pcmcia-cs is that they have to > be set up in one of the two following ways. > > 1. pcmcia-cs ifups/ifdowns interfaces on 16 bit PCMCIA cards >by default (as now) and hw-detect does not list such interfaces >in /etc/network/devhotplug, instead listing them in >/etc/network/devcardmgr (so that netcfg knows not to mark them >as "auto"). (This requires a change to hw-detect.) Maybe this may be more easily implemented considering the audience of this bug. But IMHO, it is not nice. Why retain Debian specific hack in the installer pcmcia-cs udeb system which has no need to have compatibility with ifupdown package of Potato. > 2. pcmcia-cs does not ifup/ifdown interfaces on 16 bit PCMCIA cards >by default (which requires a change to pcmcia-cs) and hw-detect >lists such interfaces in /etc/network/devhotplug (as now). Yes. This will be nice since these ifup/ifdown hack in pcmcia-cs is Debian specific hack added in pre-Woody days. I like to see this but the pcmcia-cs maintainer looks like he is determined to keep current feature with good reason. As I see, the only compromise pcmcia-cs maintainer may accept should be the one which he does not need to worry about uses complaining unhappy upgrade experiences. Thomas, is it possible for you to provide debconf low priority question to customize pcmcia-cs in traditional ways with ifup/ifdown hack (default of pcmcia-cs package) and alternatively to customize pcmcia-cs without old Debian ifup/ifdown hack (seeded by debian-installer). This is like new hotplug package. This should give people upgrading from Woody smooth transition while fresh Sarge install can get nice hotplug enabled system. ... wait pcmcia-cs package you are talking may be udeb. Well, in that case, we can share code base with updated deb package, isn't it? Just a thought... (By the way, tc1 CD was detecting 16bit PCMCIA NIC but recent sid-di are not detecting 16bit PCMCIA NIC any more. A bit wondering.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh support for notebooks :) --> screen?
On Sun, Jun 27, 2004 at 08:21:18PM +0100, Colin Watson wrote: > On Sun, Jun 27, 2004 at 01:56:24PM +0200, Osamu Aoki wrote: > > I am wondering if ssh can be supported for normal d-i initrd too. > > > > Most importantly, scp. > > > > This is because many new PC comes without floppy to save failed install > > except to USB or HDD. SCP makes it easy to copy the log. This should > > make failed install easier to debug as long as network is alive. > > > > At lease inclusion of some ssh package to the pool/* will be nice for > > netinst CD. > > openssh-client-udeb. I didn't package scp because it's straightforward > to do the same thing with ssh and tar, but I suppose I could add it. openssh-client-udeb is sufficient for me. I only meant some SCP like functionality. I really doubt needs to login to another machine from a machine running on initrd. So really stripped down ssh shall be enough (no X forwarding etc.) Just nit pick. It is ssh+cat == scp. 'scp foo [EMAIL PROTECTED]:bar' is like 'bar"'. "tar" is a sepatete issue although it is an idiom used with ssh to move multiple files. (These files will not be concatenated if moved with ssh+tar in the famous way.) > If we're going to have scp we should also have sftp; scp is badly > designed, inextensible, and should eventually die. True. Code choice for udeb should be minimalistic. By the way, speaking of basic functionality of initrd, I do not see "screen" command missing in initrd nor in pool/* as udeb. I wonder how you are handling some operations which kill the remote terminal connection used for the install. It will interrupt install process unless "screen" like commands are used. Just an innocent question without much thought. So excuse me if I am asking some obvious. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#255128: cdrom-detect --> pcmcia trouble in sid
On Sun, Jun 27, 2004 at 10:37:53PM +0200, Osamu Aoki wrote: > PS: I noticed that business card CD does not support PCMCIA card > services. 3 floppies did better job for PCMCIA on my another i486 > machine. I do not have floppy on Dell so these modules could not be > made available (I did not bothered to burn another CD just for these > modules either). Pity, Dell can not read CD-RW and this each trial is > making another silver disk. > Wait. This problem is sid problem. both netinst and busines card suffer. pcmcia-core is looked for while pcmcia_core modules are used. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#255128: cdrom-detect: Bad handling of mount error
On Sun, Jun 27, 2004 at 01:12:11PM -0400, Joey Hess wrote: > Osamu Aoki wrote: > > Busybox does not have "sleep" on this version. (Why?) > > Just to save space, though I understand it's in sid now. Yes. I though I saw sleep somewhere. That was sid CD :-) > > I will put updated patch, iso-image example, syslog-commented, etc at > > > > http://people.debian.org/~osamu/pub/d-i/ > > > > It works but I think following messages after Detecting CD needs to be > > understood before applying. > > > > | Jun 26 19:34:27 (none) user.notice cdrom-detect: Detected CD with 'testing' > > distribution > > | Jun 26 19:34:27 (none) user.info main-menu[297]: (process:454): mount: Mounting > > /dev/cdroms/cdrom0 on /cdrom failed: Not a directory > > | Jun 26 19:34:27 (none) user.info main-menu[297]: (process:454): umount: > > | Jun 26 19:34:27 (none) user.info main-menu[297]: (process:454): /cdrom > > | Jun 26 19:34:27 (none) user.info main-menu[297]: (process:454): : Invalid > > argument > > Hmm, I didn't think that main-menu did stderr interception and logging > any more. It should just be redirected to the messages file these days. This "Jun 26 19:34:27 (none) user.info main-menu[297]: (process:454):..." types of delayed logging still happens on my new try with sid (20040626) trial. In both case, CD are correctly mounted without issue. Yes on this machine, sleep works but since without the insertion of sleep works fine, I think I want to do without it. Now that I verified with tc1 and 20040626-sid image. Osamu PS: I noticed that business card CD does not support PCMCIA card services. 3 floppies did better job for PCMCIA on my another i486 machine. I do not have floppy on Dell so these modules could not be made available (I did not bothered to burn another CD just for these modules either). Pity, Dell can not read CD-RW and this each trial is making another silver disk. signature.asc Description: Digital signature
Bug#256547: installation-reports: i486 with 20 MB lowmem+floppy fails as expected
Package: installation-reports
Version: floppy image in tc1 (2004-05-30 22:19)
Severity: normal
Machine: IBM Thinkpad230Cs
Processor: 80486 DX2 50 MHz
Memory: 20 MB (4MB+16MB, Max)
Root Device: IDE (Upgraded to 2GB)
Root Size/partition table:
hda1 ext3 (woody system was going to be wiped and over written)
hda5 swap
... more ext2 FS for woody
Output of lspci:
N/A now.
Failed to install as expected :)
Base System Installation Checklist: (No special action, linux)
Initial boot worked:[O] Mention low mem.
Configure network HW: [O]
Config network: [O]
Detect CD: [N/A] (Floppy/network install)
Load installer modules: [E] Without swap, it failed as expected
...
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
Base System Installation Checklist: (Boot with expert)
Initial boot worked:[O] Mention low mem.
Load deiver from floppy:[O] net-drivers.img
Choose language:[O]
Choose country: [O] Belgium/English/PC-AT/us
Detect network: [O] Start PC card yes:
complain about lack of modules such as ide-detect, ide-*, isofs
Configure network HW: [O] Yes DHCP without DHCP hostname
Config network: [O]
At this stage, ide modules are not available.
Load installer modules: [ ]
manually just select installer components only.
it install many modules such as lowmem again here.
Are they needed?
Abort at lvm2-udeb (Free/MEM is 636) same as above.
Go to console and I could activate swap using devfs device name but too
late.
Detect CD: [N/A]
-
Memo:
I was pleasantly surprised to see my old PC card (16bit) NIC was
working.
Considering for most people installing lowmem, lvm2-udev etc are not
needed. So if lowmem flags some packages out of initial downloads, I
may have survived. (Do not download in one action. Just download
first set and prompt for user interaction only for lowmem, then install
the rest.)
As I think about it, I just need some way to selectively install modules
(I am sure there is but it is not obvious) such as ide normal modules
so swap can be easily activated. For lowmem, I think ide-detect module
etc. needs to be there before normal action of installer modules. This
will give access to swap so memory will not run out so easily.
If there is a small optional module to activate some hard disk partition
automatically, I think lowmem support will be greater.
Osamu
--
~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ +
Osamu Aoki <[EMAIL PROTECTED]> Brussels Belgium, GPG-key: A8061F32
.''`. Debian Reference: post-installation user's guide for non-developers
: :' : http://qref.sf.net and http://people.debian.org/~osamu
`. `' "Our Priorities are Our Users and Free Software" --- Social Contract
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian installation enviroment
On Sun, Jun 27, 2004 at 01:48:58PM +0200, Fredrik Johnsson wrote: > Hi! > > Seams I'll have to refrase it a bit. > > Currently I'm trying to find out what deps the program dbootstrap on > woody cdinstallation has regarding libraries, enviroment variables and > other commands,program (fdisk, mke2fs and such). Hmm... You seem to need some basic Debian dependency handling info. I think you should go to http://www.debian.org/devel/ (Or http://www.nl.debian.org/devel/) Start with http://www.nl.debian.org/doc/maint-guide/ Then move at leat to http://www.nl.debian.org/doc/developers-reference/ http://www.nl.debian.org/doc/debian-policy/ and read these fine documents for the developers and developers-to-be. If these are too technical, you may want to read some Debian specific user oriented intro guides like mine: http://www.nl.debian.org/doc/user-manuals#quick-reference Also this is for new d-i, another intro for playing with installer media by me may be useful for handling disk image files. http://people.debian.org/~osamu/hackdi > I need to know every file and enviroment variable that is the bare > necessities for it to run on the cd. Have you looked into debian/control file in the Debianized source especially Depends: field. > And I would like to recreate this > in a chroot enviroment for testing purposes. Wow, ... this will be nice but may not be so trivial as I see how people are developing boot loader. You can certainly build chroot in installer initrd type system but that only gives partial test of installer. > It might be that I could read out most of it from the source, but I > don't know where to find the source for bootstrap As others has suggested use "apt-get source" if you know the name of the source. signature.asc Description: Digital signature
