Unexpected reboot after powerpc install
Hi Everyone, I was trying to follow John Paul Adrian Glaubitz instructions for installing Debian 10 on a PowerMac G5. The instructions are at https://lists.debian.org/debian-powerpc/2021/02/msg00011.html. The instructions say to forgo the reboot after installation and perform some extra steps. At the end of the installation, the last screen told me a reboot was needed. The last screen gave me two choices - or . I selected because I had the extra steps to perform. I planned on reboot after performing the extra steps. unexpectedly rebooted the machine and I lost the chance to perform the extra steps. (Now I'm stuck at an OpenFirmware prompt that results in a kernel load failure/corrupt image error message for every command I enter. Sigh...) >From a UX perspective, the last screen has a lot of opportunity for improvement. There's no indication what does or where it "goes back" to. It is also not clear that "going back" does not undo the most recent steps performed by the installer. Finally, there's no indication will immediately reboot the machine. I believe the last screen should say something like: Installation is complete. A reboot is required. If you select then a reboot will happen now. If you select then you will have to manually reboot later. Would you like to Reboot now? Changing the text on the last screen will dramatically improve the UX experience. It tells the user what is going to happen. It also offers the user a chance to avoid the reboot . Jeff
Re: Unexpected reboot after powerpc install
On 2/9/2021 10:27 AM, Jeffrey Walton wrote: Hi Everyone, I was trying to follow John Paul Adrian Glaubitz instructions for installing Debian 10 on a PowerMac G5. The instructions are at https://lists.debian.org/debian-powerpc/2021/02/msg00011.html. The instructions say to forgo the reboot after installation and perform some extra steps. At the end of the installation, the last screen told me a reboot was needed. The last screen gave me two choices - or . I selected because I had the extra steps to perform. I planned on reboot after performing the extra steps. Actually, at the reboot step, you need to "Switch to another console". See (1) on how to do that. 1) https://www.debian.org/releases/buster/amd64/ch06s01.en.html -- John Doe
Re: Unexpected reboot after powerpc install
On 2/9/21 10:49 AM, john doe wrote: > Actually, at the reboot step, you need to "Switch to another console". Well, you can just select "Go back" and you're in the main menu from where you can also execute a shell. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Processed: Re: task-japanese-desktop: should explicitly prefer mozc over anthy
Processing control commands: > owner -1 debian-boot@lists.debian.org Bug #982175 [task-japanese-desktop] task-japanese-desktop: should explicitly prefer mozc over anthy Owner recorded as debian-boot@lists.debian.org. > forwarded -1 > https://salsa.debian.org/installer-team/tasksel/-/merge_requests/15 Bug #982175 [task-japanese-desktop] task-japanese-desktop: should explicitly prefer mozc over anthy Set Bug forwarded-to-address to 'https://salsa.debian.org/installer-team/tasksel/-/merge_requests/15'. -- 982175: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982175 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Problem installing Debian on Dell XPS 13 9360 laptop
On 09/02/2021 00:43, Lou Poppler wrote: On Mon, 2021-02-08 at 22:59 +, Bernard McNeill wrote: But, as I think I mentioned earlier, I am very reluctant indeed to mess around with Windows itself. I have backed up the user data, but I am not at all sure how to re-install Windows itself. If the machine failed I suspect I would take it to a specialist with a copy of the user data. I suggest at this point you should try out one of the debian "live" images. These can be copied to a USB stick (via win32diskimager or others) just like you copied the installer to USB. Then, you boot into the live image and it runs completely from the USB stick -- you have a mostly complete linux system you can experiment with, without permanently writing it onto any other disks, and without the live system needing to write to any other disks. I would suggest the current stable "gnome" live system, which is familiar to Windows users -- and I also suggest the so-called "non-free" version (which just means it includes various firmware files for wifi or fancy graphics adapters, etc.) Download here: https://cdimage.debian.org/cdimage/unofficial/non-free/images-including-firmware/current-live/amd64/iso-hybrid/debian-live-10.8.0-amd64-gnome+nonfree.iso I am going to try your suggestion. For the record, I did fully reinstall Debian with Fastboot (both Windows and BIOS) disabled. I got the same issues as before, but can confirm (because I was looking for it) that the installer/partitioner does not seem to see the SSD. It could see both the install USB flash drive and the external USB HDD. Best regards
Installing firmware and ISO images on CD/DVD
Hi Everyone, I'd like to install the additional firmware required for PowerPC. It is briefly discussed at https://www.debian.org/releases/jessie/amd64/ch06s04.html.en. The problem I am having is, PowerMac's don't have an eject button. I can't eject the installer to add the firmware CD from http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/archive/8.10.0+nonfree/powerpc/iso-cd/. I tried to use a USB stick but the firmware was not found. (I don't even think the USB bus was scanned - the led on the usb stick did not blink). I think the installer should be modified in two places to support an eject operation. The first place is the "Missing firmware" screen. The second place is the "Configure Apt" screen. Jeff
Re: Installing firmware and ISO images on CD/DVD
Hello! > On Feb 9, 2021, at 1:22 PM, Jeffrey Walton wrote: > > Hi Everyone, > > I'd like to install the additional firmware required for PowerPC. It > is briefly discussed at > https://www.debian.org/releases/jessie/amd64/ch06s04.html.en. > > The problem I am having is, PowerMac's don't have an eject button. I > can't eject the installer to add the firmware CD from > http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/archive/8.10.0+nonfree/powerpc/iso-cd/. > I tried to use a USB stick but the firmware was not found. (I don't > even think the USB bus was scanned - the led on the usb stick did not > blink). You can eject the CD from the command line with: # eject /dev/cdrom or # eject /dev/sr0 > I think the installer should be modified in two places to support an > eject operation. The first place is the "Missing firmware" screen. The > second place is the "Configure Apt" screen. That could potentially be done but we‘re adding firmware on the ISOs in the near future anyway. Adrian
Color choices for the installer
Hi Everyone, I think the installer's choice of red for the background color can be improved. Red is a color associated with anger and aggression. Red as an accent would probably be OK, but the installer uses a wall of red. There's no need to increase anger and aggression when working with an installer. I know of a couple of companies that changed their colors to avoid red to reduce stress and anxiety in its customers. For example, USAir. Blue is usually a safe color. It is favored by most people. It is associated with calm, serenity, stability and reliability. There are other colors available if you are not a fan of blue. Also see https://www.verywellmind.com/color-psychology-2795824, https://www.verywellmind.com/the-color-psychology-of-blue-2795815, https://www.verywellmind.com/the-color-psychology-of-red-2795821. Jeff
Bug#982369: [PATCH] all.db: add support for ODROID-C4, -HC4, -N2, -N2Plus
Package: flash-kernel Version: 3.104 Severity: normal Tags: patch Add missing data base entries for: * Hardkernel ODROID-C4 * Hardkernel ODROID-HC4 * Hardkernel ODROID-N2 * Hardkernel ODROID-N2Plus Signed-off-by: Heinrich Schuchardt --- db/all.db | 28 1 file changed, 28 insertions(+) diff --git a/db/all.db b/db/all.db index 0d1d33d..426247f 100644 --- a/db/all.db +++ b/db/all.db @@ -584,6 +584,34 @@ Boot-Script-Path: /boot/boot.scr U-Boot-Script-Name: bootscr.uboot-generic Required-Packages: u-boot-tools +Machine: Hardkernel ODROID-C4 +Kernel-Flavors: arm64 +DTB-Id: amlogic/meson-sm1-odroid-c4.dtb +Boot-Script-Path: /boot/boot.scr +U-Boot-Script-Name: bootscr.uboot-generic +Required-Packages: u-boot-tools + +Machine: Hardkernel ODROID-HC4 +Kernel-Flavors: arm64 +DTB-Id: amlogic/meson-sm1-odroid-hc4.dtb +Boot-Script-Path: /boot/boot.scr +U-Boot-Script-Name: bootscr.uboot-generic +Required-Packages: u-boot-tools + +Machine: Hardkernel ODROID-N2 +Kernel-Flavors: arm64 +DTB-Id: amlogic/meson-g12b-odroid-n2.dtb +Boot-Script-Path: /boot/boot.scr +U-Boot-Script-Name: bootscr.uboot-generic +Required-Packages: u-boot-tools + +Machine: Hardkernel ODROID-N2Plus +Kernel-Flavors: arm64 +DTB-Id: amlogic/meson-g12b-odroid-n2-plus.dtb +Boot-Script-Path: /boot/boot.scr +U-Boot-Script-Name: bootscr.uboot-generic +Required-Packages: u-boot-tools + Machine: Hardkernel ODROID-U3 board based on Exynos4412 Kernel-Flavors: armmp armmp-lpae DTB-Id: exynos4412-odroidu3.dtb -- 2.30.0
Re: Color choices for the installer
On 2/9/21 5:00 AM, Jeffrey Walton wrote: Hi Everyone, I think the installer's choice of red for the background color can be improved. Red is a color associated with anger and aggression. Red as an accent would probably be OK, but the installer uses a wall of red. I am just a common user, lurking. I do lots of installs and never have I seen a Red background. Please tell us which ISO you are using. There's no need to increase anger and aggression when working with an installer. I know of a couple of companies that changed their colors to avoid red to reduce stress and anxiety in its customers. For example, USAir. Blue is usually a safe color. It is favored by most people. It is associated with calm, serenity, stability and reliability. There are other colors available if you are not a fan of blue. Also see https://www.verywellmind.com/color-psychology-2795824, https://www.verywellmind.com/the-color-psychology-of-blue-2795815, https://www.verywellmind.com/the-color-psychology-of-red-2795821. Jeff
Re: Color choices for the installer
On Tue, Feb 09, 2021 at 06:21:52AM -0800, Peter Ehlert wrote: > >On 2/9/21 5:00 AM, Jeffrey Walton wrote: >> Hi Everyone, >> >> I think the installer's choice of red for the background color can be >> improved. Red is a color associated with anger and aggression. Red as >> an accent would probably be OK, but the installer uses a wall of red. >I am just a common user, lurking. I do lots of installs and never have I seen >a Red background. >Please tell us which ISO you are using. The only time you'd normally get a red background is when the installer is flagging an error. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I used to be the first kid on the block wanting a cranial implant, now I want to be the first with a cranial firewall. " -- Charlie Stross
Re: Color choices for the installer
On Tue, Feb 9, 2021 at 9:22 AM Peter Ehlert wrote: > > On 2/9/21 5:00 AM, Jeffrey Walton wrote: > > Hi Everyone, > > > > I think the installer's choice of red for the background color can be > > improved. Red is a color associated with anger and aggression. Red as > > an accent would probably be OK, but the installer uses a wall of red. > I am just a common user, lurking. I do lots of installs and never have I > seen a Red background. > Please tell us which ISO you are using. I am using debian-10.0.0-powerpc-NETINST-1.iso at https://cdimage.debian.org/cdimage/ports/snapshots/2021-02-02/. Jeff
Re: Color choices for the installer
On Tue, Feb 9, 2021 at 9:25 AM Steve McIntyre wrote: > > On Tue, Feb 09, 2021 at 06:21:52AM -0800, Peter Ehlert wrote: > > > >On 2/9/21 5:00 AM, Jeffrey Walton wrote: > >> Hi Everyone, > >> > >> I think the installer's choice of red for the background color can be > >> improved. Red is a color associated with anger and aggression. Red as > >> an accent would probably be OK, but the installer uses a wall of red. > >I am just a common user, lurking. I do lots of installs and never have I seen > >a Red background. > >Please tell us which ISO you are using. > > The only time you'd normally get a red background is when the > installer is flagging an error. Thanks Steve. Yeah, I kind of feel that way. After 9 hours of trying to install Debian I'd write it up as one big mistake. I think I'll wait for the release ISO. Jeff
Re: Color choices for the installer
On 2/9/21 3:34 PM, Jeffrey Walton wrote: > Yeah, I kind of feel that way. After 9 hours of trying to install > Debian I'd write it up as one big mistake. I think I'll wait for the > release ISO. I'm doing all this in my free time and I'm working on the Debian Ports releases almost alone. But thanks for the praise anyway. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Installing firmware and ISO images on CD/DVD
On Tue, 2021-02-09 at 07:22 -0500, Jeffrey Walton wrote: > Hi Everyone, > > I'd like to install the additional firmware required for PowerPC. It > is briefly discussed at > https://www.debian.org/releases/jessie/amd64/ch06s04.html.en. > > The problem I am having is, PowerMac's don't have an eject button. I > can't eject the installer to add the firmware CD from > http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/archive/8.10.0+nonfree/powerpc/iso-cd/. > I tried to use a USB stick but the firmware was not found. (I don't > even think the USB bus was scanned - the led on the usb stick did not > blink). > > I think the installer should be modified in two places to support an > eject operation. The first place is the "Missing firmware" screen. The > second place is the "Configure Apt" screen. > > Jeff > The second CD you reference [8.10.0+nonfree] is both an installer and a source of firmware files. You should be able to install without ejecting, I think?
Bug#982404: Debian 10.8 Won't Load Kernel 5.9
Package: installation-reports Boot method: CD Image version: https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-10.8.0-amd64-netinst.iso Date: Machine: ASUS Sabertooth 990FX 2.0 Motherboard two 4 TB WD Black HDs Processor: AMD FX 8370 processor Memory: 32 GB Partitions: root@LinuxHome:/home/beard9g# df -Tl Filesystem Type 1K-blocks Used Available Use% Mounted on udev devtmpfs 16363304 0 16363304 0% /dev tmpfs tmpfs 3283456 15643281892 1% /run /dev/mapper/LinuxHome--vg-root ext4 3810956664 1095032640 2522267808 31% / tmpfs tmpfs 16417268 81596 16335672 1% /dev/shm tmpfs tmpfs 5120 4 5116 1% /run/lock /dev/sda2 ext2 242078 109048 120530 48% /boot /dev/sda1 vfat 524340 5224 519116 1% /boot/efi tmpfs tmpfs 32834521643283288 1% /run/user/1000 Output of lspci -knn (or lspci -nn): root@LinuxHome:/home/beard9g# lspci -knn 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD/ATI] RD9x0/RX980 Host Bridge [1002:5a14] (rev 02) Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] RD9x0/RX980 Host Bridge [1002:5a14] 00:02.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GFX port 0) [1002:5a16] Kernel driver in use: pcieport 00:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 0) [1002:5a18] Kernel driver in use: pcieport 00:05.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 1) [1002:5a19] Kernel driver in use: pcieport 00:09.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 4) [1002:5a1c] Kernel driver in use: pcieport 00:0a.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 5) [1002:5a1d] Kernel driver in use: pcieport 00:0b.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD990 PCI to PCI bridge (PCI Express GFX2 port 0) [1002:5a1f] Kernel driver in use: pcieport 00:0d.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP2 Port 0) [1002:5a1e] Kernel driver in use: pcieport 00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] [1002:4391] (rev 40) Subsystem: ASUSTeK Computer Inc. SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] (M5A99X EVO (R1.0) SB950) [1043:84dd] Kernel driver in use: ahci Kernel modules: ahci 00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] Kernel driver in use: ohci-pci Kernel modules: ohci_pci 00:12.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396] Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396] Kernel driver in use: ehci-pci Kernel modules: ehci_pci 00:13.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] Kernel driver in use: ohci-pci Kernel modules: ohci_pci 00:13.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396] Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396] Kernel driver in use: ehci-pci Kernel modules: ehci_pci 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus Controller [1002:4385] (rev 42) Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus Controller [1002:4385] Kernel driver in use: piix4_smbus Kernel modules: i2c_piix4, sp5100_tco 00:14.2 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA) [1002:4383] (rev 40) Subsystem: ASUSTeK Computer Inc. SBx00 Azalia (Intel HDA) [1043:8436] Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 LPC host controller [1002:439d] (rev 40) Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 LPC host controller [1002:439d] 00:14.4 P
Bug#982422: debootstrap: segmentation fault around ldconfig during debootstrapping bullseye/arm64 on a buster/amd64 host
Package: debootstrap
Version: 1.0.114
Severity: normal
I'm struggling with a problem that I currently have with debootstrapping an
arm64 system on my amd64 machine. The attached script can reproduce the issue
here.
It crashes here on a debian buster amd64, in the 2nd debootstrap stage:
...
W: Failure trying to run: /sbin/ldconfig
W: See //debootstrap/debootstrap.log for details
...
2021-02-10 01:05:52 URL:http://deb.debian.org/debian/pool/main/x/xz-
utils/liblzma5_5.2.5-1.0_arm64.deb [164436/164436] ->
"/...//var/cache/apt/archives/partial/liblzma5_5.2.5-1.0_arm64.deb" [1]
2021-02-10 01:05:52
URL:http://deb.debian.org/debian/pool/main/z/zlib/zlib1g_1.2.11.dfsg-2_arm64.deb
[87944/87944] ->
"/...//var/cache/apt/archives/partial/zlib1g_1%3a1.2.11.dfsg-2_arm64.deb" [1]
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
It works if I debootstrap a buster system instead. Then trying to upgrade to
bullseye in the same chroot crashes with a segfault during the upgrade of libc-
bin. It also segfaults when I just open a chrooted shell after the 1st stage
and then run "ldconfig". That worked here around new year, but then broke.
This looks like a software bug somewhere. I'm not sure if I'm right here. But
maybe you can tell me.
#!/bin/bash
set -e
LOOPFILE=removemelater.loopfile
INNERROOT=removemelater.loopmnt
LOOPDEV=/dev/loop5
reproduce() {
dd if=/dev/zero of=$LOOPFILE bs=1M count=2048
losetup $LOOPDEV $LOOPFILE
mkfs.ext4 $LOOPDEV
mkdir $INNERROOT
mount $LOOPDEV $INNERROOT
debootstrap --arch=arm64 --foreign bullseye $INNERROOT
mount -o bind /sys $INNERROOT/sys
mount -o bind /dev $INNERROOT/dev
mount -o bind /dev/pts $INNERROOT/dev/pts
mount -o bind /proc $INNERROOT/proc
chroot $INNERROOT /bin/bash -c "/debootstrap/debootstrap --second-stage"
}
reproduce || cat $INNERROOT/debootstrap/debootstrap.log
Bug#982422: debootstrap: segmentation fault around ldconfig during debootstrapping bullseye/arm64 on a buster/amd64 host
> I'm not a debootstrap maintainer, but if you're using QEMU user mode > to run > foreign chroots, I suggest you use the qemu-debootstrap wrapper which > comes > with the qemu-user-static package. Yes, I think that's what it does implicitly due to some magic mechanism. I can also explicitly write 'qemu-aarch64-static' in front of '/bin/bash' in my script, but that seems to do the very same thing. > If you're using systemd, there's also a handy tool used for entering > chroots > called systemd-nspawn you may be interested in. It takes care of the > mount > points and the other little details. You could just use it like > sudo systemd-nspawn -D ./bullseye Interesting indeed. But do you think it could be related? Well, I'll give it a try tomorrow. Interesting improvement anyway. > There's also a slimmer arch-chroot tool in the arch-install-scripts > package > (despite the name, it's useful aside from just Arch Linux chroots). I would not like to switch to just another tool at that moment. My actual script is a bit larger and would not be trivial to migrate. Something seems to break regarding libc-bin, so is this about glibc in some way? Sorry, I'm not deeply experienced in those system levels. :) What would be good ways to get more information? I tried with strace meanwhile, but this is just telling me "PTRACE_TRACEME: Function not implemented". :-/ As I said, I definitely had it working here, one or two month ago, without changes on the script. So I'm optimistic that it could be solvable. > Your script ran okay and didn't segfault from my Bullseye host. That's great to hear. So even if I cannot get it solved, it should go away in some months. :) Not perfect, but not worst case...
