Recover config file from ISO during (re)install?
-
How did that additional disk appear in pfSense? Like adaX?
I expect it to check anything that appears under
sysctl kern.disks:
https://github.com/pfsense/pfsense/blob/master/src/etc/rc.ecl#L57 -
@stephenw10 It appears as da1. (da0 being the disk I'd want to install to). It seems to have two partitions, da1p1 and da1p2, even though I just made a single FAT32 partition on it. Obviously when I run dmesg, the 4GB disk I created with the config file on shows up, but I'm too limited in terms of regular linux commands that are missing is this minimal recovery shell, so I can't see too much. If you need any specific output, just tell me.
-
You should see the list of devices it checks during boot as the external config locator runs. That should be the same list it tries to recover from at install.
Be careful because if/when this does work it will pull in that config at every boot until you detach the disk!
Otherwise I would try to mount the drive from the recovery prompt and check it:
mount_msdosfs /dev/da1p1 /mnt ls -ls /mnt -
@stephenw10 Yeah that's what I already did manually. However, even after mounting I manually have to copy the config file to /tmp/recovered_config/config.xml for it to work, and then everything works fine. But if after mounting, I exit to the install-menu, and choose recovery config, it still doesn't find it. Doesn't matter if it's in / or /conf of that disk.
-
So what does
ls -ls /mntactually show?What does the ECL show it's checking at first boot if the drive is still attached?
-
If I don't manually mount anything, ie. after a reboot with an empty disk attached as SCSI:0:0, a 4GB disk attached to SCSI:0:1 formatted as FAT32 with the config in it, and a DVD drive with the ISO, /mnt is completely empty. Output of ls -ls /mnt: total 0
Not sure what you mean by your other question?
-
I meant how does that appear after you mount it? And which partition did you mount?
During a normal boot the External Config Locator attempts to pull in a config from an attached drive and it shows the drives it's looking at:
External config loader 1.0 is now starting... da0s1 da0s2 da0s2a da0s3 nda0p1 nda0p2 nda0p4Does it show the attached drive in your VM?
-
I can't properly copy / paste as booting from ISO doesn't give me network, and I don't have serial on Hyper-V. So I'll try like this:
During boot I don't see the ECL logging anything at all, even with verbose enabled. Or it's too quick for me to see. What log file would that be in? I attached /var/log/messages, but after recognizing the disks, I don't see it referenced again. Note that I actually ran the config-recovery option before taking the log file. My apologies if I'm misunderstanding.
-
Ok great. And in the conf directory you have config.xml?
The ECL runs during a normal boot of the installed pfSense not booting the installer. But it looks in the same places as the config recovery that runs in the installer so if it appears there I'd expect it to also recover from there.
-
@stephenw10 said in Recover config file from ISO during (re)install?:
Ok great. And in the conf directory you have config.xml?
The ECL runs during a normal boot of the installed pfSense not booting the installer. But it looks in the same places as the config recovery that runs in the installer so if it appears there I'd expect it to also recover from there.
yes, config.xml is in /conf.
-
Ok alternative approach!
Drop to the rescue shell from the installer then run the config recovery manually from there like:
/root/recover_configxml.shThat will then show exactly what it's doing and you'll be able to see it.
-
That simply shows:
No suitable disk partitions found
whether I mounted the partition or not.
-
Hmm, Ok I guess that only looks for existing installs. Let me see....
-
Yup. OK try:
/usr/libexec/bsdinstall/copy_configxml_from_usbIt should check anything that shows up as fat32 in
gpart show -pso that should include da1p2. -
It shows as ms-basic-data, I'm not sure what it should say. But it's formatted as FAT32 in Windows, and BSD can surely read it.
-
Ok that's some windows formatting problem then. It's not marking it as fat32. It should show like:
[23.09.1-RELEASE][root@8200.stevew.lan]/root: gpart show -p => 40 234441568 nda0 GPT (112G) 40 532480 nda0p1 efi (260M) 532520 1024 nda0p2 freebsd-boot (512K) 533544 984 - free - (492K) 534528 2097152 nda0p3 freebsd-swap (1.0G) 2631680 231809024 nda0p4 freebsd-zfs (111G) 234440704 904 - free - (452K) => 1 1978367 da0 MBR (966M) 1 66584 da0s1 efi (33M) 66585 1727568 da0s2 freebsd [active] (844M) 1794153 131072 da0s3 fat32 (64M) 1925225 53143 - free - (26M) => 0 1727568 da0s2 BSD (844M) 0 16 - free - (8.0K) 16 1727552 da0s2a freebsd-ufs (844M) -
That's a Windows partitioning issue and unfortunately it's not safe to assume anything based on it. Partitions with that type could be NTFS, ExFAT, FAT32, whatever, so we can't just add code to allow that type alongside the current code.
https://en.wikipedia.org/wiki/Microsoft_basic_data_partition
You'll need to find a way to change that partition type. Some googling suggests it can be done but it's not exactly trivial.
-
hmm weird. Even when I create a FAT partition (ie. FAT16) it's reported as ms-basic data. We have minitool partition wizard, which is a bit like GParted for Windows, very extensive, but when I create FAT or FAT32 with that, it's still the same. As I think the recovery console misses mkfs, I booted gparted live, and THAT actually saw my 'MS FAT16' partition as FAT16:
So I created a new 1GB FAT32 partition using GParted:
And that still shows up as ms-basic-data
So as last test I booted an old laptop with pfsense 2.7.2 installer, and inserted another USB stick. That is actually reported as fat32lba (opposed to just fat32 in your reply). But the FAT32 partitions on the internal SSD (Windows 10) also report as ms-basic-data.
What I think is weird is that the gparted created partitions are still reported as ms-basic-data. Could that be a BSD thing on harddisks / SSD maybe? As mount_msdosfs can actually read them fine as well, so they do seem to be valid partitions.
Anyway, if the way BSD identifies partition changed, maybe an update would be a nice to have. If not, I wouldn't bother honestly, as it's a bit of a edge-case anyway. If recovery from ISO is planned though, that requires scanning ISO9600 filesystem, so maybe at the same time ms-basic-data could be added as well. But I haven't looked into the code, and I leave that descission to you ;-)
If there's anything else I can test, or create a partition with from pfSense recovery shell itself, let me know and I'll test.
Thanks so far!
-
It should still match fat32lba:
https://github.com/pfsense/FreeBSD-src/blob/devel-main/usr.sbin/bsdinstall/scripts/copy_configxml_from_usb#L40The disk I showed there is just the pfSense installation image. So you could try adding that as an attached disk.
-
Oh I'm sure it would've found the config on the USB stick on that laptop, as that was indeed seen as fat32. Didn't even try that, as gpart showed FAT32 there.
For test with my vhdx, I modded line 40 in copy_configxml_from_usb to:
for try_device in `/sbin/gpart show -p | /usr/bin/egrep '(fat32|\!11|\!12|\!14)|ms-basic-data' | /usr/bin/awk '{print $3;}'`; doand then it works just fine, just as with an USB stick. As the ms-basic-data seems to be how BSD reports these valid FAT/FAT32 drives on at least Hyper-V disks, even when created from Linux / gparted, it might be nice to have that functionality. For some weird edge-case like this, where someone is re-installing a virtualized pfSense without access to USB and no ISO fetching yet, I actually don't see an issue adding that line in the distribution, and it might just save someone some time in a disaster.
