Re: feedback on install of bullseye

2022-09-24 Thread Ray Andrews



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-




feedback on install of bullseye

2022-09-24 Thread Ray Andrews
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.



Re: Re: Ctrl-Alt-Del in systemd

2015-01-31 Thread Ray Andrews

>
> Change that symlink to point to poweroff.target:
>
> # ln -s 
/lib/systemd/system/poweroff.target/etc/systemd/system/ctrl-alt-del.target


That worked fine to change ctrl-alt-del to 'poweroff' butis it possible 
to return to the old 'cold reboot' behavior? I like to go right back to 
the bootloader like it used to be previously.