pop-os / systemd Goto Github PK

Is your feature request related to a problem? Please describe.
Currently journald has no set limit on how much storage space can be used, or should be kept free causing boot issues and other unwanted conditions.

Describe the solution you'd like
/etc/systemd/journald.conf has an option that can be set to limit the amount of space the logs can take up on the system (SystemMaxUse) as well as an option to ensure that a certain amount of space is left on the drive (SystemKeepFree). I believe both of these need to be set to mitigate the issues users are facing.

For an example I've set the two options locally as follows:
SystemMaxUse=1GB
SystemKeepFree=10GB.

Describe alternatives you've considered

There are a few other options that could be set if we are concerned with missing important information when setting the log size too low. Along with the above options there are rotation options that can be set which are labeled "MaxFileSec" and "MaxRetentionSec".

Notes:
I'm currently testing this solution to make sure it works as expected. Will verify and update ticket.

Description:

I've followed the classic procedure to install Windows and Linux in dual boot. First I installed Windows in UEFI mode, then I use a bootable PopOS key to resize the main Windows partition; I created a Linux partition as well as a 500MB /boot/efi partition in the remaining space.

My problem is, systemd-boot can't seem to detect the Windows bootloader.

When I display the systemd-boot menu, it only lists PopOS as a possible boot option, even though I can launch Windows from my BIOS menu with no problem.

Environment:

Pos OS version is 20.04.

Running bootctl gives the following output:

System:
    Firmware: UEFI 2.70 (American Megatrends 5.14)
Secure Boot: disabled
Setup Mode: setup

Current Boot Loader:
    Product: systemd-boot 245.4-4ubuntu3.1pop0~1590695674~20.04~eaac747
    Features: ✓ Boot counting
            ✓ Menu timeout control
            ✓ One-shot menu timeout control
            ✓ Default entry control
            ✓ One-shot entry control
            ✓ Support for XBOOTLDR partition
            ✓ Support for passing random seed to OS
            ✓ Boot loader sets ESP partition information
        ESP: /dev/disk/by-partuuid/585919b8-7f1b-4f94-a0b1-6ff195d07515
        File: └─/EFI/SYSTEMD/SYSTEMD-BOOTX64.EFI

Random Seed:
Passed to OS: yes
System Token: set
    Exists: yes

Available Boot Loaders on ESP:
        ESP: /boot/efi (/dev/disk/by-partuuid/585919b8-7f1b-4f94-a0b1-6ff195d07515)
        File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 245.4-4ubuntu3.1pop0~1590695>
        File: └─/EFI/BOOT/BOOTX64.EFI (systemd-boot 245.4-4ubuntu3.1pop0~1590695674~20.04~e>

Boot Loaders Listed in EFI Variables:
        Title: Linux Boot Manager
        ID: 0x0003
    Status: active, boot-order
    Partition: /dev/disk/by-partuuid/585919b8-7f1b-4f94-a0b1-6ff195d07515
        File: └─/EFI/SYSTEMD/SYSTEMD-BOOTX64.EFI

        Title: Windows Boot Manager
        ID: 0x0000
    Status: active, boot-order
    Partition: /dev/disk/by-partuuid/42f0d8f0-13e0-41cf-bc36-ac80dccc54fd
        File: └─/EFI/MICROSOFT/BOOT/BOOTMGFW.EFI

        Title: UEFI OS
        ID: 0x0009
    Status: active, boot-order
    Partition: /dev/disk/by-partuuid/585919b8-7f1b-4f94-a0b1-6ff195d07515
        File: └─/EFI/BOOT/BOOTX64.EFI

Boot Loader Entries:
        $BOOT: /boot/efi (/dev/disk/by-partuuid/585919b8-7f1b-4f94-a0b1-6ff195d07515)

Default Boot Loader Entry:
        title: Pop!_OS
        id: Pop_OS-current.conf
    source: /boot/efi/loader/entries/Pop_OS-current.conf
        linux: /EFI/Pop_OS-3ce60b75-530a-4cad-9e80-5156a8e6bb56/vmlinuz.efi
    initrd: /EFI/Pop_OS-3ce60b75-530a-4cad-9e80-5156a8e6bb56/initrd.img
    options: root=UUID=3ce60b75-530a-4cad-9e80-5156a8e6bb56 ro quiet loglevel=0 systemd.sh>

Notice the Windows Boot Manager entry under Boot Loaders Listed in EFI Variables. It seems systemd-boot is somewhat aware that my Windows partition exists, it just won't detect it as something that can be booted from.

(running bootctl install doesn't seem to change anything)

The /boot/efi/ directories look like this:

/boot/efi/EFI
├── BOOT
│   └── BOOTX64.EFI
├── Linux
├── Pop_OS-3ce60b75-530a-4cad-9e80-5156a8e6bb56
│   ├── cmdline
│   ├── initrd.img
│   └── vmlinuz.efi
└── systemd
    └── systemd-bootx64.efi

/boot/efi/loader/entries/
└── Pop_OS-current.conf

So the directories that should have been populated with the Windows Bootloader somehow aren't.

Steps to reproduce:

• Install Windows on a new computer.
• Install Pop OS 20.04 in dual-boot.
• Restart computer. Pop OS is automatically loaded, Windows isn't listed.

systemd version the issue has been seen with

248.3-1ubuntu8.2pop0~1642619863~21.10~47b8972

Used distribution

Pop!_OS 21.10

Expected behaviour you didn't see

Changing the keyboard during the bootmanager menu is possible without any issues.

Unexpected behaviour you saw

Unplugging or plugging a keyboard will freeze systemd-boot. Only a hard reset works to get a working system again. The counter stops the countdown. Pressing any keys to select an entry does not work.

Steps to reproduce the problem

1. Boot system
2. When systemd-boot menu is showing unplug your keyboard

Is your feature request related to a problem? Please describe.
Consider building with TPM2 support enabled to enable enrolling luks keys in TPM2 modules
Curently running sudo systemd-cryptenroll --tpm2-device=list produces following error message:
TPM2 not supported on this build

Describe the solution you'd like
TPM2 support enabled during build

Describe alternatives you've considered
Clevis is an alternative to systemd-cryptenroll however given pop-os tight integration with systemd a more native solution would be welcome

Distribution (run cat /etc/os-release):

Pop!_OS 19.04

Issue/Bug Description:

When changing the device name in the "About" page, the hosts file is not updated to reflect the new name, which causes programs to respond slowly, such as when running a sudo command in a terminal window or opening pretty much any app / program. The delay is anywhere between five seconds to upwards of thirty.

Updating /etc/hosts to reflect the new name solves the problem instantly and operation returns to normal.

Steps to reproduce (if you know):

Change the default entry in the "Device name" field of the About page in Settings | Details to anything but the default and reboot the system to see the effects.

Expected behavior:

Ideally, when changing the Device name, it should update the hosts file entry to reflect this to prevent any issues.

systemd version the issue has been seen with
Installed: 242-7ubunutu37pop0158679162019.10~8ba57c6

Used distribution
Pop!OS 19.10 trying to upgrade to 20.04

Expected behaviour you didn't see
Upgrade to proceed normally. On reboot systemd errors with unexpected spaces in the fstab and drops to emergency shell.

Unexpected behaviour you saw
On reboot systemd errors with unexpected spaces in the fstab and drops to emergency shell.

Steps to reproduce the problem
Have spaces in the name of the mount point in your fstab and try and upgrade

Stage updates:

• focal: https://launchpad.net/ubuntu/+source/systemd/245.4-4ubuntu3.5
• groovy: https://launchpad.net/ubuntu/+source/systemd/246.6-1ubuntu1.2

Test updates:

• focal: d10e396
• groovy: d80d6a1

Is your feature request related to a problem? Please describe.

As described in systemd/systemd#18092, prior to v248 (in the PR systemd/systemd#18110) there was no way in systemd to hook into the separate steps involved in suspend-then-hibernate. As a result, nvidia has no way to properly resume (it currently just locks the screen up, requiring a reboot) from suspend-then-hibernate. Having suspend-then-hibernate working is important to me because I like to close my lid when I'm going to step away from my computer for some indeterminate amount of time; if I'm back at my laptop within 15 minutes, I'd prefer to just wake from suspend and get back to work, instead of having to boot back up, decrypt file system, resume from hibernation, and then log back in. Otherwise, I really want my laptop to hibernate, because my laptop (gaze16) battery drains over night.

Describe the solution you'd like
Updating to at least v248 (or for now just cherry-picking systemd/systemd#18110) should allow for for amending the nvidia sleep script (/usr/lib/systemd/system-sleep/nvidia) so that sleep-then-hibernate works.

Describe alternatives you've considered
No good alternatives that I can think of.

Distribution (run cat /etc/os-release):

20.04, latest Intel ISO

Related Application and/or Package Version (run apt policy $PACKAGE NAME):

Installer boot script

Issue/Bug Description:

Right after "Running /scripts/casper-premount ... done" there is "stdin: Invalid argument". Then it continues with "Creating debconf-communicate"

Steps to reproduce (if you know):

Run the latest installer ISO.

Expected behavior:

Not this.

Other Notes:

Is your feature request related to a problem? Please describe.
Ubuntu (and PopOS by extension) is incapable of sealing luks password to TPM2 device by default

Describe the solution you'd like
Integrate patches from https://github.com/wmcelderry/systemd_with_tpm2 into PopOS so that this mechanism works ootb

Describe alternatives you've considered
Without this even with user-controlled secure boot enabled users will still need to type their passwords on every boot

The systemd version you checked that didn't have the feature you are asking for