Re: Contacting Debian Boot team
Hi Andreas, On 2024-06-06 04:38, Andreas Tille wrote: > Any experiences with Lenovo Thinkpad X13S? Finally Lenovo is present on > DebConfs and we can talk to them. Just from reading[1] it seems to be > what I'm looking for in principle - provided they might unbundle Win11 > from it and I can just plugin the Debian installer USB to install > Debian. Trixie runs fine on it, though there are some rough edges. Full details on https://wiki.debian.org/InstallingDebianOn/Thinkpad/X13s For details of the work done on the kernel/installer/cd/live images: https://wiki.debian.org/DebianEvents/gb/2023/MiniDebConfCambridge/Rocca ema
Bug#1063413: FTBFS: cannot open /<>/Keyboard/pc105.ekbd: No such file
Hi, On 2024-02-08 02:06, Colin Watson wrote: > On Wed, Feb 07, 2024 at 11:13:01PM +0100, Holger Wansing wrote: > > Am 7. Februar 2024 21:55:05 MEZ schrieb Emanuele Rocca : > > >Perhaps this is related to the fact that 1.224 dropped the binary > > >package console-setup-pc-ekbd? > > > > What makes you think, that this has happened? > > > > There is a merge request that includes the removal of said package, > > but it has not yet been merged. Looks like the change has been uploaded though, there is no console-setup-pc-ekbd here: https://sources.debian.org/src/console-setup/1.224/debian/control/ But on 1.223 it's there: https://sources.debian.org/src/console-setup/1.223/debian/control/#L161 > My inclination is to upload 1.225 without that patch for now, as we need > to rebuild for the new xkb-data to sort out uninstallability in > unstable, and then get the kFreeBSD-removal patch sorted out after that. > Objections? That sounds good to me, thanks Colin.
Bug#1063413: FTBFS: cannot open /<>/Keyboard/pc105.ekbd: No such file
Source: console-setup Version: 1.224 Severity: serious Justification: fails to build from source (but built successfully in the past) Tags: sid trixie ftbfs Dear Maintainer, console-setup 1.224 fails to build from source with the following error: Dumping the encoded keymaps for pc105... WARNING: Can not find "caps_switch" in "group". WARNING: Can not find "caps_toggle" in "group". gzip -9n >/Keyboard/pc105.ekbd >/<>/Keyboard/pc105.ekbd.gz /bin/sh: 1: cannot open /<>/Keyboard/pc105.ekbd: No such file make[1]: *** [rules.mk:17: /<>/Keyboard/pc105.ekbd.gz] Error 2 make[1]: Leaving directory '/<>' make: *** [debian/rules:204: udeb-install] Error 2 Version 1.223 builds fine in unstable instead. Perhaps this is related to the fact that 1.224 dropped the binary package console-setup-pc-ekbd?
Re: What to do with d-i on armel?
Hi Bastian, On Sun, Jan 07, 2024 at 11:07:48PM +0100, Bastian Blank wrote: > Do we have any armel subarch that can be installed via d-i? Not as far as I know, perhaps Sledge has more info on this? Also, I don't think we've seen anyone mentioning armel in ages on debian-boot, both in terms of installation reports and in general asking questions. Correct me if I'm wrong though. Any armel users out there? :-)
Re: Writable partition for D-I ISO images
Hi! On 2023-12-20 08:47, Roland Clobus wrote: > A few months ago another approach was presented on the live-build project: > for computers that are able to boot with EFI (secure or not), preparing a > live USB-stick (based on the ISO file) is nearly trivial [1]. It is called > FST (File System Transposition) [2]. > > It requires a FAT32 formatted USB stick on which the whole (including the > hidden .disk folder) content of the ISO file is copied. There is no need for > magic boot sectors, update-grub or similar. (On Windows the tool Rufus can > do all this for you). > Since the files are now on a regular FAT32 partition, they can be modified > as required. Without knowing that the method had such a cool name, a few weeks back I documented it here: https://wiki.debian.org/DebianInstaller/WritableUSBStick ema
Bug#1053803: debian-installer: grub2 2.12~rc1-10 on ARM64 daily installer makes linux image load fail
Control: reassign -1 grub-efi-arm64-bin Control: retitle -1 grub 2.12~rc1-10 fails loading linux on Renesas RZG2L, grub 2.06 works Hi John, thanks for the bug report! On 2023-10-11 04:15, John wrote: > The ARM64 daily installer stopped working from 19-Sep-2023 due to grub2 > 2.12~rc1-10 updates with linux image load failure. > > This was working ok on 04-Sep-2023 with grub 2.06-13 For now we've only been able to reproduce this on a Renesas RZG2L board as far as I'm aware, retitling the bug accordingly. For example, I can boot kernels with grub 2.12 on ARM systems such as the Thinkpad X13s, Macbook M1, and RPi 3B+. Also the problem is grub-specific and not limited to the installer, so I've reassigned it to the grub-efi-arm64-bin binary package. Booting with debug enabled, this is the output of a failed attempt on the Renesas board. The grub version used in this test was 2.12~rc1-10. loader/efi/linux.c:101:linux: UEFI stub kernel: loader/efi/linux.c:102:linux: PE/COFF header @ 0040 loader/efi/linux.c:128:linux: LoadFile2 initrd loading enabled loader/efi/linux.c:495:linux: kernel file size: 34445248 loader/efi/linux.c:497:linux: kernel numpages: 8410 loader/efi/linux.c:514:linux: kernel @ 0xb6b43000 loader/efi/linux.c:416:linux: Using LoadFile2 initrd loading protocol loader/efi/peimage.c:242:linux: PE-COFF header checked loader/efi/peimage.c:316:linux: sections loaded loader/efi/peimage.c:518:linux: no relocations loader/efi/linux.c:213:linux: linux command line: 'BOOT_IMAGE=/linux' error: image not loaded. This instead is grub 2.12~rc1-11 succeeding on a RPi: loader/efi/linux.c:101:linux: UEFI stub kernel: loader/efi/linux.c:102:linux: PE/COFF header @ 0040 loader/efi/linux.c:128:linux: LoadFile2 initrd loading enabled loader/efi/linux.c:495:linux: kernel file size: 34510784 loader/efi/linux.c:497:linux: kernel numpages: 8426 loader/efi/linux.c:514:linux: kernel @ 0x2c92 loader/efi/linux.c:416:linux: Using LoadFile2 initrd loading protocol loader/efi/peimage.c:200:linux: PE-COFF header checked loader/efi/peimage.c:276:linux: sections loaded loader/efi/peimage.c:478:linux: no relocations loader/efi/linux.c:213:linux: linux command line: 'BOOT_IMAGE=/install.amd64/vmlinuz --- quiet' loader/efi/linux.c:233:linux: starting image 0x351cf518
Bug#1035477: installation-reports: grub or kernel of D-I image hangs on Thinkpad X13s after "EFI stub: Exiting boot services..."
Hi Axel, On 2023-10-10 01:45, Axel Beckert wrote: > I tried that, installer ran through fine, grub boots from disk after > installation, kernel loads initramfs and then falls into the initramfs > prompt and fractions of a second later (sometimes even beforehand) the > whole screen goes black and then nothing helps then pressing the power > button for about 10 seconds. This sounds like you might have missed the wiki step "Add qnoc-sc8280xp module to initramfs": https://wiki.debian.org/InstallingDebianOn/Thinkpad/X13s > And I can easily install tons of packages when I boot from the > installer USB stick into the rescue mode and chroot into the > installation on disk. OK then once you chroot into the installed system you should be able to check if qnoc-sc8280xp is in /etc/initramfs-tools/modules. If not, echo qnoc-sc8280xp >> /etc/initramfs-tools/modules update-initramfs -u -k all To triple-check that the needed module is in there: zstdcat /initrd.img | cpio -itv | grep qnoc-sc8280xp.ko In any case, the daily netinst image should now work! There's no need to manually copy any firmware and similar shenanigans. If you have the time, please follow the InstallingDebianOn/Thinkpad/X13s page again from the begingging to the end (quite a few things have changed) and let me know if that works for you. Thanks, Emanuele
Bug#1040010: [debian-installer] Please support more arm64 boards
Hello Roman, On 2023-07-01 04:18, Roman Mamedov wrote: > There are 42 DTBs shipped with the installer for Allwinner alone: > https://d-i.debian.org/daily-images/arm64/daily/device-tree/allwinner/ > > But for the bootloader aka firmware aka u-boot: > https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/ > it is an extremely weird and arbitrary list of 12 random boards. For instance > supporting "Orange Pi Zero Plus2" of all things specifically, not even just > "Zero Plus"; and not, say, Orange Pi Prime or Orange Pi Win (and so on). The choice of 12 boards does indeed look a little puzzling. Having no historical background on this, I can try and guess that they were added on a case-by-case basis every time someone needed to boot the installer on their system. Out of interest: do you have a board that's not among the lucky 12? :-) > So despite having all the other DTBs, the system is not installable on those > boards. Unless the user is sent to find and compile their own u-boot, but if > so, what is the purpose of randomly providing it for 12 random niche boards to > begin with, might as well make everyone do that. > > Instead, I suggest a better solution: maybe not even daily, but at least once > per month, could you build a bootloader part for ALL the supported boards, and > not just a handful of them. In an ideal world we would have just one single image that works on all systems! That's one of the ideas behind the Arm SystemReady certification program at least: making sure that the board can boot a regular, unmodified distro ISO without any additional blobs. We don't live in such a world unfortunately, at least not yet and not for all boards. I'm not sure we should have one different image for each DTB honestly. I'd rather go for having no custom images at all, but a very simple procedure to build your own image for your board. Maybe in the form of documentation, or a script, or both. Emanuele
Re: Upcoming D-I Bookworm RC 4 and pseudo-RC 5
Hi, On 2023-06-03 08:07, Cyril Brulebois wrote: > Since there was good progress on the arm64 console thing (#1036952), and > considering the current results of the investigation as to where vt102 > comes from, and why arm64 isn't quite the deciding factor (a busybox > limitation instead), I'd be happy to consider getting an updated > rootskel for migration before pseudo-RC 5 and 12.0.0. Such an upload > would need to happen quickly though… (ema bcc'd, as possible uploader, > no obligations though!). I see that Samuel took care of the rootskel upload. Thanks! ema
Bug#1036952: rootskel: text installs on aarch64 lack glyphs for many languages
Hi again, On 2023-05-31 05:46, Samuel Thibault wrote: > The problem is that both are frown-prone. I guess there is a reason why > on arm the default console is set to the serial port, e.g. for simpler > debugging or something like that. Also worth mentioning: there is no bug on real hardware (eg: RPi 3B+). So far I think we've only heard about people getting this issue with qemu. ciao, ema
Bug#1036952: rootskel: text installs on aarch64 lack glyphs for many languages
Hi, On 2023-05-31 05:46, Samuel Thibault wrote: > I'd rather see a patch like > > if [ "$TERM" = vt102 -a `tty` = /dev/tty1 ] ; then > # Busybox's init uses a global TERM across all consoles. > # If the serial console is the default such as on arm64, that > # will force vt102 on the Linux VT. Fix this back so we get > # colors, utf-8, etc. > TERM=linux > fi > > (to be tested etc.) The following patch works. I've built a netboot image with patched rootskel, see attached screenshots for before and after the cure. diff -Nur rootskel-1.135/src/lib/debian-installer.d/S40term-linux /home/ema/debian/rootskel-1.135+nmu1/src/lib/debian-installer.d/S40term-linux --- rootskel-1.135/src/lib/debian-installer.d/S40term-linux 2011-01-20 01:05:16.0 +0100 +++ /home/ema/debian/rootskel-1.135+nmu1/src/lib/debian-installer.d/S40term-linux 2023-06-01 15:05:32.514361854 +0200 @@ -1,5 +1,13 @@ export LANG=C +if [ "$TERM" = vt102 -a `tty` = /dev/tty1 ] ; then + # Busybox's init uses a global TERM across all consoles. +# If the serial console is the default such as on arm64, that +# will force vt102 on the Linux VT. Fix this back so we get + # colors, utf-8, etc. + TERM=linux +fi + if [ "$TERM" = linux ] ; then if [ "$TERM_TYPE" = virtual ]; then echo -ne "\033[9;0]" # Turn off console blanking.
Bug#1036952: rootskel: text installs on aarch64 lack glyphs for many languages
Hi, On Tue, May 30, 2023 at 09:08:45PM +0200, Cyril Brulebois wrote: > Philip Hands (2023-05-30): > > Apparently, this MR fixes the problem: > > > > https://salsa.debian.org/installer-team/rootskel/-/merge_requests/8 > > > > Although this does prompt the question of why aarch64 has TERM set to > > 'vt102' at this point, rather than 'linux'. > > Glancing at the merge request earlier, my first (intertwined) questions > were: > > 1. Why is aarch64 special here? > 2. Where does that difference come from? According to Jessica Clarke this is due to busybox using vt102: https://society.oftrolls.com/@jrtc27@mastodon.social/110459684352427882 > 3. Which other architectures might be impacted if we were to change > that? I'm not sure, and I haven't tested the S40term-linux patch yet. However I can report that booting the installer by passing console=tty0 to the kernel fixes the problem (thanks alpernebbi!). Which of the two changes (console=tty0 vs S40term-linux patch) is less risky?
Bug#1036215: installation-reports: PXE netboot x86_64 libvirt guest on aarch64 host
Hello, following up here on the BTS for the benefit of those not reading #debian-boot. On Wed, May 17, 2023 at 05:37:07PM +0200, Cyril Brulebois wrote: > Emanuele Rocca (2023-05-17): > > (B) failure to load the grub splash screen [...] > > sarzana dnsmasq-tftp[7413]: file /srv/tftp/bookworm/isolinux/splash.png > > not found for 192.168.122.7 > > sarzana dnsmasq-tftp[7413]: file /srv/tftp/bookworm/splash.png not found > > for 192.168.122.7 > > > > The grub.cfg file under /debian-installer/amd64/grub/grub.cfg has the > > following > > conditionals: > > > > if background_image /isolinux/splash.png; then > > [...] > > elif background_image /splash.png; then > > > > The splash screen is loaded correctly replacing either of those with > > /debian-installer/amd64/boot-screens/splash.png instead. > > Adding an extra conditional in there really doesn't seem appropriate at > this point. Seeing how images/netboot/ is 745M, and how splash.png is > 58K, I think I'd rather have it duplicated in a way that it's found in > /splash.png for both text and gtk installers (/isolinux/splash.png could > would be a weird location given the booting happens via GRUB). Even better than duplicating the image, we can use a symlink instead, see: https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/32
Bug#1036215: installation-reports: PXE netboot x86_64 libvirt guest on aarch64 host
Package: installation-reports Boot method: PXE netboot Image version: netboot.tar.gz from https://deb.debian.org/debian/dists/testing/main/installer-amd64/20230515/images/netboot/ Machine: QEMU TCG x86_64 libvirt guest on aarch64 host Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect media: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: This report is about the successful installation of Bookworm on a x86_64 guest running on a aarch64 host. The guest was installed with virt-manager using PXE boot and UEFI Secure Boot enabled. Everything went smoothly except: (A) some troubles with the UEFI PXE boot device to choose (B) failure to load the grub splash screen (A) At VM startup I've entered the UEFI firmware and booted selecting the first PXEv4 option, see [0]. Choosing the first one *seemed* to work fine, but it ended up in a Secure Boot error (see [1]). Disabling Secure Boot did not fix the problem, I still got a "Invalid Parameter" error. It eventually became clear that I had to boot with [2] instead. I'm not really sure what the difference between the two may be, and if this is an issue in the Tianocore firmware. At any rate, [2] worked fine with and without Secure Boot enabled. I went on with a preseeded installation, which finished uneventfully. I then noticed the following errors in the libvirtd logs on the host (B): sarzana dnsmasq-tftp[7413]: file /srv/tftp/bookworm/isolinux/splash.png not found for 192.168.122.7 sarzana dnsmasq-tftp[7413]: file /srv/tftp/bookworm/splash.png not found for 192.168.122.7 The grub.cfg file under /debian-installer/amd64/grub/grub.cfg has the following conditionals: if background_image /isolinux/splash.png; then [...] elif background_image /splash.png; then The splash screen is loaded correctly replacing either of those with /debian-installer/amd64/boot-screens/splash.png instead. [0] https://people.debian.org/~ema/RC3-x86_64-uefi-firmware.png [1] https://people.debian.org/~ema/RC3-x86_64-uefi-firmware-sb-error.png [2] https://people.debian.org/~ema/RC3-x86_64-uefi-firmware-right-entry.png PS: To test PXE boot with libvirt I've edited the default network with: $ sudo virsh net-edit default Here's what the part looks like: I've untarred netboot.tar.gz under /srv/tftp/bookworm/. After editing the network, I re-created it with: $ sudo virsh net-destroy default && sudo virsh net-start default Although I'm not 100% sure it was necessary, I've also restarted libvirt and shot a couple of dnsmasq processes that seemed to want to stick around: $ sudo systemctl stop libvirtd && sudo pkill dnsmasq && sudo systemctl start libvirtd
Bug#1035477: installation-reports: grub or kernel of D-I image hangs on Thinkpad X13s after "EFI stub: Exiting boot services..."
Hi again, On 2023-05-03 08:16, Axel Beckert wrote: > Machine: Thinkpad X13s (ARM) Sorry, I've realized only after sending my previous message and having a coffee that this is about the X13s. :) The X13s is unfortunately not supported by Linux 6.1 that Bookworm will ship with. Hopefully 6.4 will include all the needed patches. > But Dimitri's Ubuntu Installer Live image lunar-desktop-arm64.iso from > https://people.canonical.com/~xnox/ubuntu-concept/full/daily-live/current/ > as of 2023-03-07 20:08 booted fine without these issues. > > It would be nice if Dimitri (xnox@d.o, Cc'ed) could tell us which fix > has been applied by him (or Ubuntu) to this image so that we can fix > this issue also in Debian, maybe even before the release of Bookworm. If that image works, then it includes quite a few of out of tree kernel patches. As per [1] they are unfortunately not going to be applied to the Debian kernel, we have to wait for upstream inclusion. Emanuele [1] https://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines
Bug#1035477: installation-reports: grub or kernel of D-I image hangs on Thinkpad X13s after "EFI stub: Exiting boot services..."
Hi Axel, On 2023-05-03 08:16, Axel Beckert wrote: > After choosing either "expert install" (first and prefered try) or > "graphical expert install" (second try and second choice) I saw these > three lines and then nothing more happened: > > EFI stub: Booting Linux Kernel... > EFI stub: Using DTB from configuration table > EFI stub: Exiting boot services... > > Waited 10 minutes at least, i.e. left it alone, did something else and > came back later. Even adding the "debug" kernel parameter didn't bring > up any more details on what's happening. Perhaps we can get some more output by adding 'earlycon=efifb keep_bootcon' after 'debug' to the kernel CLI. Additionally, please try adding 'set debug=linux' to grub's configuration as well -- after the setparams directive for example. See attached screenshot. Thanks, Emanuele
Bug#1035381: virt-manager: does not autodetect OS of Debian Installer RC ISOs
Package: virt-manager Version: 1:4.1.0-2 X-Debbugs-CC: debian-boot@lists.debian.org Hi, Step 2 of the "Create a new virtual machine" wizard fails to automatically detect the operating system when using an RC version of d-i such as [0]. See attached screenshot. Stable images like [1] are correctly identified as "Debian 11". Given that "debiantesting" is in the list of known operating systems, it would be great if d-i RC ISOs could be identified as such. Thanks, ema [0] https://cdimage.debian.org/cdimage/bookworm_di_rc2/amd64/iso-cd/debian-bookworm-DI-rc2-amd64-netinst.iso [1] https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-11.7.0-amd64-netinst.iso
Bug#1035018: btrfs-progs: /sbin/fsck.btrfs missing from udeb
Package: btrfs-progs Version: 6.2-1 X-Debbugs-CC: debian-boot@lists.debian.org Tags: patch Hi, the btrfs-progs udeb currently includes only /bin/btrfs and /bin/mkfs.btrfs. Please add /sbin/fsck.btrfs as well so that it can be included in the initramfs generated by the debian installer. Patch attached. Thanks! ema diff -Nru btrfs-progs-6.2/debian/btrfs-progs-udeb.install btrfs-progs-6.2/debian/btrfs-progs-udeb.install --- btrfs-progs-6.2/debian/btrfs-progs-udeb.install 2023-03-01 00:16:51.0 +0100 +++ btrfs-progs-6.2/debian/btrfs-progs-udeb.install 2023-04-27 16:43:48.0 +0200 @@ -1,2 +1,3 @@ btrfs /bin mkfs.btrfs /bin +fsck.btrfs /sbin
Re: netboot's kernel version does not match linux-image-amd64
Hi, On 2023-04-25 06:02, Roland Clobus wrote: > On 25/04/2023 17:38, ign...@tuta.io wrote: > > Package: debian-installer-12-netboot-amd64 > > Version: 20230217 > > That's an old image. For Bookworm (Debian 12) the kernel is currently at > 6.1.20-2. Where did you find this installer? Could you try a newer one? That's indeed an old image, but with the most recent daily netinst [0] the problem is reproducible. [0] https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso 2023-04-24 23:09 sha256 f384d9cf3d22714c7b1a7b1f922645be424cd3356a55b906c35678f88f6368c0
Bug#913431: Debian Installer Bullseye RC 2 release
Hi Vincent, On Sat, Apr 22, 2023 at 02:58:22AM +0200, Vincent Danjean wrote: > I made a push request[1] but I missed the fact that it fails. > It was due to the tests being run with sh(dash) instead of bash or > busybox sh. > So, I just fixed the code so that it works with any of these 3 shells > and I update the testsuite. Now, all the tests pass on salsa. Nice! > Let me know if this is ok for you. As d-i is already in RC, if > you prefer, I can revert the longint2human part that modifies > some information, and only keep the human2longint that adds > some new input that were forbidden before (no change for what > was already accepted). The longint2human part can be added after > the release if you think it is too intrusive (or if it must be > adapted) I think splitting the patch as you suggest is a good idea. The longint2human part is quite a large change, let's do that after Bookworm. Thanks, ema
Re: Ensuring initramfs is compressed with zstd
Hi, On Sun, Mar 05, 2023 at 02:56:59AM +0100, Ben Hutchings wrote: > I did a test installation with d-i bookworm alpha 2, and I noticed a > warning message from update-initramfs during base installation that it > was falling back from zstd to gzip compression. Just FTR this is still the case with d-i RC1, I suppose Ben's patch never made it to base-installer. ema
Bug#913431: Debian Installer Bullseye RC 2 release
Hi Vincent, On 2023-03-24 11:03, Vincent Danjean wrote: > However, I did not rebuild all the installer packages to generate a > new installer and test it in real conditions. I haven't had the time to test your patch yet, but there's a hack I'd like to share to test things in d-i without rebuilding anything. Create a preseed file (say preseed.cfg) with the following line: d-i partman/early_command string wget https://example.org/partman-base-vincent.sh -O /lib/partman/lib/base.sh Upload the preseed file to a webserver, say https://example.org/preseed.cfg, and your patched base.sh to https://example.org/partman-base-vincent.sh. When booting the installer, pass the following to the kernel command line: preseed/url=https://example.org/preseed.cfg Just in case you want to give it a try.
Bug#913431: Debian Installer Bullseye RC 2 release
Hi Vincent, On 2021-06-20 10:54, Vincent Danjean wrote: > Would someone give a feedback to the (old) patch proposed > in #913431 in order to be able to also use power-of-two units > in the Debian Installer? It took a while, sorry about that. :) There is (now) a function in partman-base called valid_human [1] which checks if the partition size specified by the user is valid. Probably when you first wrote the patch this wasn't the case. That function needs to be modified as well to accept GiB and friends. [1] https://salsa.debian.org/installer-team/partman-base/-/blob/master/lib/base.sh#L373
Bug#1032648: depthcharge-tools-installer: repeatedly logs about non-ChromeOS board
Package: depthcharge-tools-installer Hi, while looking at d-i logs for one of my systems I've noticed the following message repeated many times: depthcharge-tools-installer: Not installing to non-ChromeOS board. Please consider removing the logging statement from isinstallable. Thanks, ema
Bug#1032528: installation-reports: Raspberry Pi 3 Model B Plus in EFI mode - debian-bookworm-DI-alpha2-arm64-netinst.iso
Package: installation-reports Boot method: USB stick Image version: https://cdimage.debian.org/cdimage/bookworm_di_alpha2/arm64/iso-cd/debian-bookworm-DI-alpha2-arm64-netinst.iso Date: 2023-03-08 Machine: Raspberry Pi 3 Model B Plus Rev 1.3 Processor: ARM Cortex-A53 Memory: 1G Partitions: Filesystem Type 1K-blocksUsed Available Use% Mounted on udev devtmpfs395476 0395476 0% /dev tmpfs tmpfs91436 500 90936 1% /run /dev/mmcblk0p5 ext4 30196596 1749452 26887900 7% / tmpfs tmpfs 457172 0457172 0% /dev/shm tmpfs tmpfs 5120 0 5120 0% /run/lock /dev/mmcblk0p1 vfat307016 21048285968 7% /boot/efi tmpfs tmpfs91432 0 91432 0% /run/user/1000 Output of lspci -knn (or lspci -nn): n/a Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O*] Configure network: [O] Detect media: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[E] Overall install:[] Comments/Problems: I have tested the Bookworm Alpha 2 installer on a RPi 3B+ in EFI mode. To do so, I first had to add the UEFI Firmware for Raspberry Pi 3 to the SD card onto which I planned to install Debian. The firmware images are available here: https://github.com/pftf/RPi3/releases On another Linux system I created a msdos (not GPT) partition table on the SD card with fdisk: $ sudo fdisk /dev/sdf Created a new partition with 'n', specified it should be primary with 'p', assigned it number '1', First sector '2048', Last sector '+300m'. Changed the partition type with 't', specified hex code 'e' for "W95 FAT16 (LBA)", made it bootable with 'a', saved with 'w'. Then I created a FAT16 filesystem on the partition with: $ sudo mkfs.vfat -F 16 /dev/sdf1 Mounted /dev/sdf1, unzipped RPi3_UEFI_Firmware_v1.38.zip onto it. At this point, the RPi3 was able to boot regular vanilla d-i images from a USB stick. I used debian-bookworm-DI-alpha2-arm64-netinst.iso. - Both wifi and wired ethernet were found, though for some reason the wired interface did not always manage to get configured via DHCP. I tried a few times, and when wired ethernet did not work, the wifi interface did. It seemed hit-or-miss. The installer also detected that some non-free firmware was required by the brcm module, but I don't think this is the reason for the issue, which I suspect would have otherwise been always reproducible? - The raspi-firmware package did not get installed, and I think it should probably have? - To ensure that Guided partitioning would not automatically change the partition table to GPT, but leave it as msdos, I have manually created a root partition. I haven't tested whether this was actually necessary though. - Rebooting into the freshly installed system unfortunately did not work. This is because bootaa64.efi (and indeed the whole /boot/efi/EFI/boot directory) was missing. I could fix this by booting the installer again in Rescue Mode and choosing "Force GRUB installation to the EFI removable media path", which added /boot/efi/EFI/BOOT with: ema@raspi:~$ sudo ls -l /boot/efi/EFI/BOOT total 5160 -rwx-- 1 root root 856064 Mar 8 2023 BOOTAA64.EFI -rwx-- 1 root root 91520 Mar 8 2023 fbaa64.efi -rwx-- 1 root root 4322752 Mar 8 2023 grubaa64.efi - depthcharge-tools-installer was very keen in letting me know that I do not have a ChromeOS board. The message "depthcharge-tools-installer: Not installing to non-ChromeOS board." was repeated a total of 21 times. ema@raspi:~$ sudo grep -c "non-ChromeOS board" /var/log/installer/syslog 21 Mentioning that once, if at all, would probably be enough. :-) So all in all the only truly serious problem was the fact that grub had to be installed to the EFI removable media path. I briefly discussed this with Sledge on irc and he mentioned that it would be good to have a list of platforms requiring such workaround, so that we can apply it when needed. Please find the contents of /var/log/installer/ attached. installer.tar.gz Description: application/gzip
Bug#1031398: debian-installer-utils: fetch-url fails with https if system date is wrong
Package: debian-installer-utils Version: 1.144 Booting with preseed/url=https://example.org/preseed.cfg fails if the system's clock is awfully wrong. I've got a system convinved that today is January 1st, 1970 and unsurprisingly the wget certificate check fails. Also unsurprisingly adding debian-installer/allow_unauthenticated_ssl=true is a viable workaround. Given that AFAIK d-i does support setting the date with ntp, it may possibly make sense to do that before wgetting the preseed file? Thanks, Emanuele
Bug#1031221: grub-installer: db_input / db_go undefined in postinst
control: tag -1 patch Patch here: https://salsa.debian.org/installer-team/grub-installer/-/merge_requests/12
Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted
control: tag -1 patch On Sun, Feb 12, 2023 at 09:46:34PM +0100, Emanuele Rocca wrote: > I'm unsure as to what the best course of action is here, but perhaps an idea > is > to avoid calling "die" when mount fails for efivarfs, and log an error to > /var/log/syslog instead? Of course the relevant umount should be skipped too. > > In any case, the "|| true" part in the mountvirtfs efivarfs call should > probably be dropped. Patch at https://salsa.debian.org/installer-team/grub-installer/-/merge_requests/11
Bug#1031221: grub-installer: db_input / db_go undefined in postinst
Package: grub-installer Version: 1.186 Severity: normal Tags: newcomer Hi, The function die() in /var/lib/dpkg/info/grub-installer.postinst calls db_input and db_go, but the functions are not defined: https://salsa.debian.org/installer-team/grub-installer/-/blob/master/debian/postinst#L16 Here's the relevant error in /var/log/syslog: /var/lib/dpkg/info/grub-installer postinst: line 16: db_input not found configuring 'grub-installer' failed with error code 1 The script should source /usr/share/debconf/confmodule. Thanks, ema
Bug#933523: Possible solution
Hi, On Wed, Jul 21, 2021 at 03:42:25PM +0200, Sebastian Neuser wrote: > > On Wed, 2021-07-21 at 14:59 +0200, John Paul Adrian Glaubitz wrote: > > That's probably because of the "|| true" that Steve added to the mount > > call which means that this line will always succeed even when the > > mount attempt actually failed. > > I don't think so: > mountvirtfs() mounts efivarfs with `mount ... || die ...` and die() ends > with `exit 1`, so `|| true` after the call to mountvirtfs() is actually > dead code. > > Unless I still don't get shell script logic, which is of course entirely > possible. :-) Just to confirm your understanding of the logic, indeed in case of mount efivarfs errors the script should fail because of the die() calls, see https://bugs.debian.org/1031183. Why did the mount command seemingly succeed in this case and yet the FS did not get mounted I guess is the open question. Is this bug still reproducible with a recent installer image?
Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted
Package: grub-installer
Version: 1.186
Severity: important
Hi,
On systems where efivarfs cannot be mounted, the grub installation step fails
even though it would have otherwise worked just fine skipping the mount
efivarfs command, i.e. system installation is successful with this preseed file:
d-i partman/early_command string sed -i 's/mountvirtfs efivarfs/#/'
/var/lib/dpkg/info/grub-installer.postinst
The relevant code in d/postinst looks as follows, suggesting the intention to
ignore failures:
mountvirtfs efivarfs /target/sys/firmware/efi/efivars || true
However, mountvirtfs itself is exiting with 1 in case of mount errors:
mountvirtfs () {
fstype="$1"
path="$2"
if grep -q "[[:space:]]$fstype\$" /proc/filesystems && \
! grep -q "^[^ ]\+ \+$path " /proc/mounts; then
mkdir -p "$path" || \
die grub-installer/mounterr "Error creating $path"
mount -t "$fstype" "$fstype" "$path" || \
die grub-installer/mounterr "Error mounting $path"
trap "umount $path" HUP INT QUIT KILL PIPE TERM EXIT
fi
}
I'm unsure as to what the best course of action is here, but perhaps an idea is
to avoid calling "die" when mount fails for efivarfs, and log an error to
/var/log/syslog instead? Of course the relevant umount should be skipped too.
In any case, the "|| true" part in the mountvirtfs efivarfs call should
probably be dropped.
Please note that this issue is different from https://bugs.debian.org/933523.
In that case, installing grub fails *because* efivarfs does not get mounted
properly, and the surprising bit is that the mountvirtfs efivarfs call does
*not* fail for some reason. :-)
FTR here's the error I get trying to mount efivarfs manually:
~ # mount -t efivarfs efivarfs /target/sys/firmware/efi/efivars
mount: mounting efivarfs on /target/sys/firmware/efi/efivars failed:
Operation not supported
Thanks!
ema
Bug#899240: debian-installer: blank screen on boot (6th Gen. ThinkPad X1)
On 21/05 03:47, Matti Pöllä wrote: > booting to Debian Installer fails on a 6th Generation Lenovo ThinkPad > X1 (type 20KH-006MMX) with the following symptoms: > > * Boot from a Debian installation media (mini.iso 2018-05-18 on a USB > drive). Also tested with Wheezy, Jessie, Stretch and Testing amd64 > ISOs. > > * GRUB menu (version 2.02-2) shows options "Install", "Advanced > options" and "Install with speech synthesis". > > * On entering "Install", the screen goes blank. The machine is still > powered on and the keyboard leds respond to, e.g., the "mute" > button. Switching to virtual terminals does not help as the screen > appears dead. This issue is reproducible if the installer is starting in UEFI mode (grub says "Debian GNU/Linux UEFI Installer menu") but CSM Support is disabled in the Thinkpad Setup screen, which is the one you access by pressing F1 at boot. Set CSM Support to "Yes" under Startup -> UEFI/Legacy Boot to get past this. Alternatively, set "UEFI/Legacy Boot" to "Legacy Only", in which case the installer will start in BIOS mode. > Booting to a live environment using debian-live-9.3.0-amd64-gnome.iso > is not affected by the bug. The live system uses a full 2560x1440 > resolution on a 4.9.0-4-amd64 kernel. However, the "Install" option on > the same ISO results in a blank screen. This might be due to the live image including i915.ko in its initrd? It seems to get loaded pretty early on, much earlier than X. To doublecheck, remove boot=live from the kernel parameters. You'll be dropped into a initramfs shell and by running lsmod you'll see that i915 is loaded already. Also I've tried booting the live image with modprobe.blacklist=i915 and it behaves exactly like the installer with CSM Support disabled (immediate blank screen).
Bug#899240: debian-installer: blank screen on boot (6th Gen. ThinkPad X1)
On Mon, 21 May 2018 15:47:20 +0300 =?UTF-8?B?TWF0dGkgUMO2bGzDpA==?= wrote: > Package: debian-installer > Severity: normal > Tags: d-i > > Dear Maintainer, > > booting to Debian Installer fails on a 6th Generation Lenovo ThinkPad > X1 (type 20KH-006MMX) with the following symptoms: > > * Boot from a Debian installation media (mini.iso 2018-05-18 on a USB > drive). Also tested with Wheezy, Jessie, Stretch and Testing amd64 > ISOs. > > * GRUB menu (version 2.02-2) shows options "Install", "Advanced > options" and "Install with speech synthesis". > > * On entering "Install", the screen goes blank. The machine is still > powered on and the keyboard leds respond to, e.g., the "mute" > button. Switching to virtual terminals does not help as the screen > appears dead. > > Similar problems with a blank screen have been reported on earlier > versions of the ThinkPad X1 (see > https://bbs.archlinux.org/viewtopic.php?id=210007) with workarounds > involving boot parameters intel_pstate=no_hwp or > intel_pstate=disable. In this case, this does not help. Also, the bug > appears on several kernel versions (from 3.16 in Jessie). > > Booting to a live environment using debian-live-9.3.0-amd64-gnome.iso > is not affected by the bug. The live system uses a full 2560x1440 > resolution on a 4.9.0-4-amd64 kernel. However, the "Install" option on > the same ISO results in a blank screen. > >
Bug#422307: Sparc installation problem.
Hello Anthony, * Anthony Smith [EMAIL PROTECTED], [2007-05-04 15:36 -0600]: Image version: Sarge Can you try a recent version of the installer? http://www.debian.org/releases/etch/debian-installer/ Thanks. ciao, ema -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419698: Bug#420602: kernel fails to boot on SunBlade 100
* Kolargol double zero [EMAIL PROTECTED], [2007-04-23 15:50 +0200]: After upgrading a SunBlade 100 from Sarge to Etch, the 2.6.18 kernel fails to boot after SILO loaded it. The screen shows: Remapping the kernel... done. Booting Linux... Try passing fbcon=map:1 (or video=atyfb:off) to the kernel. There's a known problem with atyfb cards, upstream is working on it. Please let us know if this workaround actually solves your problem, so that we can merge these two bugs as well. (Just FYI, the other open bugs concerning this issue are #395147, #403364 and #405285). Thanks. ciao, ema -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400263: installation report: low memory install (kbd-chooser and ext3 creation)
Hello Holger, * Holger Wansing [EMAIL PROTECTED], [2006-11-24 20:52 +0100]: Partitions: hda13,9 GB ext2 as / hda296 MB as swap (but I tried several different schemes, read further) [...] 2. ext3 creation on low memory machines. There has been a bugreport on nslu2 where creating 1GB ext3 partitions failed (ran out of memory) when swap partition was to small. I have here a 4GB hard disc and I wasn't able to create a ext3 partition of this size (tried with different swaps, max was 128 MB). Progress bar froze everytime at 33%. With the nslu2 I've been able to create an ext3 fs on a 1G partition with 96M swap (see #399951). So there seems to be a relation between the size of the swap partition and the maximum size of the ext3 fs you can create. I don't know, maybe partman-auto could decide the size of the swap area according to the disk size? - Or some note in the manual about this situation? Yes, I think that documenting this problem would be very useful. Even if partman-auto could do some magic to setup a swap area big enough to avoid the problem, the user has always the option to partition the disk manually (obiouvsly). ciao, ema -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i runs out of RAM on 32 MB machine with 1 GB hard drive
Hello Holger, * Holger Wansing [EMAIL PROTECTED], [2006-11-23 12:18 +0100]: Ahh, or is the difference, that I create ext2, not ext3? Yeah, another difference is that I created an ext3 fs, and ssh died during the journal creation. (ext3 is not available in low memory mode here) You should be able to choose the udeb for ext3 in the screen that allows to select which components of the installer you want to use. ciao, ema -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i runs out of RAM on 32 MB machine with 1 GB hard drive
Hello Martin, * Martin Michlmayr [EMAIL PROTECTED], [2006-11-22 11:04 +0100]: * Emanuele Rocca [EMAIL PROTECTED] [2006-11-22 00:37]: And the creation of an ext3 fs on /dev/sda1 fails due to ssh going out of memory. But it works if swap on /dev/sda5 is larger? I've tried this morning with a bigger sda5, but without luck. fdisk -l /dev/sda: /dev/sda111 112 899608+83 Linux Native /dev/sda2 112 112 124 96390 5 DOS Extended /dev/sda5 113 113 124 96358+82 Linux Swap /var/log/syslog: Nov 22 09:58:01 kernel: Free swap = 90140kB Nov 22 09:58:01 kernel: Total swap = 96348kB Nov 22 09:58:01 kernel: Free swap:90140kB Nov 22 09:58:01 kernel: 8192 pages of RAM Nov 22 09:58:01 kernel: 429 free pages Nov 22 09:58:01 kernel: 681 reserved pages Nov 22 09:58:01 kernel: 1229 slab pages Nov 22 09:58:01 kernel: 664 pages shared Nov 22 09:58:01 kernel: 1552 pages swap cached Nov 22 09:58:01 kernel: Out of Memory: Kill process 4024 (sshd) score 96 and children. Nov 22 09:58:01 kernel: Out of memory: Killed process 4049 (sshd). There was another terminal open with a tail -f on /var/log/syslog, which could be an explaination of the failure, given that it was indeed using some resources. I'll further investigate this issue tonight. Other systems affected besides the nslu2? ciao, ema -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399951: RC1 on a NSLU2, 1GB usb drive
Package: installation-reports Boot method: Firmware flashed, installed via ssh Image version: Debian/NSLU2 Etch RC1 downloaded from http://www.slug-firmware.net/d-dls.php Machine: Linksys NSLU2 Partitions: Device Boot Start End Blocks Id System /dev/sda1 1 12 96358+ 82 Linux swap / Solaris /dev/sda2 * 13 125 907672+ 83 Linux Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [ ] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] (Partially ok, see notes below) Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [ ] Install boot loader:[O] Overall install:[O] Comments/Problems: There's a known issue [0] installing over ssh on a 1GB hard drive in low mem. Without a big enough swap partition the ssh daemon goes out of memory creating the root fs, disconnecting the user. Moreover, trying to login again to resume the installation, partman hangs doing: cd /var/lib/partman/devices/=dev=mtdblock0 open_dialog DUMP (from /lib/partman/init.d/35dump) BTW, besides from this issue, the installation was perfect, congrats for the really fine job. I've been able to complete the installation twice, the first time with a 128M swap partition, and now even with a smaller one, as suggested by Otavio [1], just 96M. The partman-auto reciepe for put everything in one partition creates a swap area of around 80M, which are not enough; I'd suggest to raise the default size, maybe only if in low-mem. [0] http://lists.debian.org/debian-arm/2006/11/msg00070.html http://lists.debian.org/debian-arm/2006/11/msg00077.html [1] http://lists.debian.org/debian-boot/2006/11/msg00859.html ciao, ema -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i runs out of RAM on 32 MB machine with 1 GB hard drive
Hello Martin, * Martin Michlmayr [EMAIL PROTECTED], [2006-11-22 16:01 +0100]: * Emanuele Rocca [EMAIL PROTECTED] [2006-11-22 14:20]: Other systems affected besides the nslu2? I assume it's a generic problem but there are few supported systems that have 32 MB RAM and on which people use a 1 GB stick. I've tried under qemu, with a 1GB disk image and 32MB RAM, and the fs creation was successful. I've not completed the installation, though. Probably it's worth changing the partman-auto recipes only for the potentially affected systems. ciao, ema -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Headaches while trying to test my own custom d-i modules
* On 12-01-04 - 07:16, Christian Perrier [EMAIL PROTECTED] wrote: Thourgh IRC, I've been directed to build my own APT repository. I thus read the online doc about this, uses apt-ftparchive. I now have a nice APT archive with my custom partitioner package on it. But, how the hell do I use it ? I don't know if this is right, I've never tried... BTW, from build/README: 'sources.list' is used to configure apt to download udebs from a mirror. It is autogenerated based on '/etc//apt/sources.list', by the Makefile's 'sources.list' target. Or you can provide your own locally modified 'sources.list.local'. Hope this helps, ema -- Emanuele Rocca | Tra salvare un puntatore su un file e dipingere una 1024D/EAF19B60 | scoreggia di verde passa veramente poca differenza. signature.asc Description: Digital signature
Bug#225858: Validating %s message untranslated from debootrstrap
* On 02-01-04 - 03:35, Joey Hess [EMAIL PROTECTED] wrote: Sometimes, base-installer updates the progress bar to say Validating %s. If the install language is not English, this is untranslated too. Booting with DEBCONF_DEBUG=5, from /var/log/syslog: METAGET base-installer/debootstrap/info/ apt description 20 Incorrect number of arguments SUBST base-installer/debootstrap/fallback-info INFO Validating %s Adding [INFO] - [Validating %s] I don't know why, but for some reasons the METAGET debconf command is called with the wrong parameters. METAGET base-installer/debootstrap/info/validating description should be the correct invocation. -- Emanuele Rocca |Tra salvare un puntatore su un file e dipingere una [EMAIL PROTECTED] | scoreggia di verde passa veramente poca differenza. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#225858: Validating %s message untranslated from debootrstrap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * On 02-01-04 - 03:35, Joey Hess [EMAIL PROTECTED] wrote: Sometimes, base-installer updates the progress bar to say Validating %s. If the install language is not English, this is untranslated too. It doesn't always happen. So far I think it only happens when installing from a businesscard CD image. Even then, it does not happen for all the debs on the image. I've seen it put the package name in properly for some, and then display %s for one, and then go back to putting in the package name for others. These are some of the packages affected by the Validating %s problem using businesscard ISOs. 2003-12-31 (md5sum a2c1f661d8eaa1323eedb49f825fc6b0): apt apt-utils aptitude bsdmainutils debconf dpkg dselect exim4-daemon-light fileutils grep groff-base libc6 libgcrypt1 libssl0.9.7 nvi pcmcia-cs perl-base ppp slang1 syslinux wget 2004-01-01 (md5sum 68cc6b72a04d1e8b979f85ef2d192ffe) With this iso, in the Receiving packages step, packages are not received but just validated. No packages seems to be affected by the problem, the Validating x string is translated correctly and %s is replaced with package name. However, after the packages extraction, debootstrap exits with an error and I am unable to go on. My guess is that this is a problem tickled by something in the debootrap progress stream, and that it has to do with the wget progress data it displays. It's probably wget-related since when the package is not received but just validated, the bug do not appears. - -- Emanuele Rocca | Medi come i ceti a cui appartengono, [EMAIL PROTECTED] | terra terra come i missili cui assomigliano -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/9WTZC6DuA+rxm2ARAmvgAKCI7VdocPgKWx7PK6+T36y/ZXDGtwCeO1dr TYSCfxBGWzwz2M30TkI+efA= =IYY+ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#225858: Validating %s message untranslated from debootrstrap
* On 02-01-04 - 13:32, Emanuele Rocca [EMAIL PROTECTED] wrote: These are some of the packages affected by the Validating %s problem using businesscard ISOs. [...] 2004-01-01 (md5sum 68cc6b72a04d1e8b979f85ef2d192ffe) With this iso, in the Receiving packages step, packages are not received but just validated. No packages seems to be affected by the problem, the Validating x string is translated correctly and %s is replaced with package name. However, after the packages extraction, debootstrap exits with an error and I am unable to go on. This happens only if I keep the filesystem intact. I am able to reproduce the bug creating a new filesystem on /, I guess because this way /target/var/cache/apt/archives is empty and the installer *really* gets the debs. Everything is like with the 2003-12-31 businesscard ISO; the same packages are affected by the problem, but I am able to go on with the installation. -- Emanuele Rocca | Medi come i ceti a cui appartengono, [EMAIL PROTECTED] | terra terra come i missili cui assomigliano -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#225709: installation-reports: No big problems, partconf and aptitude small issues
Il gio, 2004-01-01 alle 18:56, Joey Hess ha scritto: Emanuele Rocca wrote: It sounds like apt-setup did not do its thing. Please send me a copy of /var/log/installer.log. I've not got that file. Actually, I've got the dir /var/log/debian-installer/, with a directory (cdebconf) and 4 files: hardware-summary, messages, package-versions and syslog. I guess that syslog and messages are interesting, but if you need something else, just let me know. I forgot; the file I need was renamed to /var/log/base-config.log http://people.debian.org/~ema/base-config.log -- Emanuele Rocca - 1024D/EAF19B60 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#225709: installation-reports: No big problems, partconf and aptitude small issues
Package: installation-reports Severity: normal INSTALL REPORT Debian-installer-version: daily built from http://people.debian.org/~manty/testing/netinst/i386/daily/ sarge-i386-businesscard.iso 30-Dec-2003 11:01 36.7M uname -a: Linux barney 2.4.22-1-386 #9 Sat Oct 4 14:30:39 EST 2003 i586 GNU/Linux Date: Wed, 31 Dec 2003 18:57:42 +0100 Method: Boot from IDE cd-rom, businesscard ISO Machine: Desktop PC Processor: AMD K6-2 500 MHz Memory: 128 MB Root Device: IDE Root Size/partition table: hdc1 Linux swap hdc2 Linux ext3 hdc3 Linux ext3 Output of lspci: 00:00.0 Host bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3] (rev 04) 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA [Apollo VP] (rev 47) 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06) 00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 02) 00:07.3 Host bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10) 00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 01:00.0 VGA compatible controller: nVidia Corporation NV5M64 [RIVA TNT2 Model 64/Model 64 Pro] (rev 15) Base System Installation Checklist: Initial boot worked:[O] Configure network HW: [O] Config network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Create file systems:[O] Mount partitions: [O] Install base system:[O] Install boot loader:[O] Reboot: [O] [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Comments/Problems: No big problems, beside two small issue in partconf and aptitude. I created a swap partition (hdc1) and when was the time to mount it partconf marked that partition as vfat, also if a filesystem was not created yet. Another problem, when I was configuring the system, I choosed to run aptitude but in aptitude's main menu the only 2 available voices were: --- Obsolete and Locally Created Packages --- Virtual Packages This is not very useful. After removing the comment in sources.list and apt-get update, however, everything works perfectly. Happy new year and thanks for the great work done -- Emanuele Rocca | Quando sei in cabina e giochi la schedina ricordati [EMAIL PROTECTED] | che sei colonna di un sistema -- Frankie HI Nrg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Successful (well, nearly..) installation report (vmware)
Il mer, 2003-11-05 alle 06:57, Christian Perrier ha scritto: 4.0.0-build 4460 [...] 00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 01) 00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 01) .../... 0011.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 10) .../... With sarge-i386-netinst.iso from 3 Nov, same version of vmware and same lspci output, the pcnet32 module was automatically loaded. I simply had to configure the interface with ifconfig. -- Emanuele Rocca - 1024D/EAF19B60 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: successful installation report (vmware)
Il mar, 2003-11-04 alle 00:23, Joey Hess ha scritto: Debian-installer-version: sarge-i386-netinst.iso from 2 Nov Method: cdrom install on vmware Similar report, test performed with vmware and sarge-i386-netinst.iso from 3 Nov. (also for me this is the first successful install of d-i). Comments/Problems: I tested the installer this afternoon and the installation process was ok. Just a couple of things: when the d-i is downloading/extracting packages, the dialog box moves up and down if the .deb path is too long. Can the full path be omitted? The filename is not enough? Another problem, perhaps vmware-related: trying to switch back to the main menu from a console with ALT+F1 I still see the console output. Moving up and down with directional arrows redraws the screen. A screenshot is available here: http://members.xoom.virgilio.it/debian01/installer.png I tried to re-install sarge over the fresh installed system. I left the partition table untouched and in the Configure and Mount Partitions step I chose the Leave the file system intact option. After the packages extraction the installation hanged on Install the base system. This was the debootstrap.log content: ln: /target/usr/bin/awk: File exists Re-creating the file system I was able to install sarge through the d-i for the second time. :) ciao, ema -- Emanuele Rocca - 1024D/EAF19B60 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: request to NMU slang
Il mar, 2003-09-16 alle 11:48, Nikita V. Youshchenko ha scritto: Could someone please NMU slang with patch from 195010 applied? Note also that some days ago I found a problem due to the lack of a symlink to libslang.so.1. The error message appeared trying to partition the hd. Please consider to check this problem before performing the NMU. Regards, -- Emanuele Rocca - 1024D/EAF19B60 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Laptop: system hangs
Hi Matthias, Il mar, 2003-09-02 alle 13:10, Matthias P. Wuerfl ha scritto: OK. Su to root is no problem. What i meant was what do i have to type to get information about what was detected during startup?. lsmod shows you all the loaded modules, this is a good starting point. Take also a look at the output of dmesg. bye -- Emanuele Rocca - 1024D/EAF19B60 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-installer test
Please try to partition the disk by hand on the second console (to make sure fdisk can use the disk). I'll try it asap. But the partitioner complains about the lack of libslang.so.1; entering in a console and just symlinking to libslang.so.1-UTF8 solves the problem. The error message is precisely: cfdisk: error while loading shared libraries: libslang.so.1: cannot open shared object file: No such file or directory di-utils-partitioner's postinst exited with status 256 When tring on intel machines, the disk were already partitioned, while when we had a try at vmware we got a crash at this very point. The vmware crashed and the host computer did the same -- even if the vwmare wasn't run by root :-( Yes, trying the installer with vmware crashes not only the virtual machine but also the whole system, but only using physically the cdrom. (accessing directly to /dev/cdrom). Using an iso image of the cd mounted as a cdrom in vmware makes possible to go on with the installer without hanging the machine. Bye, -- Emanuele Rocca - 1024D/EAF19B60 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
