Re: feedback on install of bullseye
On Sat 24 Sep 2022 at 18:48:13 (-0700), Ray Andrews wrote: > On 2022-09-24 13:52, Dan Ritter wrote: > > 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. The 'normal' install (sorry, I forget the exact name) > > > ... 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. Erasing the > > > partitions (overwrite with zeros) didn't help. I couldn't figure out how > > > to > > > make it work so backed up and selected 'use whole disk'. > > You are lacking vital information to pass on to us here: what > > necessary step was not completed? > When I tried to bypass partitioning. As I said, the disk was already > partitioned and formatted and had a working copy of Debian 9 on it, so > my thought was to just zero out the existing partitions, which was > offered, and then proceed to install, but the the installer refused to > let me proceed. It seemed to feel the need to create partitions not > reuse them. That would correspond with my reading of §6.3.4.2. > The final partitioning screen showed the partitions > marked 'K' (keep) and I couldn't explain to the installer that they > were free to use. I would only expect to see partitions marked K where the contents were to be strictly left alone by the partitioner, but were to be available for the installer to use. This would include (for GPT disks) EFI and BIOS Boot partitions, and filesystems like, say, /home or /opt that had preexisting contents that were to be mounted in the installer just after the partitioning step. Here's an example of mine that's closest to the setup that you have. The first disk is an internal SSD with Windows on it, and the second is the installer stick. The third disk is an external caddy, sdb, and has #1 backup provision for Windows, #2 BIOS Boot for Grub (necessary with a GPT disk), #3 EFI for booting, #4 an oldoldstable root filesystem that is the one I'm overwriting in the installer, #5 an oldstable root filesystem that I'm keeping but don't need mounting in the installer, and #6 which is an encrypted filesystem that is /home to #5, and will be /home to #4 when I've configured (say, the next day) the new installation to decrypt and mount it. So I'd expect you to have a line like that of #4, and you'd probably also have a line for swap like: │ > #N524.3 MB F swapLinux swapswap which I don't have, as the systems on this caddy aren't intended for any sort of heavy work. ┌┤ [!!] Partition disks ├─┐ │ │ │ This is an overview of your currently configured partitions and mount │ │ points. Select a partition to modify its settings (file system, mount │ │ point, etc.), a free space to create partitions, or a device to │ │ initialize its partition table. │ │ │ │ Configure iSCSI volumes↑ │ │ ▒ │ │ /dev/nvme0n1 - 512.1 GB THNSN5512GPUK TOSHIBA ▒ │ │ > 1.0 MBFREE SPACE ▒ │ │ > #1367.0 MB B fat32 EFI system p ▒ │ │ > #2134.2 MBMicrosoft re ▒ │ │ > #3510.6 GBntfsBasic data p ▒ │ │ > 871.9 kBFREE SPACE ▒ │ │ > #4987.8 MBntfs ▒ │ │ > 1.4 MBFREE SPACE ▒ │ │ SCSI1 (0,0,0) (sda) - 4.0 GB SMI USB DISK ▒ │ │ SCSI2 (0,0,0) (sdb) - 1.0 TB Seagate BUP Slim BK ▒ │ │ > 1.0 MBFREE SPACE ▒ │ │ > #1666.8 GBntfsMicrosoft ba ▒ │ │ > #2 7.3 MB K biosgrubBIOS boot pa ▒ │ │ > #3268.4 MB B K ESP EFI System ▒ │ │ > #4 31.5 GB F ext4Quiz-A/▒ │ │ > #5 31.5 GBext4Quiz-B ▒ │ │ > #6270.2 GBQuiz-Home ▒
Re: feedback on install of bullseye
On Sun, 25 Sept 2022 at 04:03, Ray Andrews wrote:
> ... 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.
> Erasing the partitions (overwrite with zeros) didn't help. I couldn't
> figure out how to make it work so backed up and selected 'use whole disk'.
Hi Ray, I always install to existing partitions, so it is definitely possible.
Debian is very flexible. There are countless installation methods and
options and variations. And they mostly work. They are designed
to be powerful and flexible, but sometimes there is a learning curve.
This is great for people who aren't confused by them, but it makes
it hard to answer questions like yours. Unless you describe exactly
every step, we don't know exactly what you saw or did. And we understand
that providing such information isn't easy for you, either.
The installation guide is here:
https://www.debian.org/releases/stable/i386/ch06s03.en.html#di-partition
If I was to take a guess based on just the above paragraph ... "it kept
complaining that a necessary step was not completed" sounds like you
did not specify appropriate values for "use as" and "mount point".
I'm guessing that you would likely require
'use as' = "ext4 journalling file system" and 'mount point' = "/".
If that was the situation, the installer won't proceed because it won't
touch partitions that have not been specified to "use as", and it cannot
install Debian until it is told where you want the root filesystem ("/").
I have only ever used the installer in expert mode (that just means more
questions have to be answered), so I'm not experienced with how
it behaves in the simpler modes. I guess manual partitioning is the
same in both, if available. I have never used the GUI installer.
> Why couldn't I use existing, functioning ext4 partitions?
You definitely can. But you have to also specify somewhere for the new
installation to go, using the above method.
You might find the below video helpful for overview. Although I don't
necessarily agree with every detail, it might provide context if you
have any further questions.
https://www.youtube.com/watch?v=zMCFQwgtN-g
If you have further questions after reading the documentation, the
more specific you can make the question, so that we can exactly
reproduce your situation, the easier it is for volunteers with limited
time to answer you.
Re: feedback on install of bullseye
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 change
Re: feedback on install of bullseye
On 2022-09-24 13:52, Dan Ritter wrote: 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. The 'normal' install (sorry, I forget the exact name) ... 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. Erasing the partitions (overwrite with zeros) didn't help. I couldn't figure out how to make it work so backed up and selected 'use whole disk'. You are lacking vital information to pass on to us here: what necessary step was not completed? When I tried to bypass partitioning. As I said, the disk was already partitioned and formatted and had a working copy of Debian 9 on it, so my thought was to just zero out the existing partitions, which was offered, and then proceed to install, but the the installer refused to let me proceed. It seemed to feel the need to create partitions not reuse them. The final partitioning screen showed the partitions marked 'K' (keep) and I couldn't explain to the installer that they were free to use. Proceeding, the installer couldn't establish a connection to the web. What network hardware do you have? Wired or wireless? Wired. Pretty basic. As I said, the 'advanced' installer had no trouble whatsoever. The only thing I interacted with was setting the delay time to ten seconds from the IIRC default of three seconds. Seems to me the 'basic' installer could/should be able to handle that. 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. 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. The normal installer is the advanced installer but it pre-answers a lot of questions with the most common answers. Sure, and it was good enough for me, except that it wouldn't connect to the internet as I just mentioned. Why would the installer trash the MBR on a disk that was not involved? Why couldn't I use existing, functioning ext4 partitions? You can. Somewhere in the missing error messages are the clues. It could be that I just wasn't interacting with it properly. If there was a log or something I'd be happy to attach another disk to the machine and try again and send you the results. As long as you guys are interested I'll do anything to help. Thanks Dan -dsr-
Re: feedback on install of bullseye
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. The 'normal' install (sorry, I forget the exact name) > ... 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. Erasing the > partitions (overwrite with zeros) didn't help. I couldn't figure out how to > make it work so backed up and selected 'use whole disk'. You are lacking vital information to pass on to us here: what necessary step was not completed? > Proceeding, the installer couldn't establish a connection to the web. What network hardware do you have? Wired or wireless? > 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. > > 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. The normal installer is the advanced installer but it pre-answers a lot of questions with the most common answers. > Why would the installer trash the MBR on a disk that was not involved? > > Why couldn't I use existing, functioning ext4 partitions? You can. Somewhere in the missing error messages are the clues. -dsr-
feedback on install of bullseye
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. The 'normal' install (sorry, I forget the exact name) ... 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. Erasing the partitions (overwrite with zeros) didn't help. 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. 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. 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. 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. Why would the installer trash the MBR on a disk that was not involved? Why couldn't I use existing, functioning ext4 partitions? 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? ... just in case anyone is interested.
