Sounds scary, but it happens at build time, not runtime, so it cannot
brick devices. However, it was a frustrating exercise to uncover it,
as it is not entirely deterministic. This has been there for quite a
long time and I honestly cannot tell why it happened to me now.
Perhaps the exact location of the sparse holes on the filesystem makes
a difference. Or perhaps some versions of mkfs can handle it, others
not. All I know for sure, is that with `sparse` enabled I got massive
filesystem corruption (though sane enough to be somewhat readable) on
the rootfs. Without it, it's clean.
Changelog: Title
Signed-off-by: Kristian Amlie <kristian.amlie@northern.tech>
... not just for EFI configuration. This doesn't fix any immediate
problems, but some U-Boot configurations seem to make a reference to
this, so this is just being proactive.
Changelog: None
Signed-off-by: Kristian Amlie <kristian.amlie@northern.tech>
Because we hardcode the name in the boot loader script, you can never
upgrade to a kernel with a different version string. Fix by using a
generic name and symlinking instead.
Changelog: Title
Signed-off-by: Kristian Amlie <kristian.amlie@northern.tech>
So that we clean the deprecation warning and the multiple errors when
calling this command from CI.
Changelog: None
Signed-off-by: Lluis Campos <lluis.campos@northern.tech>
Changelog: Warn user when converting read-only file systems that would
result in unstable checksums, making the image incompatible with Mender
Delta updates.
Signed-off-by: Lluis Campos <lluis.campos@northern.tech>
Since we chown and chmod files in the overlay, we need to ensure that we
can write to them in each of the bootstrap-rootfs-overlay generation
scripts.
Eventually, I think we should make overlays as tarballs with ownership
and permissions inside the archive to avoid this dance.
Changelog: Title
Signed-off-by: Drew Moseley <drew.moseley@northern.tech>
Changelog: Title
CentOS 8 converted image cannot boot to login shell:
user: no shell: permission denied
It turns out that issue was caused by selinux. Idea for relabeling rootfs
was inspired by this post:
https://forums.centos.org/viewtopic.php?t=48714
Removing of /.autorelabel after action is done automatically and it's necessary.
Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com>
- Issue: #MEN-3725
The following new config variables have been added which closely mirror those used in meta-mender
to give fine grained controll over partition device paths. If partuuid support is enabled then
these partition variables must be used as format doesnt fit device/number variables scheme.
If partuuid support is disabled then partition variables are optional liek in meta-mender.
MENDER_ENABLE_PARTUUID
MENDER_BOOT_PART
MENDER_ROOTFS_PART_A
MENDER_ROOTFS_PART_B
MENDER_DATA_PART
Example:
MENDER_BOOT_PART="/dev/disk/by-partuuid/26445670-f37c-408b-be2c-3ef419866620" #gpt
MENDER_BOOT_PART="/dev/disk/by-partuuid/26445670-01" #dos
MENDER_BOOT_PART="/dev/sda1" #partuuid support disabled
Changelog: Partition UUID support added for gpt/dos partition tables for deterministic booting
Signed-off-by: Dell Green <dell.green@ideaworks.co.uk>
The current code enumerates the partitions and uses the index of this enumeration to query partition parameters rather than the actual partition number that is reported and expected by partx. This might not work in certain cases.
Example:
/dev/sda1
/dev/sda2
/dev/sda5
The partition number of the last partition is 5 but current code will use 3. This PR fixes this so that the actual number reported by partx is used for all operations rather than the enumerated index.
ChangeLog: Fix error when partitions numbers are not sequential
Signed-off-by: Purushotham Nayak <purunaya@cisco.com>
Currently this is redirecting stdout to stderr and then writing the
now blank stdout to the log file. This results in log messages getting
displayed to the screen but missed in the log file.
Changelog: Title
Signed-off-by: Drew Moseley <drew.moseley@northern.tech>