Bug#1037238: debian-installer: separate /usr ruins opening a shell in rescue

2023-06-21 Thread Pascal Hambourg

On 21/06/2023 at 03:55, tomas k wrote:

On Fri, 2023-06-09 at 13:32 +0200, Pascal Hambourg wrote:


With /usr-merged layout (default since buster IIRC), a separate /usr
must be mounted before running any program. The initramfs mounts a
separate /usr before running init, but the installer rescue mode did not
before running a shell. This feature has been added to bookworm
installer (rescue 1.86) but not backported to bullseye installer
AFAIK.


That explains it. I can't open the root patitiion, because rescue
system says it's not a root partition until I try what is actually
/usr. But, I have finally given up separate /usr, and just lumped it in
with the pile. But in bookworm it should work?


Bookworm's installer rescue mode should detect a separate /usr in 
/etc/fstab and offer to mount it before running a shell in the root 
partition, like previous versions already did with a separate /boot or 
/boot/efi. Other improvements include properly unmounting nested 
filesystems (e.g. /boot/efi then /boot).




Bug#1037238: debian-installer: separate /usr ruins opening a shell in rescue

2023-06-20 Thread tomas k
On Fri, 2023-06-09 at 13:32 +0200, Pascal Hambourg wrote:
> On 09/06/2023 at 01:27, tomas k wrote:
> > 
> > I'm on a different system than the problem one. For years I have
> > had to boot knoppix
> > and run a chroot to change a password I've forgotten, because I use
> > a separate usr partition,
> > and rescue thinks it's the root directory. Butr without etc it's
> > not going to work.
> 
> Rescue mode does not "think" anything about any partition. It is up
> to 
> the user to select the proper root partition, although I admit this 
> might be improved by providing more information about available 
> partitions to the user.
> 
> With /usr-merged layout (default since buster IIRC), a separate /usr 
> must be mounted before running any program. The initramfs mounts a 
> separate /usr before running init, but the installer rescue mode did
> not 
> before running a shell. This feature has been added to bookworm 
> installer (rescue 1.86) but not backported to bullseye installer
> AFAIK.
> 
That explains it. I can't open the root patitiion, because rescue
system says it's not a root partition until I try what is actually
/usr. But, I have finally given up separate /usr, and just lumped it in
with the pile. But in bookworm it should work?



> > My suggestion is, if a user wants a separate usr, to place a hidden
> > flag file in root, the presence of which
> > informs the system to mount THAT partition AND look in /etc/fstab,
> > and mount usr.
> 
> /etc/fstab already exists in the root filesystem, so no need to
> create a 
> flag file.



Bug#1037238: debian-installer: separate /usr ruins opening a shell in rescue

2023-06-09 Thread Pascal Hambourg

On 09/06/2023 at 01:27, tomas k wrote:


I'm on a different system than the problem one. For years I have had to boot 
knoppix
and run a chroot to change a password I've forgotten, because I use a separate 
usr partition,
and rescue thinks it's the root directory. Butr without etc it's not going to 
work.


Rescue mode does not "think" anything about any partition. It is up to 
the user to select the proper root partition, although I admit this 
might be improved by providing more information about available 
partitions to the user.


With /usr-merged layout (default since buster IIRC), a separate /usr 
must be mounted before running any program. The initramfs mounts a 
separate /usr before running init, but the installer rescue mode did not 
before running a shell. This feature has been added to bookworm 
installer (rescue 1.86) but not backported to bullseye installer AFAIK.



My suggestion is, if a user wants a separate usr, to place a hidden flag file 
in root, the presence of which
informs the system to mount THAT partition AND look in /etc/fstab, and mount 
usr.


/etc/fstab already exists in the root filesystem, so no need to create a 
flag file.




Bug#1037238: debian-installer: separate /usr ruins opening a shell in rescue

2023-06-08 Thread Cyril Brulebois
Control: severity -1 normal

tomas k  (2023-06-08):
> Package: debian-installer
> Severity: critical
> Tags: d-i
> Justification: breaks the whole system

Hardly. You're starting from a system that requires GRUB to be installed
for some reason. d-i isn't breaking anything at all.

> I'm on a different system than the problem one. For years I have had
> to boot knoppix and run a chroot to change a password I've forgotten

init=/bin/sh works for that.

> Most recently, I just wanted to install grub from the Debian install
> DVD, nothing else, but once again, with separate usr, no root shell.
> So I tried to go through the install and just skip to install grub,
> but it wouldn't allow it, because previous steps were skipped. ThAT
> FIASCO cost me 4  hours, about  the same amount of time it would take
> to fix the rescue system.

If rescue doesn't mount all the things automatically, you realize you
can drop to a shell in the installer's context and mount any missing
bit?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Bug#1037238: debian-installer: separate /usr ruins opening a shell in rescue

2023-06-08 Thread tomas k
Package: debian-installer
Severity: critical
Tags: d-i
Justification: breaks the whole system
X-Debbugs-Cc: foren...@wi.rr.com

Dear Maintainer,

I'm on a different system than the problem one. For years I have had to boot 
knoppix
and run a chroot to change a password I've forgotten, because I use a separate 
usr partition,
and rescue thinks it's the root directory. Butr without etc it's not going to 
work.

Most recently, I just wanted to install grub from the Debian install DVD, 
nothing else, but once again, 
with separate usr, no root shell. So I tried to go through the install and just 
skip to install grub,
but it wouldn't allow it, because previous steps were skipped. ThAT FIASCO cost 
me 4  hours, about  the same amount 
of time it would take to fix the rescue system.

My suggestion is, if a user wants a separate usr, to place a hidden flag file 
in root, the presence of which 
informs the system to mount THAT partition AND look in /etc/fstab, and mount 
usr. 

I'd really like this back the way it was, but I realize /bin is now symlinks.

Thanks for all the help.



-- System Information:
Debian Release: 11.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-0.bpo.1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled