/usr in rescue mode
to be marked as done.
This bug is a duplicate of #1000239 which was fixed in rescue 1.86.
Your message dated Sat, 2 Mar 2024 15:42:38 +0100
with message-id
and subject line Re: #769738: split usr is unsupported
has caused the Debian Bug report #769738,
regarding debian-installer: Please automatically mount /usr in rescue mode
to be marked as done.
This means that you claim that the
Your message dated Sat, 7 Oct 2023 17:13:41 +0300
with message-id
and subject line kFreeBSD has been removed from Debian ports
has caused the Debian Bug report #788173,
regarding rescue-mode: kfreebsd rescue fails with can't create /dev/md
to be marked as done.
This means that you claim tha
On 05/09/2022 at 10:46, Ansgar wrote:
On Sat, 2022-09-03 at 21:06 -0400, Nicholas D Steeves wrote:
grep 'ID\=debian' < /etc/os-release
It should also test for `/usr/lib/os-release` in case the symlink in
`/etc/` is not present.
Neither will work with separate /usr.
On Sat, 2022-09-03 at 21:06 -0400, Nicholas D Steeves wrote:
> First, the automated case: Currently DI statically sets the rootfs to be
> "subvolume=@rootfs", which is a value unique to Debian. The simple
> thing to do is to detect that a device has been formatted to btrfs
> before mounting, and t
; is only expected to reinstall the bootloader. What do
you think?
Rescue mode is also expected to chroot and run a shell into the selected
filesystem.
ISTM that the rescue media should test for an actual Debian installation
with something like:
awk '{print $1}' < /MOUNTPOINT/etc/is
h d-i
>>> (with disk encryption as well). As grub wasn't properly installed
>>> (not registered with EFI), I tried to use the rescue mode to reinstall
>>> grub.
>>>
>>> However, mounting the root filesystem failed: /target contained only a
>>&
Pascal Hambourg writes:
> On 03/09/2022 at 06:32, Philip Hands wrote:
>> Ansgar writes:
>>
[snip]
>>>
>>> However, mounting the root filesystem failed: /target contained only a
>>> "@rootfs" subdirectory. So running a shell in the target fs failed.
>>> Manually mounting the filesystem with `-o su
to use the rescue mode to reinstall
grub.
However, mounting the root filesystem failed: /target contained only a
"@rootfs" subdirectory. So running a shell in the target fs failed.
Manually mounting the filesystem with `-o subvol=@rootfs` worked.
This was with Debian 11.4.
I just pushed
Ansgar writes:
> Source: rescue
> Version: 1.85
> Severity: important
>
> I've installed a system using btrfs for the root filesystem with d-i
> (with disk encryption as well). As grub wasn't properly installed
> (not registered with EFI), I tried to use the
d with EFI), I tried to use the rescue mode to reinstall
>grub.
>
>However, mounting the root filesystem failed: /target contained only a
>"@rootfs" subdirectory. So running a shell in the target fs failed.
>Manually mounting the filesystem with `-o subvol=@rootfs` worked.
&g
Source: rescue
Version: 1.85
Severity: important
I've installed a system using btrfs for the root filesystem with d-i
(with disk encryption as well). As grub wasn't properly installed
(not registered with EFI), I tried to use the rescue mode to reinstall
grub.
However, mountin
from the installer system is a good thing to have.
At least for systems I wanted to rescue, it was very likely I had to fix
something inside the / and/or /boot and/or /boot/efi partitions, so
mounting all the things©®™ (as prompted for by the installer in rescue
mode once you pick a root filesystem)
Package: debian-installer
Severity: wishlist
Dear Maintainer,
While trying to rescue a system, I wanted to be able to list
and create EFI boot entries, but efibootmgr is not installed
in the debian-installer image.
I think that the capability of manipulating the EFI boot
entries from the install
Your message dated Tue, 25 May 2021 01:03:26 +
with message-id
and subject line Bug#988826: fixed in grub-installer 1.178
has caused the Debian Bug report #988826,
regarding grub-installer: reinstalling GRUB on a BIOS setup yields an error in
rescue mode despite being successful
to be marked
All good!
Woohoo! Thanks for confirming.
I did run a bunch of tests[1] but didn't re-do rescue mode since I was
feeling quite confident the issue disappeared for real… I'm glad you
have positive results as well!
1.
https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/12#note_240
Hi Cyril,
Cyril Brulebois, on 2021-05-24:
> Étienne Mollier (2021-04-28):
> > Device en_US fr_FR
> > /dev/sdb1ok ok
> > /dev/nvme0n1p1 ok ok
> > /dev/md/0ok ok
> > /dev/debian-vg/root ok ok
[...]
> I'm not sure whether you fo
Hi Étienne,
Étienne Mollier (2021-04-28):
> Cyril Brulebois, on 2021-04-28 06:08:30 +0200:
> > Let's see if this helps!
> > https://people.debian.org/~kibi/bug-987377/
>
> According to my observations, I does help with all the known bad
> cases I have hit so far; I notably double checked the "
Your message dated Sat, 22 May 2021 06:53:17 +0200
with message-id
and subject line Re: Bug#745361: cdebconf-gtk-udeb: fails to advertise "rescue
mode" on start-up
has caused the Debian Bug report #745361,
regarding cdebconf-gtk-udeb: fails to advertise "rescue mode" on star
Cyril Brulebois (2021-05-20):
> Namely, rescue.d/80grub-reinstall gets this new code (excerpt):
>
> chroot /target mount /boot/efi || true
> EXTRA_PATHS="$EXTRA_PATHS /target/boot/efi"
> trap "umount $EXTRA_PATHS" HUP INT QUIT KILL PIPE TERM EXIT
>
> The first line does generate an e
Your message dated Thu, 20 May 2021 05:33:25 +
with message-id
and subject line Bug#987377: fixed in cdebconf 0.258
has caused the Debian Bug report #987377,
regarding rescue-mode: when in graphical mode, locks up one prompt before the
shell
to be marked as done.
This means that you claim
Your message dated Thu, 20 May 2021 05:33:25 +
with message-id
and subject line Bug#882804: fixed in cdebconf 0.258
has caused the Debian Bug report #882804,
regarding cdebconf-gtk-udeb: Missing rescue mode label at start-up
to be marked as done.
This means that you claim that the problem
her options like reinstalling the bootloader.
I was surprised to find out that the rescue mode interface reports there
was an error while grepping -i for GRUB in /var/log/syslog only returned
the usual success messages from grub-install, yet we get an error code
set to 1…
A wild guess (unconfir
Cyril Brulebois (2017-11-26):
> The banner in the graphical installer doesn't get the “Rescue mode”
> label at start-up. It seems the information message hasn't been received
> yet when the first call to handle_exposed_banner (cdebconf gtk frontend)
> happens, so one has t
Hi Étienne,
Étienne Mollier (2021-04-28):
> According to my observations, I does help with all the known bad
> cases I have hit so far; I notably double checked the "Generic"
> partition schemes:
>
> Device en_US fr_FR
> /dev/sdb1ok ok
> /dev/nvme0n1p1
Hi Cyril,
Cyril Brulebois, on 2021-04-28 06:08:30 +0200:
> Let's see if this helps!
> https://people.debian.org/~kibi/bug-987377/
According to my observations, I does help with all the known bad
cases I have hit so far; I notably double checked the "Generic"
partition schemes:
Device
Hi Étienne,
Étienne Mollier (2021-04-26):
> Cyril Brulebois, on 2021-04-26 02:18:49 +0200:
> > Are you happy to trust me with a netboot/gtk/mini.iso build that you
> > would deploy on some USB device (like you would with a Netinst ISO,
> > except it'll need network access to download all d-i comp
Hi Cyril,
Since the LVM result I caught seemed to contradict your own
findings, I did a few more tests in that configuration. I'm
afraid I failed to identify any regular pattern, although I did
try hard to see whether things such as word wrapping might be
involved in some way, so I'm just putting
Hi Cyril,
Étienne Mollier, on 2021-04-26 09:09:50 +0200:
> Cyril Brulebois, on 2021-04-26 02:18:49 +0200:
> > If so, I'd be happy if you could just verify at least one “known-bad”
> > case with the official image first:
> >
> > http://deb.debian.org/debian/dists/bullseye/main/installer-amd64/20
Salut Cyril,
Cyril Brulebois, on 2021-04-26 02:18:49 +0200:
> Are you happy to trust me with a netboot/gtk/mini.iso build that you
> would deploy on some USB device (like you would with a Netinst ISO,
> except it'll need network access to download all d-i components that
> aren't in the initramfs)
203T092240Z| 20201202| Bullseye Alpha 3 |
| 20210415T151642Z| 20210415| Bullseye RC 1|
# Tests
## Initial testing
A `kibi/snapshot-isolinux` branch exists, that tweaks the isolinux
menu to preseed a number of parameters **for rescue mode**. This isn't
supposed to be a very
;Raid" for a simple automatic partition scheme where the
> root partition is on a single member Raid 0 array;
> - "LVM" for the automatic partition scheme;
> - "LVM+Crypto" for the configuration involving crypto;
> - "Locale" dep
for the automatic partition scheme;
- "LVM+Crypto" for the configuration involving crypto;
- "Locale" depends on the language selected when starting
rescue-mode: en_US for the default, or fr_FR;
- "Device" is the interconnection to the physical drive:
Sa
Cyril Brulebois (2021-04-24):
>
>
> cdebconf-* were updated. There's a change in there but apparently only
> for the text frontend.
>
> At least for src:cdebconf's udebs, the libc they were built against is
> no longer the same (2.29 vs. 2.31).
>
> This might very well be a red herring, though
Cyril Brulebois, on 2021-04-25 14:17:36 +0200:
> Steve McIntyre (2021-04-22):
> > From checking (as discussed in IRC with Phil), rescue-mode moved from
> > 1.78 to 1.80 between those two builds. The only changes were in
> > translations, so the problem must be elsewhere. :-
Steve McIntyre (2021-04-22):
> From checking (as discussed in IRC with Phil), rescue-mode moved from
> 1.78 to 1.80 between those two builds. The only changes were in
> translations, so the problem must be elsewhere. :-(
Must it really?
With a fresh install (with LVM but oh well), usin
ersion
available in Sid. The real hardware is an HP Zbook 15 G6,
involving an uneven pair of NVMe SSD drives, 1T and 512G
respectively.
Here are my observations so far:
* in any case the rescue mode works when run from within the
environment of the USB thumb;
* Qemu Bios: the blank page appears a
Philip Hands (2021-04-24):
> Steve McIntyre writes:
>
> ...
> > From checking (as discussed in IRC with Phil), rescue-mode moved from
> > 1.78 to 1.80 between those two builds. The only changes were in
> > translations, so the problem must be elsewhere. :-(
>
>
Steve McIntyre writes:
...
> From checking (as discussed in IRC with Phil), rescue-mode moved from
> 1.78 to 1.80 between those two builds. The only changes were in
> translations, so the problem must be elsewhere. :-(
I've now caused the test job to record the installed udebs in
it, but clearly the exit is working in the working test.
>
>In the broken test, it's not even managing to get to the "installer
>environment" shell, so it seems this bug affects both shells.
>
>BTW this is AFAIK specific to the graphical rescue mode -- IIRC text
>
the "installer
environment" shell, so it seems this bug affects both shells.
BTW this is AFAIK specific to the graphical rescue mode -- IIRC text
mode worked fine when I tried it.
All these tests have been done with BIOS mode boot.
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560]
Package: rescue-mode
Version: 1.83
Severity: normal
Dear Maintainer,
When booting recent daily images, or the bullseye-DI-rc1, into "Graphcal rescue
mode", on a system with a simple partition for root, when one selects to enter a
shell it clears the screen in order to display the "
[Bcc: debian-boot]
Dear Debian-User subscribers,
The Release Notes editor is asking whether this is still an issue for
bullseye (i.e. if the patch to Debian Installer mentioned below was
applied in the meantime).
It will be a while until I get to check that. If someone can confirm
either way
d does not work in rescue
mode
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no ide
people who might have this problem a reference.
>
> This is a companion problem to bug #918590 and am told related to
> a problem fixed in Buster RC 1.
>
> grub-installer/grub-mkconfig can fail when in rescue mode in the installed
> system's chroot because of a long LVM related
#918590 and am told related to
a problem fixed in Buster RC 1.
grub-installer/grub-mkconfig can fail when in rescue mode in the installed
system's chroot because of a long LVM related timeout. The workaround
is reportedly something like:
# mkdir /mnt/hostlvm
# mount --bind /run/lvm /mnt/ho
Processing control commands:
> retitle -1 rescue-mode: should support plain dm-crypt encrypted disks
Bug #404261 [rescue-mode] rescue-mode: should support loop-aes and plain
dm-crypt encrypted disks
Changed Bug title to 'rescue-mode: should support plain dm-crypt encrypted
disks'
Control: retitle -1 rescue-mode: should support plain dm-crypt encrypted disks
Retitle bug, since loop-AES is no longer supported by the installer
Holger
--
Holger Wansing
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Your message dated Tue, 02 Apr 2019 06:34:00 +
with message-id
and subject line Bug#925979: fixed in busybox 1:1.30.1-4
has caused the Debian Bug report #925979,
regarding busybox-udeb: breaks user-params, rescue mode, etc.
to be marked as done.
This means that you claim that the problem has
On Sat, 2019-03-30 at 13:33 +0100, Cyril Brulebois wrote:
> Heya,
>
> Chris Boot (2019-03-30):
[...]
> > I've also had a thought, and I can't remember if we've considered it
> > already: do the environment variables get preserved in
> > /proc/1/environ, even if busybox ash can't grok them? Could
Cyril Brulebois wrote...
> Restoring the patch is not sufficient, as the context obviously changed.
> Given there were few changes there, I've tried reverting the upstream
> commit (9c143ce52da11ec3d21a3491c3749841d3dc10f0), restoring
> temp-deb-installer-hack.patch and enabling the relevant confi
Heya,
Chris Boot (2019-03-30):
> On 29/03/2019 17:45, Cyril Brulebois wrote:
> [snip]
> > But in practice, that means that rescue/enable=true is no longer visible
> > from the rescue-check binary package (from src:rescue), meaning a broken
> > rescue mode. I expect a num
Hi KiBi,
On 29/03/2019 17:45, Cyril Brulebois wrote:
[snip]
> But in practice, that means that rescue/enable=true is no longer visible
> from the rescue-check binary package (from src:rescue), meaning a broken
> rescue mode. I expect a number of other features to be broken in the
> s
(from src:rescue), meaning a broken
rescue mode. I expect a number of other features to be broken in the
same way, via the user-params script in debian-installer-utils.
(In hindsight, this could be related to some other strange things I've
seen lately with some installation scenarios which include
Your message dated Fri, 29 Mar 2019 10:16:56 +0100
with message-id <20190329091656.n4qqdvsyzoaey...@mraw.org>
and subject line Re: Bug#925888: AKA shell
has caused the Debian Bug report #925888,
regarding Add Quick rescue mode
to be marked as done.
This means that you claim that the probl
Package: debian-installer
Today let's discuss Rescue Mode.
I think you should offer a second rescue mode choice.
Call it "Quick Rescue Mode".
List it right after Rescue Mode.
Quick Rescue Mode would drop the user into a shell right away.
No questions about languages. Yup, unf
Package: debian-installer
Severity: minor
Here there is a high chance the user will chose the wrong item,
because he does not recall which of his disks are which.
Therefore you need to present more details, which yes, can fit on the
same line. Add sizes and partition types and disk label stuff etc
D Binary-1
> 20190126-00:15" and trying the rescue mode after dracut killed my
> initrd, I got *tiny* fonts. Appears like 4pt or so sized. (The usual
> tiny size if something doesnt recognize UHD)
>
> But the normal install option appears "large". Readable size.
>
Hi
with a UHD screen resolution on a thinkpad, using "Debian GNU/Linux
buster-DI-alpha5 "Buster" - Official Snapshot amd64 DVD Binary-1
20190126-00:15" and trying the rescue mode after dracut killed my
initrd, I got *tiny* fonts. Appears like 4pt or so sized. (The usual
ti
Your message dated Sat, 26 Jan 2019 18:03:13 +0100
with message-id <20190126180313.f6719c01a11163a754f54...@mailbox.org>
and subject line Re: debian-installer: punjabi installation broken
has caused the Debian Bug report #727043,
regarding punjabi installation broken (or at least rescue mo
Package: cdebconf-gtk-udeb
Version: 0.227
Severity: important
Hi,
The banner in the graphical installer doesn't get the “Rescue mode”
label at start-up. It seems the information message hasn't been received
yet when the first call to handle_exposed_banner (cdebconf gtk frontend)
happe
On Mon, Jul 03, 2017 at 10:49:27AM +0200, Xavier Brochard wrote:
>Le 02 juillet 23:41:32, vous avez écrit :
>> Yup, it would be nice to see this extra information in the rescue
>> code. I've reassigned your bug report appropriately.
>
>There is a patch from Chris Lamb since 2015 in bug reports, see
Le 02 juillet 23:41:32, vous avez écrit :
> Yup, it would be nice to see this extra information in the rescue
> code. I've reassigned your bug report appropriately.
There is a patch from Chris Lamb since 2015 in bug reports, see #798465
--
Librement
Xavier / zeroheure
allways does a good job!
>
>But I would like to suggest this improvement:
>---------
>Entering Rescue Mode, d-i ask for root file system, displaying a list of
>partition without further informations.
>The choice is not easy, as you can't
Processing control commands:
> reassign -1 rescue
Bug #866043 [installation-reports] [wish] display partition scheme before
entering Rescue Mode
Bug reassigned from package 'installation-reports' to 'rescue'.
Ignoring request to alter found versions of bug #866043 to the
But I would like to suggest this improvement:
-
Entering Rescue Mode, d-i ask for root file system, displaying a list of
partition without further informations.
The choice is not easy, as you can't exactly remember what you've done a few
minutes
neath.
OK, fair. I know for a fact this works with Debian 8 since I've used
this many time for Debian/Linux teaching sessions, with RAID1 and
encrypted LVM on top of it; purposefully breaking the encrypted LVM
(removing cryptsetup) then repairing from rescue mode.
> > Given my test results above, we'll need those…
>
> Ok. I'll see what I can do.
Thanks already!
KiBi.
signature.asc
Description: Digital signature
used - the testing CD does not use the latest d-i?
> > > Were you prompted with a passphrase for the detected LUKS partition?
> > When I tried to run the installer in the "rescue" mode, it did not
> > prompt me with anything, but when it said something like "partition
&
Processing control commands:
> notfound -1 20170112
Bug #853756 [debian-installer] debian-installer: no cryptsetup available in
rescue mode
No longer marked as found in versions debian-installer/20170112.
> tag -1 moreinfo
Bug #853756 [debian-installer] debian-installer: no cryptsetup ava
would not work for me (#750586).
Well that isn't D-I Stretch RC 1 then. That one lives under:
http://cdimage.debian.org/cdimage/stretch_di_rc1/
> > Were you prompted with a passphrase for the detected LUKS partition?
>
> When I tried to run the installer in the "rescue&quo
ld not work for me (#750586).
> Were you prompted with a passphrase for the detected LUKS partition?
When I tried to run the installer in the "rescue" mode, it did not
prompt me with anything, but when it said something like "partition
disks", it did not have any crypto entries. On
Control: tag -1 - important
Control: found -1 20170112
Hi,
Toni Mueller (2017-01-31):
> I have a system which uses a LUKS partition, but when I started the
> installer (fetched today) to repair something, it would not let me
> decrypt the partition, and thus denied me access to the system.
Whi
tch etch-ignore
lenny lenny-ignore squeeze squeeze-ignore wheezy wheezy-ignore jessie
jessie-ignore stretch stretch-ignore buster buster-ignore bullseye
bullseye-ignore.
Bug #853756 [debian-installer] debian-installer: no cryptsetup available in
rescue mode
Requested to remove no tags; do
Package: debian-installer
Version: stretch RC1
Severity: important
Tags: d-i
Hi,
I have a system which uses a LUKS partition, but when I started the
installer (fetched today) to repair something, it would not let me
decrypt the partition, and thus denied me access to the system.
Cheers,
--Toni
Processing control commands:
> forcemerge 727043 -1
Bug #727043 [debian-installer] punjabi installation broken
Bug #744863 [debian-installer] punjabi installation broken (or at least rescue
mode)
Severity set to 'important' from 'normal'
Marked as found in versions de
Control: forcemerge 727043 -1
Holger Levsen (2014-04-15):
> package: debian-installer
>
>
> [16:47] < h01ger> | there seems to be a problem with punjabi which other
> languages dont show:
>
> https://jenkins.debian.net/view/g-i-installation/job/g-i-installation_debian_sid_dail
Your message dated Mon, 04 Jul 2016 16:29:40 +
with message-id
and subject line Bug#823612: fixed in rescue 1.57
has caused the Debian Bug report #823612,
regarding rescue-mode should mount /boot/efi if it's available
to be marked as done.
This means that you claim that the problem has
On Fri, 2016-07-01 at 23:05 +0100, Steve McIntyre wrote:
> On Fri, Jul 01, 2016 at 11:41:58PM +0200, Ben Hutchings wrote:
> > On Fri, 2016-07-01 at 21:56 +0100, Steve McIntyre wrote:
> > > On Tue, Jun 28, 2016 at 09:13:25PM +0200, Ben Hutchings wrote:
> > > >
> > > > I wonder why we offer to mount
On Fri, Jul 01, 2016 at 11:41:58PM +0200, Ben Hutchings wrote:
>On Fri, 2016-07-01 at 21:56 +0100, Steve McIntyre wrote:
>> On Tue, Jun 28, 2016 at 09:13:25PM +0200, Ben Hutchings wrote:
>> >
>> > I wonder why we offer to mount /boot but not /usr (more and more
>> > programs live there), /var (som
On Fri, 2016-07-01 at 21:56 +0100, Steve McIntyre wrote:
> On Tue, Jun 28, 2016 at 09:13:25PM +0200, Ben Hutchings wrote:
> >
> > I wonder why we offer to mount /boot but not /usr (more and more
> > programs live there), /var (some of them might need state there) or
> > /tmp (don't want to create
On Tue, Jun 28, 2016 at 09:13:25PM +0200, Ben Hutchings wrote:
>
>I wonder why we offer to mount /boot but not /usr (more and more
>programs live there), /var (some of them might need state there) or
>/tmp (don't want to create files there that will never be cleaned up).
Maybe, yes. For now I've m
On Tue, 2016-06-28 at 14:15 +0200, Cyril Brulebois wrote:
> Steve McIntyre (2016-06-28):
> > So, I've been pondering about this a little. At the moment, rescue
> > just tends to mount the root filesystem and nothing else. Then the
> > user is left to work out how to mount the rest of their system
On Tue, Jun 28, 2016 at 02:15:32PM +0200, Cyril Brulebois wrote:
>Steve McIntyre (2016-06-28):
>> So, I've been pondering about this a little. At the moment, rescue
>> just tends to mount the root filesystem and nothing else. Then the
>> user is left to work out how to mount the rest of their syst
Steve McIntyre (2016-06-28):
> So, I've been pondering about this a little. At the moment, rescue
> just tends to mount the root filesystem and nothing else. Then the
> user is left to work out how to mount the rest of their system (if
> needed) on their own. I'm thinking we could/should improve t
On Wed, Jun 22, 2016 at 03:13:13PM +0100, Steve McIntyre wrote:
>On Tue, Jun 21, 2016 at 09:44:08PM +0200, Cyril Brulebois wrote:
>>Hi,
>>
>>Steve McIntyre (2016-05-06):
>>> Package: rescue-mode
>>> Version: 1.51
>>> Severity: important
>>&
On Tue, Jun 21, 2016 at 09:44:08PM +0200, Cyril Brulebois wrote:
>Hi,
>
>Steve McIntyre (2016-05-06):
>> Package: rescue-mode
>> Version: 1.51
>> Severity: important
>>
>> If somebody is trying to debug EFI boot problems, it's quite confusing
Hi,
Steve McIntyre (2016-05-06):
> Package: rescue-mode
> Version: 1.51
> Severity: important
>
> If somebody is trying to debug EFI boot problems, it's quite confusing
> for people that /boot/efi is not mounted automatically.
*oops*
Is anyone working on that?
Quick p
Package: rescue-mode
Version: 1.51
Severity: important
If somebody is trying to debug EFI boot problems, it's quite confusing
for people that /boot/efi is not mounted automatically.
What makes this even worse is that /etc/mtab will be outdated and
/boot/efi will therefore *appear* to be mo
Package: installation-reports
Version: 2.60
Severity: normal
Dear Maintainer,
I PXE-booted the Stretch Alpha 4 installer in rescue mode, to fix a grub
misconfiguration, and the Logitech K400 keyboard which is regularly used with
this machine stopped working at the first configuration screen
package: rescue-mode
version: 1.51
severity: important
x-debbugs-cc: debian-...@lists.debian.org
Adding the line "set kFreeBSD.rescue/enable=true" in a grub entry and
booting the kfreebsd installer fails when executing rescue-mode. The
error is:
mkdir: can't create dir
Package: debian-installer
Severity: wishlist
Rescue mode currently asks the user if she wants to mount a separate
/boot partition. The same should probably happen for /usr.
Preferably, this could be automatically detected (empty dirs and/or
entries in fstab in target?)
Thanks,
Christian
--
To
Processing control commands:
> reassign -1 rsync
Bug #764320 [debian-installer] rsync in rescue mode
Bug reassigned from package 'debian-installer' to 'rsync'.
Ignoring request to alter found versions of bug #764320 to the same values
previously set
Ignoring request to
yself).
Another approach for now would be a live cd rather than the Debian
installer CD in rescue mode.
Cheers,
Ian.
On Tue, 2014-10-07 at 10:31 +0200, Julien Cristau wrote:
> Package: debian-installer
> Severity: wishlist
> Control: submitter -1 r...@atlas.cz
> X-Debbug
Processing control commands:
> submitter -1 r...@atlas.cz
Bug #764320 [debian-installer] rsync in rescue mode
Changed Bug submitter to 'r...@atlas.cz' from 'Julien Cristau
'
--
764320: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764320
Debian Bug Tra
Message-Id: <20141005113651.a111e...@atlas.cz>
Dear Debian developers,
I kindly ask you for help. I am using instalation CD
in rescue mode and I need to rescue my data.
In rescue environment there is no rsync command,
which would resolve my task.
I kindly ask you, please add rsync comm
Cyril Brulebois (2014-04-20):
> When enabling rescue mode, the banner isn't including the usual “Rescue
> mode” label at start-up. Switching to any language enables it, though.
> Going back to English afterwards gives the proper message. So I suspect
> that's really a one-ti
Package: cdebconf-gtk-udeb
Version: 0.189
Severity: normal
When enabling rescue mode, the banner isn't including the usual “Rescue
mode” label at start-up. Switching to any language enables it, though.
Going back to English afterwards gives the proper message. So I suspect
that's re
Holger Levsen (2014-04-15):
> package: debian-installer
>
>
> [16:47] < h01ger> | there seems to be a problem with punjabi which other
> languages dont show:
>
> https://jenkins.debian.net/view/g-i-installation/job/g-i-installation_debian_sid_daily_rescue_punjabi/
> [17:37] < K
package: debian-installer
[16:47] < h01ger> | there seems to be a problem with punjabi which other
languages dont show:
https://jenkins.debian.net/view/g-i-installation/job/g-i-installation_debian_sid_daily_rescue_punjabi/
[17:37] < KiBi> it seems to loop on the keyboard options
Your message dated Mon, 3 Mar 2014 23:04:09 +0100
with message-id <20140303220409.ga30...@mraw.org>
and subject line Re: Bug#635854: [rescue] Wheezy Rescue mode won't chroot to
ext4
has caused the Debian Bug report #635854,
regarding [rescue] Wheezy Rescue mode won't chroot to e
1 - 100 of 207 matches
Mail list logo
