Bug#614143: os-prober: generated linux entries don't use UUIDs for root= parameter

11-12-13 by Marcin but it seemed to corrupt my grub.cfg (not surprising, given the age and that it was perhaps for CentOS). My hack solution was to change /etc/grub.d/30_os-prober line 248 to be: |linux ${LKERNEL} root=UUID=${boot_device_id}| ...which I assume is a Bad Idea for some reason,

Bug#1091668: marked as done (debian-installer: Explicitly declare requirement for root)

Your message dated Thu, 15 May 2025 04:19:00 + with message-id and subject line Bug#1091668: fixed in debian-installer 20250515 has caused the Debian Bug report #1091668, regarding debian-installer: Explicitly declare requirement for root to be marked as done. This means that you claim that

Bug#1091668: debian-installer: Explicitly declare requirement for root

Kurt Roeckx (2025-04-26): > Can someone clarify the current state of this? Patch + pending as in the fix is in git and will be included in the next upload. Cheers, -- Cyril Brulebois (k...@debian.org) D-I release manager -- Release team member -- Freelance Con

Bug#1091668: debian-installer: Explicitly declare requirement for root

Can someone clarify the current state of this?

Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs

On Tue, 22 Apr 2025 12:20:22 +0200 Cyril Brulebois wrote: > Holger Wansing (2025-04-21): > > The latter would be at least consistent with the behaviour of rescue > > mode for "usual filesystems" (presenting the user a list of > > possibilities, which partit

Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs

Oops, there was also this reply: Pascal Hambourg writes: > On 18/04/2025 at 03:39, Nicholas D Steeves wrote: >> Pascal Hambourg writes: >>> On 11/04/2025 at 03:21, Nicholas D Steeves wrote: >> Would you please share what you think are useful (and/or not useful) >> criteria for these heuristics?

Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs

Dropping kibi from CC, since he's super busy Holger Wansing writes: > Would it be possible, to ask the user for input, if the automatic tries > mentioned > in [1] above all fail? Cyril Brulebois writes: > Pascal Hambourg (2025-04-21): > >> Or a bigger change like what Nicholas intends to i

Processed: Re: Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs

Processing control commands: > tag 1103476 +pending Bug #1103476 [debian-installer] "debian-installer: Rescue mode cannot execute a shell for any default btrfs installations" Added tag(s) pending. -- 1102604: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102604 1103476: https://bugs.debian

Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs

Control: tag 1103476 +pending I'm dropping kibi from CC of this big feature thread since he's ultra busy. Tyler Riddle writes: >> >> Possible yes, desirable unsure. > > Others might disagree > > > First, I absolutely do not want perfection to be the enemy of good here and > I'm interested in s

Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs

M Cyril Brulebois wrote: > Holger Wansing (2025-04-21): > > The latter would be at least consistent with the behaviour of rescue > > mode for "usual filesystems" (presenting the user a list of > > possibilities, which partition to mount as root filesystem). > >

Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs

Holger Wansing (2025-04-21): > The latter would be at least consistent with the behaviour of rescue > mode for "usual filesystems" (presenting the user a list of > possibilities, which partition to mount as root filesystem). > > Would it be possible, to ask the user fo

Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs

of rescue mode for "usual filesystems" (presenting the user a list of possibilities, which partition to mount as root filesystem). Would it be possible, to ask the user for input, if the automatic tries mentioned in [1] above all fail? Holger -- Sent from /e/ OS on Fairphone3

Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs

Control: reassign -1 rescue-mode 1.99 Control: tags -1 patch On 21/04/2025 at 19:54, Cyril Brulebois wrote: Pascal Hambourg (2025-04-21): What kind of change would you accept before trixie release ? A minimal change like mine [1] which automatically tries a few known rootfs subvolumes, with no

Processed: Re: Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs

Processing control commands: > reassign -1 rescue-mode 1.99 Bug #1102604 [debian-installer] debian-installer: Rescue mode can not execute shell when root filesystem is btrfs Bug reassigned from package 'debian-installer' to 'rescue-mode'. Ignoring request to alter found v

Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs

tion earlier about what the contents of /target should be: the root subvolume or the specific subvolume selected either by the user or automatically. Given what I've learned about the expectations of other parts of the recovery system's expectations for the contents of target I'd l

Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs

Pascal Hambourg (2025-04-21): > What kind of change would you accept before trixie release ? > A minimal change like mine [1] which automatically tries a few known rootfs > subvolumes, with no change in the user interface ? > [1] Sure.

Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs

On 11/04/2025 at 06:24, Cyril Brulebois wrote: If we can get fixed before Trixie is released, that's nice. What kind of change would you accept before trixie release ? A minimal change like mine [1] which automatically tries a few known rootfs subvolumes, with no change in the user interface

Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs

On Thu, 10 Apr 2025 14:24:58 -0600 Tyler Riddle wrote: > Package: debian-installer > Version: Trixie Alpha 1 > Severity: normal > Tags: d-i > X-Debbugs-Cc: cardboardaardv...@gmail.com, debian-boot@lists.debian.org > > Dear Maintainer, > > When using rescue mode with

Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs

menu is used to pick a subvolume it only tells the Debian installer > > what the chroot directory should be. > > I see two issues with this: > - If the default subvolume is not the top level subvolume, then other > subvolumes which are not in its path are hidden. > - rescue.d/ scri

Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs

trfs, then try to mount in order - the @rootfs subvolume (Debian/Fedora style) If we're doing minimum defaults, then '@rootfs'. Fedora uses "root" rather than @rootfs. Ah, I misunderstood what you wrote in bug#964818: "Installing Debian directly to subvolid 5 rather

Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs

. - rescue.d/ scripts which may belong to other packages than rescue-mode such as grub-install expect the system root to be in /target. The first issue can be solved by mounting the top level subvolume instead of the default subvolume. However the second issue requires to change the interface between

Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs

of? > > For now, what about just this : > if the selected device filesystem is btrfs, then try to mount in order > - the @rootfs subvolume (Debian/Fedora style) If we're doing minimum defaults, then '@rootfs'. Fedora uses "root" rather than @rootfs. > - the

Processed: Re: Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs

Processing commands for cont...@bugs.debian.org: > clone 1102604 -1 Bug #1102604 [debian-installer] debian-installer: Rescue mode can not execute shell when root filesystem is btrfs Bug 1102604 cloned as bug 1103476 > retitle -1 "debian-installer: Rescue mode cannot execute a sh

Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs

e when using rescue mode. That expectation being that I'd have an easy way to get a root shell on my root filesystem. I was not even aware that the Debian installer would create a subvolume for the root filesystem during install until I found that launching the root shell failed. I'm using

Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs

On 11/04/2025 at 03:21, Nicholas D Steeves wrote: Rather than reimplement our own thing for Debian Rescue, I think that it would be maximally beneficial to talk to the grub-btrfs (https://github.com/Antynea/grub-btrfs) project (and maybe btrfsmaintenance, and/or the new systemd-based one). or ev

Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs

Hi, Nicholas D Steeves (2025-04-10): > Attention Cyril: Does debian-rescue have the same restrictions as the > rest of Debian, or does it have special exceptions like udebs? The > reason I ask is because I'm curious if we could fix debian-rescue btrfs > support in a Trixie point release, or if i

Processed: Re: Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs

Processing control commands: > tag -1 +confirmed Bug #1102604 [debian-installer] debian-installer: Rescue mode can not execute shell when root filesystem is btrfs Added tag(s) confirmed. -- 1102604: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102604 Debian Bug Tracking System Contact

Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs

Riddle writes: > Package: debian-installer > Version: Trixie Alpha 1 > Severity: normal > Tags: d-i > X-Debbugs-Cc: cardboardaardv...@gmail.com, debian-boot@lists.debian.org > > Dear Maintainer, > > When using rescue mode with a root file system that is btrfs the option to &g

Bug#1102604: debian-installer: Rescue mode can not execute shell when root filesystem is btrfs

Package: debian-installer Version: Trixie Alpha 1 Severity: normal Tags: d-i X-Debbugs-Cc: cardboardaardv...@gmail.com, debian-boot@lists.debian.org Dear Maintainer, When using rescue mode with a root file system that is btrfs the option to launch a shell inside the root file system does not

Bug#1091668: debian-installer: Explicitly declare requirement for root

Cyril Brulebois: Control: tag -1 pending Niels Thykier (2025-01-04): The switch has already been flipped (dpkg/1.22.13). I knew I should have skipped that part, as quickly skimming for “root” didn't turn up a hit on R³ obviously… :) (Hindsight, always 20/20.) Note it can in theory

Processed: Re: Bug#1091668: debian-installer: Explicitly declare requirement for root

Processing control commands: > tag -1 pending Bug #1091668 [debian-installer] debian-installer: Explicitly declare requirement for root Added tag(s) pending. -- 1091668: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1091668 Debian Bug Tracking System Contact ow...@bugs.debian.org w

Bug#1091668: debian-installer: Explicitly declare requirement for root

Control: tag -1 pending Niels Thykier (2025-01-04): > The switch has already been flipped (dpkg/1.22.13). I knew I should have skipped that part, as quickly skimming for “root” didn't turn up a hit on R³ obviously… :) (Hindsight, always 20/20.) > Note it can in theory also

Bug#1091668: debian-installer: Explicitly declare requirement for root

Cyril Brulebois: Hej Niels, Niels Thykier (2025-01-04): The transition has moved to the endgame and this bug is now RC. This bug is filed on the assumption that the remark in d/rules about a part of the code needing root is true. The provided patch (MR) explicitly has debian-installer opt-in

Bug#1091668: debian-installer: Explicitly declare requirement for root

Hej Niels, Niels Thykier (2025-01-04): > The transition has moved to the endgame and this bug is now RC. This bug is > filed on the assumption that the remark in d/rules about a part of the code > needing root is true. The provided patch (MR) explicitly has > debian-installer o

Bug#1091668: debian-installer: Explicitly declare requirement for root

. The patch is at https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/57 Best regards, Niels Hi The transition has moved to the endgame and this bug is now RC. This bug is filed on the assumption that the remark in d/rules about a part of the code needing root is true

Bug#1091668: debian-installer: Explicitly declare requirement for root

Package: debian-installer Severity: important Tags: patch X-Debbugs-Cc: ni...@thykier.net User: ni...@thykier.net Usertags: rrr-no-as-default-issue Hi, Filing this one to ensure it is on my bug radar for the MBF and for tracking status. The patch is at https://salsa.debian.org/installer-team/d

Bug#1070483: btrfs root volume being mounted as ro upon boot

ezone setup:   [O] User/password setup:    [O] Install tasks:  [O] Install boot loader:    [O] Overall install:    [O] Comments/Problems: Manually creating an (ecrypted) btrfs partition as the root partition (two volumes automatically created, @ and @home) results in the @ volume being mo

Bug#1043226: marked as done (debian-installer: Please consider moving root user setup to expert install, or change text)

Your message dated Sat, 4 May 2024 15:16:05 +0200 with message-id <20240504151605.fac9949d94d21c59de696...@mailbox.org> and subject line Re: Bug#1043226: debian-installer: Please consider moving root user setup to expert install, or change text has caused the Debian Bug report #1043226, reg

Re: Bug#1043226: debian-installer: Please consider moving root user setup to expert install, or change text

With latest user-setup upload 1.97, this has been dealed with, so closing. -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076

Bug#1063920: console-setup: initramfs keymap is not set and breaks my root crypted boot

Package: console-setup Version: 1.226 Severity: important Dear Maintainer, Since the upgrade to 1.226, I can't open my LUKS root FS beause of broken initramfs. I can still boot under 6.6.11 since its initramfs is not updated with latest tools. I compared both initramfs and found diff

Processed: Re: user-setup: set SYSTEMD_SULOGIN_FORCE=1 in env for rescue/emergency.service when root account is locked

Processing control commands: > forwarded -1 > https://salsa.debian.org/installer-team/user-setup/-/merge_requests/6 Bug #952450 [user-setup] user-setup: set SYSTEMD_SULOGIN_FORCE=1 in env for rescue/emergency.service when root account is locked Set Bug forwarded-to-address to

Bug#952450: user-setup: set SYSTEMD_SULOGIN_FORCE=1 in env for rescue/emergency.service when root account is locked

Package: user-setup Followup-For: Bug #952450 Control: forwarded -1 https://salsa.debian.org/installer-team/user-setup/-/merge_requests/6

Bug#264435: marked as done (should check root filesystem type and warn)

Your message dated Tue, 19 Sep 2023 23:54:42 +0200 with message-id <00d7049e-0a8f-432c-ae07-eaee9d152...@debian.org> and subject line Re: Debian Installer RC1 on MIPS has caused the Debian Bug report #264435, regarding should check root filesystem type and warn to be marked as done. This

Bug#1043226: +1 (Re: Bug#1043226: debian-installer: Please consider moving root user setup to expert install, or change text)

On Tue, Aug 15, 2023 at 10:03:22PM +0100, Samuel Henrique wrote: > > So, many users, and especially newcomers to Debian, follow the instructions > > in the > > first line and are then surprised when they can't use sudo from their user > > from > > their newly installed system. > I've seen this is

Re: Bug#1043226: debian-installer: Please consider moving root user setup to expert install, or change text

On 19/08/2023 18:42, Pascal Hambourg wrote: On 19/08/2023 at 10:28, Diederik de Haas wrote: On Monday, 7 August 2023 18:25:07 CEST Jonathan Carter wrote: Firstly, the instructions start off with "You need to set a password for 'root'", followed by seemingly uninteresti

Bug#1043226: debian-installer: Please consider moving root user setup to expert install, or change text

On 19/08/2023 at 10:28, Diederik de Haas wrote: On Monday, 7 August 2023 18:25:07 CEST Jonathan Carter wrote: Firstly, the instructions start off with "You need to set a password for 'root'", followed by seemingly uninteresting text about what a good password shoul

Bug#1043226: debian-installer: Please consider moving root user setup to expert install, or change text

On Monday, 7 August 2023 18:25:07 CEST Jonathan Carter wrote: > Source: debian-installer > Version: 20230607+deb12u1 > > Firstly, the instructions start off with "You need to set a password for > 'root'", followed by seemingly uninteresting text about what a goo

Bug#1043226: debian-installer: Please consider moving root user setup to expert install, or change text

> So, many users, and especially newcomers to Debian, follow the instructions > in the > first line and are then surprised when they can't use sudo from their user > from > their newly installed system. I've seen this issue happening so many times. This would be a huge UX improvement for the in

Bug#1043226: debian-installer: Please consider moving root user setup to expert install, or change text

t; Dear Maintainer, > > When setting up users and passwords in debian-installer in a default install, > it prompts a user to set up a root password. In d-i, this works very different > than in other installers, which causes quite a bit of confusion for users. > > Firstly, the instructio

Bug#1043226: debian-installer: Please consider moving root user setup to expert install, or change text

Source: debian-installer Version: 20230607+deb12u1 Severity: wishlist Dear Maintainer, When setting up users and passwords in debian-installer in a default install, it prompts a user to set up a root password. In d-i, this works very different than in other installers, which causes quite a bit

Bug#952450: user-setup: set SYSTEMD_SULOGIN_FORCE=1 in env for rescue/emergency.service when root account is locked

sment. My understanding from the relevant manual[1] is that 'emergency.target' is a similar, albeit even more basic systemd state that is automatically selected if early boot preconditions fail and/or when serious errors occur. The system used for testing has a locked root user account, but is

Bug#1032277: installation-reports: Installer too strongly urges users to set root password

On 02/03/2023 at 19:21, Cyril Brulebois wrote: What happens if you don't set a root password and got dropped into maintenance mode at boot-time? Or if you cannot open a user session for whatever reason ? You're stuck. Default settings allow to launch an unauthenticated root she

Bug#1032277: installation-reports: Installer too strongly urges users to set root password

Hi, Jeremy Bícha (2023-03-02): > Please see the attached screenshot. I believe Debian would be improved > if this page was reworded. > > It begins with a strong emphatic statement "You need to set a password > for 'root' > > If someone is not reading very

Bug#969516: Please support installing onto f2fs root filesystem

Is there any update to this? I can't find the source anywhere to test it myself either.

Re: Unable to set root password with clear text using preseed/early_command

On Wed 16 Feb 2022 at 10:32:25 +0100, More Thanks wrote: > On Wed, Feb 16, 2022 at 04:52:48PM +0800, Glen Huang wrote: > > On Feb 16, 2022, at 4:38 PM, Philip Hands wrote: > > > Glen Huang writes: > > > > Thanks to Cyril Brulebois’s tip that I could use DEBCONF_DEBUG > > > > to debug debconf, I

Re: Unable to set root password with clear text using preseed/early_command

On Wed, Feb 16, 2022 at 04:52:48PM +0800, Glen Huang wrote: > On Feb 16, 2022, at 4:38 PM, Philip Hands wrote: > > Glen Huang writes: > > > Thanks to Cyril Brulebois’s tip that I could use DEBCONF_DEBUG > > > to debug debconf, I found out the seen flag should be set in order > > > for db_input to

Re: Unable to set root password with clear text using preseed/early_command

Setting a placeholder value is a great idea, it simplifies the early_command since the seen flag no longer needs to be set. Thanks for the tip Philip. > On Feb 16, 2022, at 4:38 PM, Philip Hands wrote: > > Glen Huang writes: > >> Thanks to Cyril Brulebois’s tip that I could use DEBCONF_DEBUG

Re: Unable to set root password with clear text using preseed/early_command

Glen Huang writes: > Thanks to Cyril Brulebois’s tip that I could use DEBCONF_DEBUG to debug > debconf, I found out the seen flag should be set in order for db_input to > pick up the value. > > Case solved, thanks to everyone helped! I was wondering about that, but didn't see my code setting l

Re: Unable to set root password with clear text using preseed/early_command

; > I’m not sure if escaping is the issue. I tried directly specifying the > password: > > debconf-set passwd/root-password passwd1234 > debconf-set passwd/root-password-again passwd1234 > > Still got prompted. > > I tried to debug it with > > d-i preseed/earl

Re: Unable to set root password with clear text using preseed/early_command

Thanks for the tip. I’m not sure if escaping is the issue. I tried directly specifying the password: debconf-set passwd/root-password passwd1234 debconf-set passwd/root-password-again passwd1234 Still got prompted. I tried to debug it with d-i preseed/early_command string \ set -x

Re: Unable to set root password with clear text using preseed/early_command

On Tue, Feb 15, 2022 at 08:08:08PM +0800, Glen Huang wrote: > Hi, > > I want to set the root password to a random string. this is the preseed I use: > > d-i preseed/early_command string \ > pw="$(tr -dc A-Za-z0-9 debconf-set passwd/root-password "$pw"

Unable to set root password with clear text using preseed/early_command

Hi, I want to set the root password to a random string. this is the preseed I use: d-i preseed/early_command string \ pw="$(tr -dc A-Za-z0-9 ' Directly setting the password also works: d-i passwd/root-password password r00tme d-i passwd/root-password-again password r00tme &

Bug#1002921: marked as done (installation-reports: No Screen Reader, Cannot boot into MATE GUI, Root only can)

Your message dated Sun, 02 Jan 2022 09:51:54 +0100 with message-id <2c19e32c-fcd0-46ef-8591-8e28d423c...@mailbox.org> and subject line Re: Bug#1002921: installation-reports: No Screen Reader, Cannot boot into MATE GUI, Root only can has caused the Debian Bug report #1002921, reg

Re: Bug#1002921: installation-reports: No Screen Reader, Cannot boot into MATE GUI, Root only can

On Sun, Jan 2, 2022, 00:39 john doe wrote: > On 1/2/2022 1:20 AM, D.J.J. Ring, Jr. wrote: > > I made a new partition for /home and I reinstalled Debian, this time I > > could lot in to MATE and I could log into the CLI. > > > > But the issue remains of after the Installation disk detects my sound

Re: Bug#1002921: installation-reports: No Screen Reader, Cannot boot into MATE GUI, Root only can

On 1/2/2022 1:20 AM, D.J.J. Ring, Jr. wrote: I made a new partition for /home and I reinstalled Debian, this time I could lot in to MATE and I could log into the CLI. But the issue remains of after the Installation disk detects my sound card, it seems to find my sound card, but immediately after

Bug#1002921: installation-reports: No Screen Reader, Cannot boot into MATE GUI, Root only can

sound during accessible > installation, This time I made up a brand new never before user name. > > The result was the very same, I could not log in with my user account, > only root. > > What is your next suggestion? > > There is an installer issue, not having speech during

Bug#1002921: installation-reports: No Screen Reader, Cannot boot into MATE GUI, Root only can

r account, only root. What is your next suggestion? There is an installer issue, not having speech during an accessible installation is an installer issue . Making a brand new user account and not being able to log in might be something else. Where do I go to get this part fixed? Thanks, David

Bug#1002921: installation-reports: No Screen Reader, Cannot boot into MATE GUI, Root only can

not log in. I could log in as previously by using root. At that time, I didn't know a way to disable lightdm login and just log in with the console. I suspect I'd get the same result as I do now, that I could not log in with any user account, only the supervisor account, root. At that ti

Bug#1002921: installation-reports: No Screen Reader, Cannot boot into MATE GUI, Root only can

could log in as previously by using root. So reusing by /home/djringjr folder won't let me log in, using a brand-new user account with brand new files from /etc/skel won't let me run the GUI. Since then I've discovered with my current installation not only can't I access the

Bug#1002921: installation-reports: No Screen Reader, Cannot boot into MATE GUI, Root only can

successful installation. I did some investigation into this. This is what I did: . I disabled lightdm using systemctl disable lightdm then more recently I used the root command "systemctl set-default multi-user.target" and now I see I cannot even log in as my regular user. I tried a new

Bug#1002921: installation-reports: No Screen Reader, Cannot boot into MATE GUI, Root only can

Also I just used systemctl set-default multi-user.target to change to a console log in. I cannot log in as user, only as root. GUI can also only be started as root. Have espeakup in console by as soon as log into Mate using root account, no sound, Orca setup has no speech settings. Regards

Bug#1002921: installation-reports: No Screen Reader, Cannot boot into MATE GUI, Root only can

el lspci -knn: Kernel modules: snd_hda_intel lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Wildcat Point-LP PCI Express Root Port #3 [8086:9c94] (rev e3) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1c.3 PCI bridge [0604]: Intel Corporation Wildcat Point-LP PCI Expres

Bug#1000239: Rescue system won't find root partition, but insists on /usr

Thank you for the discussion! I found it educational and motivating, and hope that everyone found the same. It's really refreshing to see this. Sorry for the naivety in my analysis and in the delay replying; I've been drained/busy, but I read each of your emails carefully, wanted to reply to eac

Bug#1000239: Rescue system won't find root partition, but insists on /usr

Le 09/12/2021 à 23:29, TomK a écrit : If there is a /usr partition, /usr/share will be part of it. So, separate /usr/share is exactly as common s/as separate /usr. No, by "separate /usr/share" I (and Philip I guess, please correct me if I am wrong) mean "separate from /usr". /usr/share has

Bug#1000239: Rescue system won't find root partition, but insists on /usr

Le 09/12/2021 à 00:25, Steve McIntyre a écrit : Nod. A separate /usr filesystem is a configuration that was supported well by d-i and Debian for a number of years, hence I agreed that it was worth improving rescue-mode to explicitly support it. I *could* also be convinced that we should do simil

Bug#1000239: Rescue system won't find root partition, but insists on /usr

-- From: Pascal Hambourg Sent: December 8, 2021 11:41:11 AM UTC To: Philip Hands , 1000...@bugs.debian.org, TomK Subject: Re: Bug#1000239: Rescue system won't find root partition, but insists on /usr Le 08/12/2021 à 10:49, Philip Hands a écrit : > > Is it a problem if /home or /us

Bug#1000239: Rescue system won't find root partition, but insists on /usr

On Wed, Dec 08, 2021 at 11:36:47PM +0100, Philip Hands wrote: >Pascal Hambourg writes: > >> Le 08/12/2021 à 10:49, Philip Hands a écrit : >>> >>> Is it a problem if /home or /usr/share are left unmounted during rescue? >> >> /usr/share contains architecture-independent files for many programs >>

Bug#1000239: Rescue system won't find root partition, but insists on /usr

Pascal Hambourg writes: > Le 08/12/2021 à 10:49, Philip Hands a écrit : >> >> Is it a problem if /home or /usr/share are left unmounted during rescue? > > /usr/share contains architecture-independent files for many programs > such as bash, grub, os-prober, debconf, dpkg, initramfs-tools... > >

Bug#1000239: Rescue system won't find root partition, but insists on /usr

Le 08/12/2021 à 10:49, Philip Hands a écrit : Is it a problem if /home or /usr/share are left unmounted during rescue? /usr/share contains architecture-independent files for many programs such as bash, grub, os-prober, debconf, dpkg, initramfs-tools... How common is it to have a separate /u

Bug#1000239: Rescue system won't find root partition, but insists on /usr

TomK writes: > This sounds correct, based on my experience with the bug. > I suppose now there are zero ways to definitively determine which > partition is actually root. So maybe a hidden flag (empty) file in > root might do the trick. I'd expect that looking for e.g. /et

Bug#1000239: Rescue system won't find root partition, but insists on /usr

This sounds correct, based on my experience with the bug. I suppose now there are zero ways to definitively determine which partition is actually root. So maybe a hidden flag (empty) file in root might do the trick. But the fact that /usr can be automounted, but nothing else can be manually

Bug#1000239: Rescue system won't find root partition, but insists on /usr

Steve McIntyre (2021-12-06): > In fact, it needed more work than that - the code chrooted into > /target and ran mount there. That didn't work for a separate /usr. But > I've refactored the code and made things work more cleanly inside d-i. > > I'm pondering backporting the same fix for future bu

Bug#1000239: marked as done (Rescue system won't find root partition, but insists on /usr)

Your message dated Mon, 06 Dec 2021 01:03:24 + with message-id and subject line Bug#1000239: fixed in rescue 1.86 has caused the Debian Bug report #1000239, regarding Rescue system won't find root partition, but insists on /usr to be marked as done. This means that you claim that the pr

Bug#1000239: Rescue system won't find root partition, but insists on /usr

On Sat, Dec 04, 2021 at 10:42:29PM +, Steve McIntyre wrote: >On Sat, Dec 04, 2021 at 11:37:28PM +0100, Pascal Hambourg wrote: >>Le 03/12/2021 à 22:08, Nicholas D Steeves a écrit : >>> >>> >>> c) parse /target/etc/fstab, and attempt to mount other partitions >> >>The rescue system already

Bug#1000239: Rescue system won't find root partition, but insists on /usr

Le 03/12/2021 à 22:08, Nicholas D Steeves a écrit : c) parse /target/etc/fstab, and attempt to mount other partitions The rescue system already offers to do it for separate /boot and /boot/efi, so why couldn't it do for separate /usr too ?

Bug#1000239: Rescue system won't find root partition, but insists on /usr

On Sat, Dec 04, 2021 at 11:37:28PM +0100, Pascal Hambourg wrote: >Le 03/12/2021 à 22:08, Nicholas D Steeves a écrit : >> >> >> c) parse /target/etc/fstab, and attempt to mount other partitions > >The rescue system already offers to do it for separate /boot and /boot/efi, >so why couldn't it d

Bug#1000239: Rescue system won't find root partition, but insists on /usr

cue mode. Having just tested it with a separate /usr, all one needs to do is select the actual root partition as you'd expect, then when prompted to execute a shell, select the second option (Execute a shell in the installer environment), then the trick is to mount the /usr partition b

Bug#1000239: Rescue system won't find root partition, but insists on /usr

problem here, although it exacerbates what > appears to be a pre-existing bug in the rescue mode[0]. The root cause is > that since Debian 9 [1][2], the "/usr-like" parts of the root filesystem > are no longer guaranteed to be self-contained: important shared > libraries[3] > a

Bug#1000239: Rescue system won't find root partition, but insists on /usr

cue mode[0]. The root cause is that since Debian 9 [1][2], the "/usr-like" parts of the root filesystem are no longer guaranteed to be self-contained: important shared libraries[3] and executables have been gradually moving into /usr for a while, and stretch was the point at which this

Bug#1000239: Rescue system won't find root partition, but insists on /usr

Am 03.12.2021 um 22:08 schrieb Nicholas D Steeves: 2. Reassign to src:rescue, and fix the rescue system. Looks like a duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769738

Bug#1000239: Rescue system won't find root partition, but insists on /usr

ian-testing-amd64-netinst.iso > 2. Selected sda2 > 3. Yes, mount /boot/efi > 4. Execute a shell in /dev/sda2 > 5. No usable shell was found on your root file system (/dev/sda2) > 6. Changed virtual terminal > 7. cd /target && ls bin >ls: bin: No such file or director

Processed: Re: Bug#1000239: Rescue system won't find root partition, but insists on /usr

Processing control commands: > severity -1 normal Bug #1000239 [debian-installer] Rescue system won't find root partition, but insists on /usr Severity set to 'normal' from 'serious' -- 1000239: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000239 Debian Bu

Bug#1000239: Rescue system won't find root partition, but insists on /usr

Control: severity -1 normal On Fri, Dec 03, 2021 at 04:08:24PM -0500, Nicholas D Steeves wrote: > Steps I used to try to reproduce: > > 1. Downloaded debian-testing-amd64-netinst.iso2021-12-03 16:21 408M > 2. Installed to EFI-enabled qemu eg: >kvm -bios /usr/share/ovmf/bios.bin -m 2G

Bug#1000239: Rescue system won't find root partition, but insists on /usr

/debian-separate-usr-sda.raw \ -cdrom /scratch/debian-testing-amd64-netinst.iso 2. Selected sda2 3. Yes, mount /boot/efi 4. Execute a shell in /dev/sda2 5. No usable shell was found on your root file system (/dev/sda2) 6. Changed virtual terminal 7. cd /target && ls bin

Processed (with 1 error): Re: Bug#1000239: Rescue system won't find root partition, but insists on /usr

Processing control commands: > severity -1 serious Bug #1000239 [debian-installer] Rescue system won't find root partition, but insists on /usr Severity set to 'serious' from 'normal' > tags = confirmed Unknown command or malformed arguments to command. -- 10002

Bug#1000239: Rescue system won't find root partition, but insists on /usr

erstand what could be going on, for lack of > experience. I've only been a Debian user since Woody was in testing. > > It's easy to reproduce. Do an expert install with defaults, but partition > with gpt. Boot the system with the install media, launch a rescue shell, and &g

Processed: Re: Bug#1000239: Rescue system won't find root partition, but insists on /usr

Processing control commands: > tag -1 + moreinfo Bug #1000239 [debian-installer] Rescue system won't find root partition, but insists on /usr Added tag(s) moreinfo. -- 1000239: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000239 Debian Bug Tracking System Contact ow...@bugs.de

Bug#1000239: Rescue system won't find root partition, but insists on /usr

Hi Tom, On Sat, Nov 20, 2021 at 01:59:42AM +, TomK wrote: >Package: debian-installer >Version: 20210731+deb11u1_amd64 > >Errors, "No suitable shell found on /dev/sda1" > >Cycling through every partition results in what should be /usr being >selected as the root

Bug#1000239: Rescue system won't find root partition, but insists on /usr

Package: debian-installer Version: 20210731+deb11u1_amd64 Errors, "No suitable shell found on /dev/sda1" Cycling through every partition results in what should be /usr being selected as the root partition. This is useless for a rescue syatem, because there some commands missing.

Bug#500079: marked as done (Missing root option for other detected Linux OS on dmraid)

Your message dated Sat, 30 Oct 2021 18:30:54 +0200 with message-id <20211030183054.906cb9aac22395d0f32a6...@mailbox.org> and subject line Mass-closing old grub-installer bugs has caused the Debian Bug report #500079, regarding Missing root option for other detected Linux OS on dmraid to be

  1   2   3   4   5   6   7   8   9   10   >