On Sat 24 Sep 2022 at 10:45:56 (-0700), Ray Andrews wrote: > To whom might read this. I can't boil this down to a formal bug > report but for what it's worth: > > BULLSEYE INSTALL, 2022-09-23: > > Decided to do a virgin install of bullseye to my /dev/sdb while > keeping /dev/sda devoted to Stretch. Got the installer onto a USB > stick, and proceeding normally.
For a wireless netinst install, you'd need the firmware inclusive version of the installer, but for a wired netinst install, either with or without firmware would normally suffice. > The 'normal' install (sorry, I forget > the exact name) ... I'm assuming, by contrast with the expert one, it's default installer, in either text or graphics mode. As far as I can glean from the Installation Guide, I think you can either (§6.3.4) automatically partition a whole disk, or (§6.3.4.2) manually /create/ partitions in one of three ways. That would suggest that to re-use existing partitions, as I do, you need to use the advanced installer. As Dan says, the two installers are the same, but just ask different levels of questions. The partitioner can be told which existing partitions are to be used for what perpose, and even whether they should be formatted or not. (Obviously reusing an existing filesystem with files on it is at your own risk.) > I get as far as partitioning and although the disk > (sdb) is already partitioned and formatted and working fine, it seemed > to be impossible to just leave things as they were and install to the > existing partitions, it kept complaining that a necessary step was not > completed. If this is the «Finish partitioning and write changes to disk» step, then yes, I believe it's essential because it's the step that actually ties together the partitions, mount points, and usages in the "mind" of the installer. As far as actions are concerned, this step can involve almost none. > Erasing the partitions (overwrite with zeros) didn't help. This would be futile in any case, as the installer is expected to format them with a filesystem (or swap). > I couldn't figure out how to make it work so backed up and selected > 'use whole disk'. > > Proceeding, the installer couldn't establish a connection to the web. That surprised me, in that the installer should have set the clock via machines on the internet, but I do see (§6.3.3) that the non-expert installer can side-step the issue in that step. I don't know why that is the case, or whether it could be related to using a DVD of packages. > I aborted the install since I couldn't go forward anyway. Boot to sda > and ... the installer had trashed the MBR of *both* disks and the > machine was unbootable. I attached another backup disk, booted to > that, mounted my Stretch partitions on sda, reran LILO, and that was > fine, I could boot Stretch. But the installer also trashed the swap > partition on sda -- I had to run mkswap. But no permanent damage was > done. > > Why would the installer trash the MBR on a disk that was not involved? Your narrative doesn't contain enough detail to even begin to answer that question. We don't even knows what you mean by trash. In general, MBRs are written (by "installation") or executed (at boot time) but not read. Did you compare them with a known good copy, or see they were, say, zeroed, or did it/they just not work? You don't say whether any letters of L I L O appeared, or whether any boot flagged partitions had lost their flag. What happens if both disks have flagged partitions, and what mechanism chooses which disk to boot from. Is it easy to distinguish the sda/sdb disks apart from each other using only what's displayed in the partitioner or by the installer (sdX assignments being unstable). These are some of the factors involved. > Trying again, I disconnected sda to keep it from getting mauled a > second time and proceeded with the 'advanced' installer, again > selecting 'use entire disk', this time the installer took the extra > steps to get the network up and running and the install completed > quite smoothly. That certainly suggests that an appropriate installer was chosen (my first paragraph). > Shouldn't the 'normal' install do whatever is needed to get the > network running? the advanced install had no problem there, I didn't > have to intervene it just got it done. I think I covered that at §6.3.3. As I said, I don't know the rationale. > Why couldn't I use existing, functioning ext4 partitions? The advanced installer can use existing partitions; you just didn't select that method according to the narrative above. I'm not sure what you imply by "functioning"; whether anything more than that you've used them in the past. I don't know of a method to install Debian into a preexisting encrypted filesystem, something I've never needed to attempt. (Disclaimer: I know nothing about any limitations of disk size, geometry, or addressability concerning LILO booting.) > If one does have to abort, wouldn't it be better if no changes at all > were made to anything? Why have a trashed system even when one had to > abort? In other words, why not check that the network is available > *before* trashing the MBR of both disks and the partition table of sdb > and the swap partition of the other disk? In the context of disk contents, the network is irrelevant, so I'll leave that aside. With one exception, if you back out before the step I «quoted» above, then no changes will be made to the disk. If you do execute that step, then obviously the changes asked for will be made. That will include formatting any partitions /set to be used/ as swap, which will generate new UUIDs and LABELs. That's easily rectified if another system assumes that the old values are still set. To ascertain what changes were made would require seeing your version of the table shown just before §6.3.4.3 in the Installation Guide. And apart from that, we also have no idea what was zeroed by you, and the potential effects. AFAIK, the partitioning step does nothing with either MBR; that would come later, normally with installing Grub. LILO is only mentioned once, in §C.5.1, half-a-dozen paragraphs down. Others here still use it and would advise on how you deal with configuring it. As for the exception mentioned above, that only involves installing with LVM ± encryption (neither of which you've mentioned). Those steps have to be separately confirmed after warnings have been given about their unrevokability. > ... just in case anyone is interested. There usually are. And it can be useful to make suggestions for the (next version's) Installation Guide. Cheers, David.
