Bug#932939: Unable to reproduce in Bullseye (Debian 11)
Hi, Just an update here, I just provisioned a host with Debian GNU/Linux Bullseye with "console=tty0 console=ttyS0,115200n8" present in installer kernel command-line, and it seems to have provisioned just fine. Feel free to mark this bug as resolved. Thanks! -- Ashish SHUKLA | GPG: F682 CDCC 39DC 0FEA E116 20B6 C746 CFA9 E74F A4B0 "Should I kill myself, or have a cup of coffee?" (Albert Camus) signature.asc Description: PGP signature
Bug#592834: Just saw this when using autoremove
I just updated my 20.04 install, it installed 5.4.0-84 (among other things). I rebooted and then used apt autoremove to remove anything old. Here's what I got: root@rct2:/home/farokh# apt autoremove Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: linux-headers-5.4.0-77 linux-headers-5.4.0-77-generic linux-headers-5.4.0-80 linux-headers-5.4.0-80-generic linux-image-5.4.0-77-generic linux-image-5.4.0-80-generic linux-modules-5.4.0-77-generic linux-modules-5.4.0-80-generic linux-modules-extra-5.4.0-77-generic linux-modules-extra-5.4.0-80-generic 0 upgraded, 0 newly installed, 10 to remove and 0 not upgraded. After this operation, 755 MB disk space will be freed. Do you want to continue? [Y/n] (Reading database ... 187508 files and directories currently installed.) Removing linux-headers-5.4.0-77-generic (5.4.0-77.86) ... Removing linux-headers-5.4.0-77 (5.4.0-77.86) ... Removing linux-headers-5.4.0-80-generic (5.4.0-80.90) ... Removing linux-headers-5.4.0-80 (5.4.0-80.90) ... Removing linux-modules-extra-5.4.0-77-generic (5.4.0-77.86) ... Removing linux-image-5.4.0-77-generic (5.4.0-77.86) ... /etc/kernel/postrm.d/initramfs-tools: update-initramfs: Deleting /boot/initrd.img-5.4.0-77-generic /etc/kernel/postrm.d/zz-update-grub: Sourcing file `/etc/default/grub' Sourcing file `/etc/default/grub.d/init-select.cfg' Generating grub configuration file ... Found linux image: /boot/vmlinuz-5.4.0-84-generic Found initrd image: /boot/initrd.img-5.4.0-84-generic Found linux image: /boot/vmlinuz-5.4.0-81-generic Found initrd image: /boot/initrd.img-5.4.0-81-generic Found linux image: /boot/vmlinuz-5.4.0-80-generic Found initrd image: /boot/initrd.img-5.4.0-80-generic done Removing linux-modules-extra-5.4.0-80-generic (5.4.0-80.90) ... Removing linux-image-5.4.0-80-generic (5.4.0-80.90) ... /etc/kernel/postrm.d/initramfs-tools: update-initramfs: Deleting /boot/initrd.img-5.4.0-80-generic /etc/kernel/postrm.d/zz-update-grub: Sourcing file `/etc/default/grub' Sourcing file `/etc/default/grub.d/init-select.cfg' Generating grub configuration file ... File descriptor 10 (/var/lib/dpkg/triggers/linux-update-5.4.0-77-generic (deleted)) leaked on vgs invocation. Parent PID 3468: /usr/sbin/grub-probe File descriptor 10 (/var/lib/dpkg/triggers/linux-update-5.4.0-77-generic (deleted)) leaked on vgs invocation. Parent PID 3468: /usr/sbin/grub-probe File descriptor 10 (/var/lib/dpkg/triggers/linux-update-5.4.0-77-generic (deleted)) leaked on vgs invocation. Parent PID 3481: /usr/sbin/grub-probe File descriptor 10 (/var/lib/dpkg/triggers/linux-update-5.4.0-77-generic (deleted)) leaked on vgs invocation. Parent PID 3481: /usr/sbin/grub-probe File descriptor 10 (/var/lib/dpkg/triggers/linux-update-5.4.0-77-generic (deleted)) leaked on vgs invocation. Parent PID 3494: /usr/sbin/grub-probe File descriptor 10 (/var/lib/dpkg/triggers/linux-update-5.4.0-77-generic (deleted)) leaked on vgs invocation. Parent PID 3494: /usr/sbin/grub-probe File descriptor 10 (/var/lib/dpkg/triggers/linux-update-5.4.0-77-generic (deleted)) leaked on vgs invocation. Parent PID 3507: /usr/sbin/grub-probe File descriptor 10 (/var/lib/dpkg/triggers/linux-update-5.4.0-77-generic (deleted)) leaked on vgs invocation. Parent PID 3507: /usr/sbin/grub-probe File descriptor 10 (/var/lib/dpkg/triggers/linux-update-5.4.0-77-generic (deleted)) leaked on vgs invocation. Parent PID 3579: /usr/sbin/grub-probe File descriptor 10 (/var/lib/dpkg/triggers/linux-update-5.4.0-77-generic (deleted)) leaked on vgs invocation. Parent PID 3579: /usr/sbin/grub-probe Found linux image: /boot/vmlinuz-5.4.0-84-generic Found initrd image: /boot/initrd.img-5.4.0-84-generic Found linux image: /boot/vmlinuz-5.4.0-81-generic Found initrd image: /boot/initrd.img-5.4.0-81-generic File descriptor 10 (/var/lib/dpkg/triggers/linux-update-5.4.0-77-generic (deleted)) leaked on vgs invocation. Parent PID 3979: /usr/sbin/grub-probe File descriptor 10 (/var/lib/dpkg/triggers/linux-update-5.4.0-77-generic (deleted)) leaked on vgs invocation. Parent PID 3979: /usr/sbin/grub-probe File descriptor 10 (/var/lib/dpkg/triggers/linux-update-5.4.0-77-generic (deleted)) leaked on lvs invocation. Parent PID 4086: /bin/sh done Removing linux-modules-5.4.0-77-generic (5.4.0-77.86) ... Removing linux-modules-5.4.0-80-generic (5.4.0-80.90) ... Here is all the text from the ssh sessions: farokhs-Mac-Pro:~ farokh$ ssh rctmail far...@mail.rocklandtimes.com's password: Welcome to Ubuntu 20.04.3 LTS (GNU/Linux 5.4.0-81-generic x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https
Re: Should /boot be ext2, instead of ext4?
On 9/7/2021 12:58 AM, Pascal Hambourg wrote: Hello, Le 05/09/2021 à 18:47, J. William Campbell a écrit : AFAIK, the on disk format for ext4 is the same as ext2. If the code can read an ext2 filesystem, it can read an ext4 filesystem. I am not sure about that. AFAIK, some ext4 features such as extents create a different on-disk format than ext2 or ext3. The ext2, ext3 and ext4 Linux drivers refuse to mount an ext4 filesystem as ext2 because of unsupported features. Actually, there is a 32 bit rev level defined in the superblock. However, it doesn't distinguish much and isn't the whole story. There are also feature bits that must be supported by any software attempting to read the disk. I think you are correct that incompatible features would cause any software trying to read the disk to fail. ext4 also supports 48 bit block numbers. It is therefore probable u-boot couldn't actually read an ext4 file system if the file sizes were such that extents were used. It doesn't actually matter, because u-boot see options it doesn't recognize and won't try. older u-boots didn't know about ext4, so when they check the version of the filesystem they see a number that they don't understand and give up. IIUC, an ext* filesystem does not have a version number. Instead it has a collection of "features", some of which are supported only by ext4. But IMO the real point is : if ext2 is mandatory for /boot when installing with LVM, why then is it not mandatory when installing without LVM ? Good question. I think it should be. Making the boot partition as simple as possible without adding problems accessing it from "normal" software seems like a good goal. All userspace programs can access ext2 file systems with ease equal to ext4. IMHO it should be a requirement that the file system be ext2. For sure, the boot partition doesn't need 48 bit block numbers an "largefile" support. The kernel/initrd is big but not that big😁.
Re: Should /boot be ext2, instead of ext4?
Hello, Le 05/09/2021 à 18:47, J. William Campbell a écrit : AFAIK, the on disk format for ext4 is the same as ext2. If the code can read an ext2 filesystem, it can read an ext4 filesystem. I am not sure about that. AFAIK, some ext4 features such as extents create a different on-disk format than ext2 or ext3. The ext2, ext3 and ext4 Linux drivers refuse to mount an ext4 filesystem as ext2 because of unsupported features. older u-boots didn't know about ext4, so when they check the version of the filesystem they see a number that they don't understand and give up. IIUC, an ext* filesystem does not have a version number. Instead it has a collection of "features", some of which are supported only by ext4. But IMO the real point is : if ext2 is mandatory for /boot when installing with LVM, why then is it not mandatory when installing without LVM ?
Bug#986491: Acknowledgement (fails to fully configure with debconf low priority)
My main reason for running installs at low priority both at the main debian-installer screen and wanting to do so after the base system is installed is so I can have a fully configured system and not have to go back and reconfigure everything after the installation is finished. If the debconf priority of the installation would be transfered over to the installed system when the base system was being installed then I could have an installation where I was asked about all configuration questions the first time the system was fully installed and when it came up at the end of the installation everything would be ready to go. My question is why is the debconf priority not carried over from the debian-installer to the installed system after the base system is installed as if a user chose expert mode or just low priority I would have thought this would have been the case? On 4/6/2021 5:03 PM, Debian Bug Tracking System wrote: Thank you for filing a new Bug report with Debian. You can follow progress on this Bug here: 986491: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986491. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. As you requested using X-Debbugs-CC, your message was also forwarded to n...@nickgawronski.com (after having been given a Bug report number, if it did not have one). Your message has been sent to the package maintainer(s): Debian Install System Team If you wish to submit further information on this problem, please send it to 986...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system.
