In 87a19e9048 I merged staging-next into master using the GitHub gui as intended.
In ac241fb7a5 I merged master into staging-next for the next staging cycle, however, I accidentally pushed it to master.
Thinking this may cause trouble, I reverted it in 0be87c7979. This was however wrong, as it "removed" master.
This reverts commit 0be87c7979.
I merged master into staging-next but accidentally pushed it to master.
This should get us back to 87a19e9048.
This reverts commit ac241fb7a5, reversing
changes made to 76a439239e.
When 'grafting' '/nix/store/<hash>-loopback.cfg' from disk onto
'/boot/grub/loopback.cfg' on the iso, the parent 'grub' directory does not
exist yet. In this case it is automatically created and inherits its
attributes, including timestamp, from /nix/store.
This is correct/expected/intentional behavior of xorriso, but has the
undesired result of leaking the timestamps of /nix/store into the iso. For
this reason we put the loopback.cfg in a
'/nix/store/<hash>-loopback.cfg/grub/loopback.cfg' instead, so it will inherit
the attributes from the correctly-timestamped
'/nix/store/<hash>-loopback.cfg/grub' directory.
For the same reason we move '/EFI/boot/efi-background.png' down in the list
so it is grafted after its parent '/EFI/boot' directory is created with
the correct timestamp.
fixes#74944
Slim is abandoned and won't work with wayland.
It's in our best interest to use the display-manager
that makes most sense for Plasma5, sddm.
We've already moved on from it being default in #30890
and the graphical.nix profile, which the virtualbox profile uses,
has sddm anyway.
There's many reason why it is and is going to
continue to be difficult to do this:
1. All display-managers (excluding slim) default PAM rules
disallow root auto login.
2. We can't use wayland
3. We have to use system-wide pulseaudio
4. It could break applications in the session.
This happened to dolphin in plasma5
in the past.
This is a growing technical debt, let's just use
passwordless sudo.
This will keep configuration configuring the size of the /boot partition
still build, while showing the deprecation warning.
In 99.9% of cases I assume ignoring the configuration is better, as the
sd-image builder already is pretty opinionated in that matter.
The slack, seemingly, accounted for more than the minimum required for
slack plus the two partitions.
This change makes the gap a somewhat abstracted amount, but is not
configurable within the derivation.
The current FAT32 partition is kept as it is required for the Raspberry
Pi family of hardware. It is where the firmware is kept.
The partition is kept bootable, and the boot files kept in there until
the following commits, to keep all commits of this series individually
bootable.
This will reduce the confusion at boot, where the only thing visible is
the last message from u-boot; where it looks like the board is
hung, while in reality it's likely resizing partitions.
This will reduce the confusion at boot, where the only thing visible is
the last message from u-boot; where it looks like the Raspberry Pi is
hung, while in reality it's likely resizing partitions.
Prior to this commit an installation over serial via syslinux would
involve:
1. setting bitrate to BIOS's bitrate (typically 115200)
2. setting bitrate to syslinux's bitrate (38400)
3. setting bitrate to stty's bitrate (115200)
By changing syslinux's bitrate to 115200, an installation over serial
is a smoother experience, and consistent with the GRUB2 installation
which is also 115200 bps.
[root@nixos:~]# stty
speed 115200 baud; line = 0;
-brkint ixoff iutf8
-iexten
In a future commit I will add default serial terminals to the syslinux
kernel lines.
