NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
install/56921: sysinst fails to mount /boot when selecting "Use existing GPT partitions"
>Number: 56921
>Category: install
>Synopsis: sysinst fails to mount /boot when selecting "Use existing GPT partitions"
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: install-manager
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon Jul 11 00:50:00 +0000 2022
>Originator: matthew green
>Release: NetBSD 9.99.98
>Organization:
people's front against (bozotic) www (softwar foundation)
>Environment:
System: NetBSD 9.99.98 (GENERIC64) #52: Sun Jul 10 16:29:05 PDT 2022 mrg%yesterday-when-i-was-mad.eterna23.net@localhost:/var/obj/evbarm-aarch64/usr/src/sys/arch/evbarm/compile/GENERIC64
Architecture: aarch64
Machine: evbarm
>Description:
when the installation is interrupted mid-way and restarted, there
are cases where /boot is not mounted before sets are extracted and
thus this partition ends up empty and the system can't boot.
>How-To-Repeat:
i built an evbarm64 release & iso-image, created an empty disk image
for installation, and also a 3rd image with the release sets on them.
i fired up qemu with the ISO and 2 disk images attached, it boots the
ISO, and enters the installer.
from this point i proceeded with a normal installation, but due to
an error with the release sets image, i had to cancel and restart
after the GPT was created, and the ffs (/) and msdos (/boot)
partitions were made (but are empty.)
i replaced the sets disk image, restarted, and the installation went
ahead like normal. i selected the "Use existing GPT partitions"
option during partitioning, and then "Partition sizes ok" next, and
then answered questions about mounting the sets and it extracted the
sets and went through the final configuration steps. i exited the
installer, "halt -p", removed the installer ISO from the disk list
and restarted qemu, but it fails to boot. inspection of the /boot
partition shows it is empty, and the contents are actually in the
root file system.
the only place that file systems are mounted that aren't root are
the ones created by this instance of the installer is in the
make_filesystems() function, which isn't used in this case (though
perhaps it should be, since this is not an ugprade but a fresh
installation.)
i tried running an 'upgrade' afterwards, hoping it would mount /boot
and update it, but it remains empty & non-bootable. suspending
sysinst while it is extracting sets shows that only /targetroot is
mounted, not /targetroot/boot as well.
>Fix:
Home |
Main Index |
Thread Index |
Old Index