Stephen's questions

I was running Bullseye (Debian 11?), tried to install kernel 6.x from the bullseye-backports. I am really not sure how to undo it. The new kernel does not work with the graphics driver and a few more. I want to go back to 5.10 kernel.

Here are what I have done:

1. Added the following to the /etc/apt/sources.list

deb http://deb.debian.org/debian/ bullseye-backports main contrib non-free

2. Ran these commands:

 sudo apt install -t bullseye-backports linux-image-amd64 firmware-misc-nonfree
 sudo remove firmware-misc-nonfree
 sudo apt -s remove linux-image-amd64

The apt policy linux-image-amd64 shows:

linux-image-amd64:
  Installed: 5.10.209-2
  Candidate: 5.10.209-2
  Version table:
     6.1.55-1~bpo11+1 100
        100 http://deb.debian.org/debian bullseye-backports/main amd64 Packages
 *** 5.10.209-2 500
        500 http://deb.debian.org/debian bullseye/main amd64 Packages
        100 /var/lib/dpkg/status
     5.10.205-2 500
        500 http://security.debian.org/debian-security bullseye-security/main amd64 Packages

However, I am not sure if I am currently using any of those kernels:

$ uname -a
Linux debian 5.10.0-28-amd64 #1 SMP Debian 5.10.209-2 (2024-01-31) x86_64 GNU/Linux

The following is the Debian-related part of /boot/grub/grub.cfg:

menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-da96684c-0696-43ed-ba36-54d11861e7d4' {
    load_video
    insmod gzio
    if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
    insmod part_gpt
    insmod ext2
    search --no-floppy --fs-uuid --set=root da96684c-0696-43ed-ba36-54d11861e7d4
    echo    'Loading Linux 6.1.0-0.deb11.13-amd64 ...'
    linux   /boot/vmlinuz-6.1.0-0.deb11.13-amd64 root=UUID=da96684c-0696-43ed-ba36-54d11861e7d4 ro noresume quiet
    echo    'Loading initial ramdisk ...'
    initrd  /boot/initrd.img-6.1.0-0.deb11.13-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 'gnulinux-advanced-da96684c-0696-43ed-ba36-54d11861e7d4' {
    menuentry 'Debian GNU/Linux, with Linux 6.1.0-0.deb11.13-amd64' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-6.1.0-0.deb11.13-amd64-advanced-da96684c-0696-43ed-ba36-54d11861e7d4' {
        load_video
        insmod gzio
        if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
        insmod part_gpt
        insmod ext2
        search --no-floppy --fs-uuid --set=root da96684c-0696-43ed-ba36-54d11861e7d4
        echo    'Loading Linux 6.1.0-0.deb11.13-amd64 ...'
        linux   /boot/vmlinuz-6.1.0-0.deb11.13-amd64 root=UUID=da96684c-0696-43ed-ba36-54d11861e7d4 ro noresume quiet
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd.img-6.1.0-0.deb11.13-amd64
    }
    menuentry 'Debian GNU/Linux, with Linux 6.1.0-0.deb11.13-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-6.1.0-0.deb11.13-amd64-recovery-da96684c-0696-43ed-ba36-54d11861e7d4' {
        load_video
        insmod gzio
        if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
        insmod part_gpt
        insmod ext2
        search --no-floppy --fs-uuid --set=root da96684c-0696-43ed-ba36-54d11861e7d4
        echo    'Loading Linux 6.1.0-0.deb11.13-amd64 ...'
        linux   /boot/vmlinuz-6.1.0-0.deb11.13-amd64 root=UUID=da96684c-0696-43ed-ba36-54d11861e7d4 ro single noresume
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd.img-6.1.0-0.deb11.13-amd64
    }
    menuentry 'Debian GNU/Linux, with Linux 5.10.0-28-amd64' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.10.0-28-amd64-advanced-da96684c-0696-43ed-ba36-54d11861e7d4' {
        load_video
        insmod gzio
        if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
        insmod part_gpt
        insmod ext2
        search --no-floppy --fs-uuid --set=root da96684c-0696-43ed-ba36-54d11861e7d4
        echo    'Loading Linux 5.10.0-28-amd64 ...'
        linux   /boot/vmlinuz-5.10.0-28-amd64 root=UUID=da96684c-0696-43ed-ba36-54d11861e7d4 ro noresume quiet
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd.img-5.10.0-28-amd64
    }
    menuentry 'Debian GNU/Linux, with Linux 5.10.0-28-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.10.0-28-amd64-recovery-da96684c-0696-43ed-ba36-54d11861e7d4' {
        load_video
        insmod gzio
        if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
        insmod part_gpt
        insmod ext2
        search --no-floppy --fs-uuid --set=root da96684c-0696-43ed-ba36-54d11861e7d4
        echo    'Loading Linux 5.10.0-28-amd64 ...'
        linux   /boot/vmlinuz-5.10.0-28-amd64 root=UUID=da96684c-0696-43ed-ba36-54d11861e7d4 ro single noresume
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd.img-5.10.0-28-amd64
    }
    menuentry 'Debian GNU/Linux, with Linux 5.10.0-26-amd64' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.10.0-26-amd64-advanced-da96684c-0696-43ed-ba36-54d11861e7d4' {
        load_video
        insmod gzio
        if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
        insmod part_gpt
        insmod ext2
        search --no-floppy --fs-uuid --set=root da96684c-0696-43ed-ba36-54d11861e7d4
        echo    'Loading Linux 5.10.0-26-amd64 ...'
        linux   /boot/vmlinuz-5.10.0-26-amd64 root=UUID=da96684c-0696-43ed-ba36-54d11861e7d4 ro noresume quiet
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd.img-5.10.0-26-amd64
    }
    menuentry 'Debian GNU/Linux, with Linux 5.10.0-26-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.10.0-26-amd64-recovery-da96684c-0696-43ed-ba36-54d11861e7d4' {
        load_video
        insmod gzio
        if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
        insmod part_gpt
        insmod ext2
        search --no-floppy --fs-uuid --set=root da96684c-0696-43ed-ba36-54d11861e7d4
        echo    'Loading Linux 5.10.0-26-amd64 ...'
        linux   /boot/vmlinuz-5.10.0-26-amd64 root=UUID=da96684c-0696-43ed-ba36-54d11861e7d4 ro single noresume
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd.img-5.10.0-26-amd64
    }
    menuentry 'Debian GNU/Linux, with Linux 5.10.0-22-amd64' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.10.0-22-amd64-advanced-da96684c-0696-43ed-ba36-54d11861e7d4' {
        load_video
        insmod gzio
        if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
        insmod part_gpt
        insmod ext2
        search --no-floppy --fs-uuid --set=root da96684c-0696-43ed-ba36-54d11861e7d4
        echo    'Loading Linux 5.10.0-22-amd64 ...'
        linux   /boot/vmlinuz-5.10.0-22-amd64 root=UUID=da96684c-0696-43ed-ba36-54d11861e7d4 ro noresume quiet
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd.img-5.10.0-22-amd64
    }
    menuentry 'Debian GNU/Linux, with Linux 5.10.0-22-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.10.0-22-amd64-recovery-da96684c-0696-43ed-ba36-54d11861e7d4' {
        load_video
        insmod gzio
        if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
        insmod part_gpt
        insmod ext2
        search --no-floppy --fs-uuid --set=root da96684c-0696-43ed-ba36-54d11861e7d4
        echo    'Loading Linux 5.10.0-22-amd64 ...'
        linux   /boot/vmlinuz-5.10.0-22-amd64 root=UUID=da96684c-0696-43ed-ba36-54d11861e7d4 ro single noresume
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd.img-5.10.0-22-amd64
    }
}

Here are the vmlinuz* files I actually have under /boot/:

$ ls -1 /boot/vmlinuz*
/boot/vmlinuz-5.10.0-22-amd64
/boot/vmlinuz-5.10.0-26-amd64
/boot/vmlinuz-5.10.0-28-amd64
/boot/vmlinuz-6.1.0-0.deb11.13-amd64

Everything works if I explicitly choose the 5.10.0-28 kernel from the grub menu on boot. I think I have to effectively remove the boot entry from grub.cfg, the 6.1x kernel-related files and headers.

I am worried if I do so manually, I will mess up the dependency list for Debian's package management system. And, I do not need the bullseye-backports any more.

I removed the entry from /etc/apt/sources.list and apt update -y followed by apt upgrade. It did not help. Not sure what should be done.

I will attach the minimized test case below. However, it is a simple Dockerfile that has these lines:

VOLUME ["/sys/fs/cgroup"]
CMD ["/lib/systemd/systemd"]

It is Debian:buster-slim based image, and runs systemd inside the container. Effectively, I used to run the container like this:

$ docker run  --name any --tmpfs /run \
    --tmpfs /run/lock --tmpfs /tmp \
    -v /sys/fs/cgroup:/sys/fs/cgroup:ro -it image_name

It used to work fine before I upgraded a bunch of host Linux packages. The host kernel/systemd now seems to default cgroup v2. Before, it was cgroup. It stopped working. However, if I give the kernel option so that the host uses cgroup, then it works again.

Without giving the kernel option, the fix was to add --cgroupns=host to docker run besides mounting /sys/fs/cgroup as read-write (:rw in place of :ro).

I'd like to avoid forcing the users to give the kernel option. Although I am far from an expert, forcing the host namespace for a docker container does not sound right to me.

I am trying to understand why this is happening, and figure out what should be done. My goal is to run systemd inside a docker, where the host follows cgroup v2.

Here's the error I am seeing:

$ docker run --name any --tmpfs /run --tmpfs /run/lock --tmpfs /tmp \
    -v /sys/fs/cgroup:/sys/fs/cgroup:rw -it image_name
systemd 241 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
Detected virtualization docker.
Detected architecture x86-64.

Welcome to Debian GNU/Linux 10 (buster)!

Set hostname to <5e089ab33b12>.
Failed to create /init.scope control group: Read-only file system
Failed to allocate manager object: Read-only file system
[!!!!!!] Failed to allocate manager object.
Exiting PID 1...

It does not look right but especially this line seems suspicous:

Failed to create /init.scope control group: Read-only file system

It seems like there should have been something before /init.scope. That was why I reviewed the docker run options, and tried the --cgroupsns option. If I add the --cgroupns=host, it works. If I mount /sys/fs/cgroup as read-only, then it fails with a different error, and the corresponding line looks like this:

Failed to create /system.slice/docker-0be34b8ec5806b0760093e39dea35f4305262d276ecc5047a5f0ff43871ed6d0.scope/init.scope control group: Read-only file system

To me, it is like the docker daemon/engine fails to configure XXX.slice or something like that for the container. I assume that docker may be to some extend responsible for giving the namespace but something is not going well. However, I can't be so sure at all. What would be the issue/fix?

The Dockerfile I used for this experiment is as follows:

FROM debian:buster-slim

ENV container docker
ENV LC_ALL C
ENV DEBIAN_FRONTEND noninteractive

USER root
WORKDIR /root

RUN set -x

RUN apt-get update -y \
    && apt-get install --no-install-recommends -y systemd \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* \
    && rm -f /var/run/nologin

RUN rm -f /lib/systemd/system/multi-user.target.wants/* \
    /etc/systemd/system/*.wants/* \
    /lib/systemd/system/local-fs.target.wants/* \
    /lib/systemd/system/sockets.target.wants/*udev* \
    /lib/systemd/system/sockets.target.wants/*initctl* \
    /lib/systemd/system/sysinit.target.wants/systemd-tmpfiles-setup* \
    /lib/systemd/system/systemd-update-utmp*

VOLUME [ "/sys/fs/cgroup" ]

CMD ["/lib/systemd/systemd"]

I am using Debian. The docker version is 20.10.3 or so. Google search told me that docker supports cgroup v2 as of 20.10 but I don't actually understand what that "support" means.

In short, if I do dd disk-to-disk (e.g. /dev/sda to /dev/sdb), is the capacity of the whole disk also copied?

For example, if sda is actually 1TB and sdb 2TB, after the dd, which would a Linux system regard sdb as, 1TB or 2TB?

I assume that the disk capacity is recorded in a separate ROM or small non-volatile storage, not in any sector of the disk. Or, maybe a couple of sectors of a physical disk might be always reserved.

I'd like to migrate systems on an old 1TB hard disk to a new 2TB one with minimal pain. The old disk won't be used. I thought dd might do. The only part that I wasn't sure is if I do dd & the size of the disk capacity is ever copied just like the partition table, the new 2TB disk would become 1TB. I wanted to make sure before actually doing dd.

My Google search was not fruitful, so finally I decided to post a question here.

If all the systems were Linux, I'd consider rsync partition-to-partition & grub-install. However, unfortunately, I have one Windows and do not have a Windows installation usb. I am not sure how to re-install and/or reconfigure Windows boot loader after rsync.