Bug#1021918: debian-installer: Kernel module blacklisting inconsistent
Hi again, Olaf Meeuwissen writes: > Sorry for the belated follow-up. > > Pascal Hambourg writes: > >> On 22/10/2022 at 03:39, Olaf Meeuwissen wrote: >>> Pascal Hambourg writes: >>>> On 17/10/2022 at 13:13, Olaf Meeuwissen wrote: >>>>> I recently tried this version with hardware that triggers loading of the >>>>> mt7921e kernel module. Loading the module fails due to a firmware file >>>>> load error but the installer starts okay. However, the installer later >>>>> crashes when probing for network hardware (when it tries to rmmod the >>>>> kernel module). >>>> >>>> How does the installer crash exactly ? Kernel panic ? Freeze ? Error ? >>> Freeze. Even after ten minutes the network hardware probe does not >>> complete. FWIW, I have seen an error log as well but that may have >>> been with Devuan's preview installer for daedalus. >> >> I could not reproduce this after tricking the installer into unloading >> and reloading the mt7921e module. The module unloads and reloads >> cleanly. But I do not have any hardware matching this module. > > The freeze probably only occurs when an attempt to loadh the firmware > file is made. Unlikely that will happen if the hardware is not found. > Anyway, this issue is not with this particular kernel module but with > the installer's inconsistent module blacklisting behaviour. > > FWIW, I've since installed firmware-misc-nonfree and removed all the > blacklisting bits for the module. WiFi works fine. > >>> I've attached the installer's syslog. /dev/sdc is the installer ISO. >>> The other disks, /dev/sda, /dev/sdb and /dev/nmve0n1 are the machine's >>> internal disks. I just ran the installer after the machine was already >>> installed with the workaround I mentioned in the original bug report. >>> The error starts at >>>Oct 19 23:06:13 check-missing-firmware: removing and loading >>> kernel module mt7921e >> >>> Oct 19 23:06:13 kernel: [ 40.024088] BUG: unable to handle page >>> fault for address: 6500 >>> Oct 19 23:06:13 kernel: [ 40.024092] #PF: supervisor write access in >>> kernel mode >>> Oct 19 23:06:13 kernel: [ 40.024094] #PF: error_code(0x0002) - >>> not-present page >> (...) >>> Oct 19 23:06:13 kernel: [ 40.024120] Call Trace: >>> Oct 19 23:06:13 kernel: [ 40.024121] >>> Oct 19 23:06:13 kernel: [ 40.024124] __cancel_work_timer+0x3c/0x190 >>> Oct 19 23:06:13 kernel: [ 40.024128] ? __kernfs_remove.part.0+0x190/0x2b0 >>> Oct 19 23:06:13 kernel: [ 40.024131] mt7921_pci_remove+0x2c/0x110 >>> [mt7921e] >> >> It looks like a kernel bug when unloading this module. Can you trigger >> the bug in an installed system ? If yes it means that it not specific >> to the installer. > > Machine's at the office, will see if I can test tomorrow or the day after. Checked this morning. With the firmware file loaded, rmmod succeeds without problems. With the firmware file not loaded, trying to rmmod it echoes "Killed" on the command-line and created a longish call trace in /var/log/kern.log. Not sure if it was the same, though. >>>>> The first issue I ran into was that the documented[1] way to blacklist >>>>> kernel modules is no longer correct >>>>>[1]: >>>>> https://www.debian.org/releases/testing/amd64/ch05s03.en.html#module-blacklist >>>>> Instead of >>>>> mt7921e.blacklist=yes >>>>> I had to use >>>>> modprobe.blacklist=mt7921e >>>> >>>> /lib/debian-installer-startup.d/S02module-params has the following comment: >>>> >>>> # Before udev is started, parse kernel command word for module params of >>>> # the form module.param=value and register them so they will be used when >>>> # modules are loaded. Also check for modules to be blacklisted. >>>> >>>> But udev is actually started earlier, so the first method does not >>>> work with modules included in initrd.gz (e.g. storage drivers). >>> In that case, shouldn't that be mentioned in the installation >>> manual? >>> Actually, a single method that works for *all* modules, whether in the >>> initrd.gz or installed later is much preferred. >>> >>>> However it should work with network driver modules which are installed >>>> much later. >>> You may want to double check how the kernel command parse results >>> are >>> use
Bug#1021918: debian-installer: Kernel module blacklisting inconsistent
Sorry for the belated follow-up. Pascal Hambourg writes: > On 22/10/2022 at 03:39, Olaf Meeuwissen wrote: >> Pascal Hambourg writes: >>> On 17/10/2022 at 13:13, Olaf Meeuwissen wrote: >>>> I recently tried this version with hardware that triggers loading of the >>>> mt7921e kernel module. Loading the module fails due to a firmware file >>>> load error but the installer starts okay. However, the installer later >>>> crashes when probing for network hardware (when it tries to rmmod the >>>> kernel module). >>> >>> How does the installer crash exactly ? Kernel panic ? Freeze ? Error ? >> Freeze. Even after ten minutes the network hardware probe does not >> complete. FWIW, I have seen an error log as well but that may have >> been with Devuan's preview installer for daedalus. > > I could not reproduce this after tricking the installer into unloading > and reloading the mt7921e module. The module unloads and reloads > cleanly. But I do not have any hardware matching this module. The freeze probably only occurs when an attempt to loadh the firmware file is made. Unlikely that will happen if the hardware is not found. Anyway, this issue is not with this particular kernel module but with the installer's inconsistent module blacklisting behaviour. FWIW, I've since installed firmware-misc-nonfree and removed all the blacklisting bits for the module. WiFi works fine. >> I've attached the installer's syslog. /dev/sdc is the installer ISO. >> The other disks, /dev/sda, /dev/sdb and /dev/nmve0n1 are the machine's >> internal disks. I just ran the installer after the machine was already >> installed with the workaround I mentioned in the original bug report. >> The error starts at >>Oct 19 23:06:13 check-missing-firmware: removing and loading >> kernel module mt7921e > >> Oct 19 23:06:13 kernel: [ 40.024088] BUG: unable to handle page fault for >> address: 6500 >> Oct 19 23:06:13 kernel: [ 40.024092] #PF: supervisor write access in >> kernel mode >> Oct 19 23:06:13 kernel: [ 40.024094] #PF: error_code(0x0002) - not-present >> page > (...) >> Oct 19 23:06:13 kernel: [ 40.024120] Call Trace: >> Oct 19 23:06:13 kernel: [ 40.024121] >> Oct 19 23:06:13 kernel: [ 40.024124] __cancel_work_timer+0x3c/0x190 >> Oct 19 23:06:13 kernel: [ 40.024128] ? __kernfs_remove.part.0+0x190/0x2b0 >> Oct 19 23:06:13 kernel: [ 40.024131] mt7921_pci_remove+0x2c/0x110 >> [mt7921e] > > It looks like a kernel bug when unloading this module. Can you trigger > the bug in an installed system ? If yes it means that it not specific > to the installer. Machine's at the office, will see if I can test tomorrow or the day after. >>>> The first issue I ran into was that the documented[1] way to blacklist >>>> kernel modules is no longer correct >>>>[1]: >>>> https://www.debian.org/releases/testing/amd64/ch05s03.en.html#module-blacklist >>>> Instead of >>>> mt7921e.blacklist=yes >>>> I had to use >>>> modprobe.blacklist=mt7921e >>> >>> /lib/debian-installer-startup.d/S02module-params has the following comment: >>> >>> # Before udev is started, parse kernel command word for module params of >>> # the form module.param=value and register them so they will be used when >>> # modules are loaded. Also check for modules to be blacklisted. >>> >>> But udev is actually started earlier, so the first method does not >>> work with modules included in initrd.gz (e.g. storage drivers). >> In that case, shouldn't that be mentioned in the installation >> manual? >> Actually, a single method that works for *all* modules, whether in the >> initrd.gz or installed later is much preferred. >> >>> However it should work with network driver modules which are installed >>> much later. >> You may want to double check how the kernel command parse results >> are >> used then. > > I did, and .blacklist works as expected with NIC modules > matching my hardware (iwlwifi and e1000e). I meant double check by reading the source code, not by trying with some rather commonly used modules. >> Or maybe the mt7921e module is in the initrd.gz? >> Just checked, it is not. > > Indeed, it is in the package nic-wireless-modules--di. > >>>> However, upon booting I saw a pile of ATA bus and I/O errors that made >>>> me suspicious. The disk is brand new and a smartmontools extended test >>>> reports no errors. >>>> I found a /etc/modprobe.d/blacklist.local.c
Bug#1021918: debian-installer: Kernel module blacklisting inconsistent
Pascal Hambourg writes: > On 17/10/2022 at 13:13, Olaf Meeuwissen wrote: >> I recently tried this version with hardware that triggers loading of the >> mt7921e kernel module. Loading the module fails due to a firmware file >> load error but the installer starts okay. However, the installer later >> crashes when probing for network hardware (when it tries to rmmod the >> kernel module). > > How does the installer crash exactly ? Kernel panic ? Freeze ? Error ? Freeze. Even after ten minutes the network hardware probe does not complete. FWIW, I have seen an error log as well but that may have been with Devuan's preview installer for daedalus. You can still switch VTs but trying to `poweroff` or `reboot` after starting a shell on VT2 or VT3 will also freeze. The last bit of the error can be seen on VT4. I've attached the installer's syslog. /dev/sdc is the installer ISO. The other disks, /dev/sda, /dev/sdb and /dev/nmve0n1 are the machine's internal disks. I just ran the installer after the machine was already installed with the workaround I mentioned in the original bug report. The error starts at Oct 19 23:06:13 check-missing-firmware: removing and loading kernel module mt7921e and looks like what I've seen on VT4. >> The first issue I ran into was that the documented[1] way to blacklist >> kernel modules is no longer correct >> [1]: >> https://www.debian.org/releases/testing/amd64/ch05s03.en.html#module-blacklist >> Instead of >>mt7921e.blacklist=yes >> I had to use >>modprobe.blacklist=mt7921e > > /lib/debian-installer-startup.d/S02module-params has the following comment: > > # Before udev is started, parse kernel command word for module params of > # the form module.param=value and register them so they will be used when > # modules are loaded. Also check for modules to be blacklisted. > > But udev is actually started earlier, so the first method does not > work with modules included in initrd.gz (e.g. storage drivers). In that case, shouldn't that be mentioned in the installation manual? Actually, a single method that works for *all* modules, whether in the initrd.gz or installed later is much preferred. > However it should work with network driver modules which are installed > much later. You may want to double check how the kernel command parse results are used then. Or maybe the mt7921e module is in the initrd.gz? Just checked, it is not. >> However, upon booting I saw a pile of ATA bus and I/O errors that made >> me suspicious. The disk is brand new and a smartmontools extended test >> reports no errors. >> I found a /etc/modprobe.d/blacklist.local.conf file with >>blacklist modprobe > > This is a minor bug in > /lib/debian-installer-startup.d/S02module-params which can be easily > fixed. However, it should not have any actual impact as "modprobe" > does not match any kernel module name or alias. Strange, because removing it made those ATA bus and I/O errors go away, reproducibly at that. >> For completeness' sake, the /etc/default/grub file included >>GRUB_CMDLINE_LINUX="modprobe.blacklist=mt7921e" > > As expected. I have since removed that blacklist statement and installed firmware-misc-nonfree. That makes the firmware load without any trouble. >> Seeing that the kernel boot argument is added correctly to the GRUB >> configuration, there is no need to create a file in /etc/modprobe.d/. >> In addition, the installation manual needs to be updated to use the >> correct syntax. > > If I understand correctly, this is how things work: > > The kernel runs /init. > /init runs /lib/debian-installer/start-udev which starts udevd. > udevd gets hotplug events and calls modprobe to load matching modules > included in initrd.gz. > Then /init exec's /bin/busybox init. Since there is no mt7921e module in the initrd.gz, in fact no modules matching mt7, it should not have been loaded at this point according to your understanding. > busybox init reads /etc/inittab and runs /sbin/debian-installer-startup. > debian-installer-startup runs > /lib/debian-installer-startup.d/S02module-params. > /lib/debian-installer-startup.d/S02module-params calls > /bin/register-module for each module parameter or blacklist in the > kernel command line. That appears to work but blacklisting syntax is *not* as documented in the installation manual. > register-module writes module blacklists in > /etc/modprobe.d/blacklist.local.conf and module parameters in > /etc/modprobe.d/local.conf. The blacklist.local.conf file is created as documented but using the alternative syntax I had to use leads to the oxymoronic blacklist modprobe entry, trying to tell modprobe to blacklist itself :-) You mentioned above th
Bug#1021918: debian-installer: Kernel module blacklisting inconsistent
Package: debian-installer Version: 20220917 Severity: normal Tags: d-i Dear Maintainer, I recently tried this version with hardware that triggers loading of the mt7921e kernel module. Loading the module fails due to a firmware file load error but the installer starts okay. However, the installer later crashes when probing for network hardware (when it tries to rmmod the kernel module). Since the hardware has 2 additional wired NICs that work fine (and I wanted to do an air-gap install anyway!), I decided to blacklist the module. The first issue I ran into was that the documented[1] way to blacklist kernel modules is no longer correct [1]: https://www.debian.org/releases/testing/amd64/ch05s03.en.html#module-blacklist Instead of mt7921e.blacklist=yes I had to use modprobe.blacklist=mt7921e to prevent the kernel from loading the module (between the boot menu and starting the installer proper). With the latter appended to the `linux` line of the boot menu entry, the installation appeared to have completed without problems. However, upon booting I saw a pile of ATA bus and I/O errors that made me suspicious. The disk is brand new and a smartmontools extended test reports no errors. I found a /etc/modprobe.d/blacklist.local.conf file with blacklist modprobe Removing that file made the ATA bus and I/O errors go away. For completeness' sake, the /etc/default/grub file included GRUB_CMDLINE_LINUX="modprobe.blacklist=mt7921e" so the offending module is not loaded upon reboot after installation. Seeing that the kernel boot argument is added correctly to the GRUB configuration, there is no need to create a file in /etc/modprobe.d/. In addition, the installation manual needs to be updated to use the correct syntax. Hope this helps, -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-3-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) LSM: AppArmor: enabled -- Olaf Meeuwissen
Bug#370462: Serial ATA-2 Athlon 64 X2 installation report
Joey Hess [EMAIL PROTECTED] writes: Olaf Meeuwissen wrote: --- Emacs Muse notes I took while installing, wiki markup alert --- Press F1 for help, or ENTER to boot :: nah! I want control, so let's boot using =expert= mode and set the boot keyboard to =jp106= rightaway. It took me a while to figure out that you are apparently supposed to hit _Enter_ when you see =SET debian-installer/keymap jp106=, and again at =FSET debian-installer/keymap seen yes= before the installer continues. Eh, what? Why was the installer taking raw debconf protocol to you? No idea. I just said: expert bootkbd=jp106 at the bootprompt and that's what I got. Note though, that this happened not only with the beta2 installer but also with the 20060525 snapshot. I've had a look at the logs in /var/log/installer, but the only odd thing I could find was this (from beta2, note line marked with ): Jun 3 06:26:12 kernel: Probing IDE interface ide1... Jun 3 06:26:12 kernel: ieee1394: Host added: ID:BUS[0-00:1023] GUID[0010dccb7904] Jun 3 06:26:13 S30read-environment: Setting debconf/priority to 'low'. Jun 3 06:26:13 frontend: Setting debconf/priority to low Jun 3 06:26:13 kernel: vga16fb: initializing Jun 3 06:26:13 kernel: vga16fb: mapped to 0x810a Jun 3 06:26:13 kernel: Console: switching to colour frame buffer device 80x30 Jun 3 06:26:13 kernel: fb0: VGA16 VGA frame buffer device Jun 3 06:26:13 kbd-chooser[3284]: INFO: kbd_chooser: setting keymap jp106 Jun 3 06:26:16 kernel: Vendor: Generic Model: STORAGE DEVICERev: 9317 Jun 3 06:26:16 kernel: Type: Direct-Access ANSI SCSI revision: 00 Jun 3 06:26:16 kernel: sd 5:0:0:0: Attached scsi removable disk sdb Jun 3 06:26:16 kernel: Vendor: Generic Model: STORAGE DEVICERev: 9317 Jun 3 06:26:16 kernel: Type: Direct-Access ANSI SCSI revision: 00 Jun 3 06:26:16 kernel: sd 5:0:0:1: Attached scsi removable disk sdc Jun 3 06:26:16 kernel: usb-storage: device scan complete Jun 3 06:26:35 init: ^MStarting pid 3339, console /dev/vc/1: '/sbin/debian-installer' Jun 3 06:26:35 init: ^MStarting pid 3347, console /dev/vc/3: '/usr/bin/tail' Jun 3 06:26:35 init: ^MStarting pid 3350, console /dev/vc/4: '/usr/bin/tail' Jun 3 06:26:35 main-menu[3375]: DEBUG: Executing /lib/main-menu.d/10rescue Jun 3 06:26:35 main-menu[3375]: DEBUG: Executing /lib/main-menu.d/5lowmem Jun 3 06:26:35 main-menu[3375]: DEBUG: resolver (libc6): package doesn't exist (ignored) Jun 3 06:26:35 main-menu[3375]: DEBUG: resolver (libdebian-installer4): search, dependency from cdebconf-udeb Jun 3 06:26:35 main-menu[3375]: DEBUG: resolver (libdebian-installer4-udeb): mark, dependency from cdebconf-udeb For the rest there are two mentions of bootkbd=jp106 when the kernel command line is logged before the above extract from the syslog file. When that SET debian-installer/keymap jp106 is shown on the screen I can not switch VTs. The three finger salute works, though. # Cmpletely unrelated, my system clock is running at double speed. # Mighty annoying. It seems to be a well-known and old problem, though. Hope this helps, -- Olaf Meeuwissen FSF Associate Member #1962 sign up at http://member.fsf.org/ GnuPG key: 30EF893A/2774 815B DE83 06C8 D733 6B5B 033C C857 30EF 893A Penguin's lib! -- I hack, therefore I am -- LPIC-2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370462: Serial ATA-2 Athlon 64 X2 installation report
a while but completes fine after selecting a kernel. I used =kernel-image-2.6-amd64-generic=. Configure the package manager :: to use *neither* =non-free= nor =contrib= software. The installer then failed to access the mirror. Obvious, of course, because I didn't choose one and the machine is not connected to the network to begin with. Just =Ignore= that as well as the warning about the entry for =security.debian.org=. Select and install software :: for a =Standard system=, which installs some six extra packages. Install the GRUB boot loader on a hard disk :: into the master boot record and set a password. Oops, you're not asked to retype the password ... -- used sparrow Finish the installation :: ejects the CD-ROM and reboots smoothly into a freshly installed Debian GNU/Linux testing Etch system. --- end of my installation notes --- I was slightly surprised not to find lspci. It gets hard filling out this report without ;-) One more thing, in retrospect I think that 2.9GB for swap is overdoing it a bit when you have 1.0GB of memory. -- Olaf Meeuwissen FSF Associate Member #1962 sign up at http://member.fsf.org/ GnuPG key: 30EF893A/2774 815B DE83 06C8 D733 6B5B 033C C857 30EF 893A Penguin's lib! -- I hack, therefore I am -- LPIC-2 debian-installer-logs.tar.gz Description: files in /var/log/debian-installer/
Debian on a Toshiba SS S4/275PNHW
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I've installed Debian on a Toshiba SS S4/275PNHW (a while back already) and finally got around to putting together a diff against boot-floppies that is needed to install. # I got a little distracted trying to return the pre-loaded OS and still am :-| (see http://www13.0038.net/~olaf/no-return.en.html for details). This laptop has neither internal CD-ROM, nor internal floppies so some boot-floppies patching was required to get it going. I don't know if this model is available outside Japan. Toshiba recently released two derived models, the S5/280PNKW and S5/280PNLN , that should be installable with my customized boot floppies. # Note, I do not recommend any of these computers. As a matter of fact, I'd recommend you buy *no* Toshiba products at all if you care about your rights as a customer. I've installed on my S4/275PNHW in a variety of ways using these patched boot-floppies and a set of woody pre-release CD-ROMs: bootkernel/drivers base system smart media USB floppy USB CD-ROM USB floppy USB floppy USB CD-ROM smart media USB stick drive USB CD-ROM I haven't tried but am pretty sure you could even install from a single USB stick drive (using the 2.88MB floppy image and a minimal file system containing the kernel, drivers and base system packages in the right places). Anyway, the patch and instructions to build custom boot floppies are available via: http://www13.0038.net/~olaf/floppies.en.html Time permitting, I'll polish up and add my installation/configuration notes. - -- Olaf Meeuwissen GnuPG key: 91114EAF/C3E1 2D40 C7CC AEB2 FB15 8BDF 60C2 5B3F 9111 4EAF -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE92htmYMJbP5ERTq8RAnj5AJ4s0UZZ/IY+9ZNsftUn7eH2ozkNNQCfWFik EHZhhgejMg9F+e/XPUsVt4o= =oMWx -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BiDi and RTL
Chris Tillman [EMAIL PROTECTED] writes: My reasoning is there will be so little use of floppies from here on out. CD's are ubiquitous, the energy we spend making the installer fit in 1.4MB would be far better spent making our CD (and mini-CD) installation flawless, and concentrating on better network (nfs/bootp/etc.) support. There seems to be a trend amongst the mobile laptops to NOT have a CD drive. You will need an external USB CD drive and the BIOS may not support booting off it. For example, Toshiba's Dynabook SS S4/275PNHW is such a beast and it only boots off the CD drives made by Toshiba. # I believe they call this legacy-free USB support or something. However, booting from an external USB floppy drive works with any ol' drive, so you might want to keep those floppies around for a bit. BTW, this machine can boot of a PC card, so I ended up installing from a home-brew 2.88Mb floppy image on smart media, installed the drivers from floppy (the PC card was invisible after the boot) and pulled in the rest from CD ;-) # MY IO Data CD drive works fine, I just can't boot off it :-( FYI, http://dynabook.com/pc/catalog/ss_c/020121s4/index_j.htm Sorry, but in Japanese only I'm afraid. -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Demographic analysis of debian user's language (was Re: b-f one-liner needs translating
Javier Fernández-Sanguino Peña [EMAIL PROTECTED] writes: On Tue, Mar 05, 2002 at 08:07:57AM +0900, Olaf Meeuwissen wrote: Question. How many Catalan speakers will be unable to get by with one of the es, fr or maybe even pt versions? I do not want to go over a language-battle but most of the people Jordi pointed out would be able to use 'es' or 'fr' installations. However, they would probably be more comfortable by using their main language. Neither do I, but when we are talking priorities for inclusion I would weigh this kind of information rather heavily. So if it were up to me (which it isn't), I would not chop Polish in favour of Catalan; and if there is going to be more languages on a second floppy (hi Claus), I'd probably put Catalan there and leave Polish on the first. -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: b-f one-liner needs translating
Phil Blundell [EMAIL PROTECTED] writes: Do you have statistics for the number of Catalan speakers who don't also speak one of the other supported languages? For example, there would be less advantage in adding it if, say, the existing French translation is actually usable by 50% of the Catalan-speaking population. Question. How many Catalan speakers will be unable to get by with one of the es, fr or maybe even pt versions? # I have no idea how close the languages are, but methinks most people # would at least be rather heavily exposed to one of these. -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#77487: md5sum.txt file for disks-i386 doesn't match files on server
Adam Di Carlo [EMAIL PROTECTED] writes:
I cannot reproduce this problem:
Dang!
aph@auric:current /bin/pwd
/org/ftp.debian.org/ftp/dists/potato/main/disks-i386/2.2.17-2000-11-11
aph@auric:current md5sum -c md5sum.txt
aph@auric:current echo $?
0
aph@auric:current grep README.txt md5sum.txt
927867784500d50707de22435da7f101 ./README.txt
194304eee103ab6e05ea733c08121ca8 ./images-2.88/udma66/README.txt
25b8c189c34da19bbe2eb92d970cc4dd ./images-2.88/idepci/README.txt
What's the beef?
Wish I knew. Looks like my /usr/bin/md5sum is weird.
olaf@bilbo:[...]/2.2.17-2000-11-11$ md5sum -cv md5sum.txt
md5sum: can't open ./README.txt
md5sum: can't open ./READ-pl.txt
md5sum: can't open ./dosutils/setlang.bat
md5sum: can't open ./dosutils/rawrite2.exe
md5sum: can't open ./dosutils/rawrite2.txt
md5sum: can't open ./dosutils/loadlin.exe
[...]
olaf@bilbo:[...]/2.2.17-2000-11-11$ ls -l ./READ* ./dosutils/
-rw-r--r--1 olaf mirror 6366 Sep 30 17:23 ./READ-pl.txt
-rw-r--r--1 olaf mirror 6163 Sep 30 17:23 ./README.txt
./dosutils/:
total 60
-rw-r--r--1 olaf mirror 32208 Sep 30 17:26 loadlin.exe
-rw-r--r--1 olaf mirror 17863 Oct 31 09:40 rawrite2.exe
-rw-r--r--1 olaf mirror 1671 Mar 7 1996 rawrite2.txt
-rw-r--r--1 olaf mirror928 Sep 30 17:26 setlang.bat
olaf@bilbo:[...]/2.2.17-2000-11-11$ md5sum ./READ* ./dosutils/
bb11aaadd6f882502a46b9e5009798dd ./READ-pl.txt
17eed5c36e647abf6ee9c9879e6e902a ./README.txt
81d0270ee44075a1afb88b0aedcd27fe ./dosutils/loadlin.exe
d8a0e813566f75d6208b7376c9d9fc18 ./dosutils/rawrite2.exe
a9fd62a293f2385ae460050bc2fbede4 ./dosutils/rawrite2.txt
b5a971f1d9d9001ea9c28edd9cc9e786 ./dosutils/setlang.bat
olaf@bilbo:[...]/2.2.17-2000-11-11$ grep ./READ md5sum.txt
927867784500d50707de22435da7f101 ./README.txt
ddb842488ffa4b8f66e7a31ea199ef7e ./READ-pl.txt
[...]
olaf@bilbo:[...]/2.2.17-2000-11-11$ grep ./dosutils/
b5a971f1d9d9001ea9c28edd9cc9e786 ./dosutils/setlang.bat
d8a0e813566f75d6208b7376c9d9fc18 ./dosutils/rawrite2.exe
9eaa2b84c0e6e5fc6da673626cec9f06 ./dosutils/rawrite2.txt
81d0270ee44075a1afb88b0aedcd27fe ./dosutils/loadlin.exe
Looks like only *.txt files give the wrong checksums. Still mistified
on why I get the can't open errors. I have rw access on the files, so
what gives? Running md5sum with a daily computed list of all files on
the system works fine (compensating for access permissions). That in-
cludes 2.2.17-2000-11-11.
Hmmm, got a hunch here ... let's check ...
olaf@bilbo:[...]/2.2.17-2000-11-11$ hexdump -c md5sum.txt
000 9 2 7 8 6 7 7 8 4 5 0 0 d 5 0 7
010 0 7 d e 2 2 4 3 5 d a 7 f 1 0 1
020 . / R E A D M E . t x t \r \n
030 d d b 8 4 2 4 8 8 f f a 4 b 8 f
040 6 6 e 7 a 3 1 e a 1 9 9 e f 7 e
050 . / R E A D - p l . t x t \r
060 \n b 5 a 9 7 1 f 1 d 9 d 9 0 0 1
See the end of that third line, \r\n, hmmm, that looks very DOSish and
is bound to trip up md5sum. Same thing in README.txt. Bet the other
text files have the same problem. Oops, looks like I used an FTP URL
and got bitten by the infamous binary/ascii download no-no courtesy of
wget :-{
Sorry for the false alarm!
Is this bug closable?
Yes. And thanks for making me do my homework ;-)
--
Olaf Meeuwissen Epson Kowa Corporation, Research and Development
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
