Groups > linux.debian.user > #237428 > unrolled thread

How do I mount the USB stick containing the installer in Rescue Mode?

Started by	Stella Ashburne <rewefie@gmx.com>
First post	2021-07-15 11:50 +0200
Last post	2021-07-16 18:00 +0200
Articles	20 on this page of 43 — 12 participants

Back to article view | Back to linux.debian.user

Page 1 of 3 [1] 2 3 Next page →

#237428 — How do I mount the USB stick containing the installer in Rescue Mode?

From	Stella Ashburne <rewefie@gmx.com>
Date	2021-07-15 11:50 +0200
Subject	How do I mount the USB stick containing the installer in Rescue Mode?
Message-ID	<CB6ad-3wa-1@gated-at.bofh.it>

Debian Bullseye's installer is on a USB stick and I used it to boot into Rescue Mode. If it's of any relevance, the partition table type is GPT, with UEFI+Secure Boot enabled.

After booting into Rescue Mode and filling out the required details onscreen, I chose /dev/perfect-vg/root as the device to use as root file system. If you may recall, the volume group perfect-vg is LUKS-encrypted.

When asked if I wanted to mount the separate /boot/efi partition, I entered No.

Next, I entered Executive a shell in /dev/perfect-vg/root

I typed the command nano /etc/apt/sources.list and commented out all the lines therein.

I added the the following line:

deb [trusted=yes] file:/media/myusb bullseye main

I saved the sources.list file.

I created a directory called /media/myusb and issued the following command to mount the USB stick to it:

mount /dev/sdb1 /media/myusb

The error message is:

mount: /media/myusb: /dev/sdb1 already mounted or mount point busy

Below are the results of cat /etc/fstab

<file system>                  <mount point>  <type>   <options>    <dump>   <pass>
/dev/mapper/perfect--vg-root   /              ext4     errors-remount-ro   0   1
/boot/efi was on /dev/sda1 during installation
UUID=A30E-2C33    /boot/efi     vfat    umask=0077      0      1
/dev/mapper/perfect--vg-swap    none       swap    sw   0      0
/dev/sr0      /media/cdrom0     udf, iso9660 user, noauto   0  0
/media/myusb

I appreciate your help in this matter.

[toc] | [next] | [standalone]

#237429

From	Reco <recoverym4n@enotuniq.net>
Date	2021-07-15 12:00 +0200
Message-ID	<CB6jT-3Ad-3@gated-at.bofh.it>
In reply to	#237428

	Hi.

On Thu, Jul 15, 2021 at 11:43:26AM +0200, Stella Ashburne wrote:
> Next, I entered Executive a shell in /dev/perfect-vg/root

It's Superuser shell actually, not Supervisor/Executive one.

> I created a directory called /media/myusb and issued the following command to mount the USB stick to it:
> mount /dev/sdb1 /media/myusb
> 
> The error message is:
> mount: /media/myusb: /dev/sdb1 already mounted or mount point busy

Something has mounted your device elsewhere already.
A usual thing with the modern desktop environments.
Check the output of "mount" and "df -Th" and /dev/sdb1 will probably be
there. I'd like to see the output of these commands too, btw.

> Below are the results of cat /etc/fstab

If these are the full contents of /etc/fstab, it's incorrect.
In addition to the mountpoint you should specify a block device (or its
equivalent), filesystem type, mount points, dump/pass and that's the
least.

I.e. this line is wrong:

/media/myusb

This line is correct:

/dev/sdb1 /media/usb auto defaults,nofail 0 0

"nofail" is really needed for removable devices, because whoever
designed systemd made an "interesting" decision to halt the boot process
(i.e. host is inaccessible by network, console access only) even if a
single filesystem mentioned in fstab fails to mount.
You may want to add "noauto" as well, see fstab(5).

Reco

[toc] | [prev] | [next] | [standalone]

#237431

From	Greg Wooledge <greg@wooledge.org>
Date	2021-07-15 13:10 +0200
Message-ID	<CB7pD-4uh-1@gated-at.bofh.it>
In reply to	#237429

On Thu, Jul 15, 2021 at 12:55:11PM +0300, Reco wrote:
> "nofail" is really needed for removable devices, because whoever
> designed systemd made an "interesting" decision to halt the boot process
> (i.e. host is inaccessible by network, console access only) even if a
> single filesystem mentioned in fstab fails to mount.

This was the traditional behavior before systemd, so one can't really
fault systemd for continuing the practice.

It's assumed that all file systems mentioned in /etc/fstab are essential
to the correct operation of the system (unless otherwise specified).  If
one of them doesn't mount, it means a disk is broken to the point where
human intervention is required, so the operating system decides to play
it safe and not continue.

[toc] | [prev] | [next] | [standalone]

#237433

From	The Wanderer <wanderer@fastmail.fm>
Date	2021-07-15 13:20 +0200
Message-ID	<CB7zj-4y5-1@gated-at.bofh.it>
In reply to	#237431

[Multipart message — attachments visible in raw view] — view raw

On 2021-07-15 at 07:00, Greg Wooledge wrote:

> On Thu, Jul 15, 2021 at 12:55:11PM +0300, Reco wrote:
> 
>> "nofail" is really needed for removable devices, because whoever 
>> designed systemd made an "interesting" decision to halt the boot
>> process (i.e. host is inaccessible by network, console access only)
>> even if a single filesystem mentioned in fstab fails to mount.
> 
> This was the traditional behavior before systemd, so one can't
> really fault systemd for continuing the practice.
> 
> It's assumed that all file systems mentioned in /etc/fstab are
> essential to the correct operation of the system (unless otherwise
> specified).  If one of them doesn't mount, it means a disk is broken
> to the point where human intervention is required, so the operating
> system decides to play it safe and not continue.

Given the number of complaints I remember reading about cases where a
computer which had been working fine before failed to boot under
systemd, because there was a fstab entry which didn't have "nofail" set
where systemd needed it to be, I find the assertion that this was the
traditional behavior before systemd to be implausible.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#237434

From	Reco <recoverym4n@enotuniq.net>
Date	2021-07-15 13:20 +0200
Message-ID	<CB7zk-4y5-3@gated-at.bofh.it>
In reply to	#237431

On Thu, Jul 15, 2021 at 07:00:40AM -0400, Greg Wooledge wrote:
> On Thu, Jul 15, 2021 at 12:55:11PM +0300, Reco wrote:
> > "nofail" is really needed for removable devices, because whoever
> > designed systemd made an "interesting" decision to halt the boot process
> > (i.e. host is inaccessible by network, console access only) even if a
> > single filesystem mentioned in fstab fails to mount.
> 
> This was the traditional behavior before systemd, so one can't really
> fault systemd for continuing the practice.

Not in Debian (sysvinit, upstart). RHEL, SuSE behaved exactly this way
indeed.

Reco

[toc] | [prev] | [next] | [standalone]

#237440

From	Joe <joe@jretrading.com>
Date	2021-07-15 15:50 +0200
Message-ID	<CB9Uu-662-1@gated-at.bofh.it>
In reply to	#237431

On Thu, 15 Jul 2021 07:00:40 -0400
Greg Wooledge <greg@wooledge.org> wrote:

> On Thu, Jul 15, 2021 at 12:55:11PM +0300, Reco wrote:

> >  halt the boot
> > process (i.e. host is inaccessible by network, console access only)
> > even if a single filesystem mentioned in fstab fails to mount.  
> 
> This was the traditional behavior before systemd, so one can't really
> fault systemd for continuing the practice.
> 
> It's assumed that all file systems mentioned in /etc/fstab are
> essential to the correct operation of the system (unless otherwise
> specified).  If one of them doesn't mount, it means a disk is broken
> to the point where human intervention is required, so the operating
> system decides to play it safe and not continue.
> 

So when I switched my unstable installation from sysvinit to systemd and
it subsequently failed to boot because of a missing drive, that was just
coincidence, was it? My system had never been booting and for some
reason I'd never noticed?

OK, naming removable drives in /etc/fstab may not have been best
practice, but it never held up booting before systemd arrived. But to
be fair, consistent mounting of USB media was a shambles before
systemd, and naming USB drives in fstab was the only way to ensure that
it happened reliably. Remember usbmount and other bodges?

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#237441 — Re: How do I mount the USB stick containing the installer in Rescue Mode?

From	Stefan Monnier <monnier@iro.umontreal.ca>
Date	2021-07-15 17:40 +0200
Subject	Re: How do I mount the USB stick containing the installer in Rescue Mode?
Message-ID	<CBbCW-7jf-3@gated-at.bofh.it>
In reply to	#237431

Greg Wooledge [2021-07-15 07:00:40] wrote:
> On Thu, Jul 15, 2021 at 12:55:11PM +0300, Reco wrote:
>> "nofail" is really needed for removable devices, because whoever
>> designed systemd made an "interesting" decision to halt the boot process
>> (i.e. host is inaccessible by network, console access only) even if a
>> single filesystem mentioned in fstab fails to mount.
> This was the traditional behavior before systemd, so one can't really
> fault systemd for continuing the practice.

That's not my recollection.  AFAIK before systemd, you'd just get an
error message and the boot would just (try to) continue.

I don't think systemd's decision is bad.  But I think it's implementation is
not good enough: it should offer some kind of simple "continue
y/n?" prompt.
[ "Simple" for the user: the implementation might be not so simple.  ]

To be honest, I've added the `nofail` pretty much everywhere and hence
haven't faced this problem recently, so for all I know, the
implementation has already been improved.  But the behavior I saw back
when moving to systemd was definitely not pleasant.

        Stefan

[toc] | [prev] | [next] | [standalone]

#237444

From	Reco <recoverym4n@enotuniq.net>
Date	2021-07-15 18:20 +0200
Message-ID	<CBcfE-7L8-5@gated-at.bofh.it>
In reply to	#237441

	Hi.

On Thu, Jul 15, 2021 at 11:30:10AM -0400, Stefan Monnier wrote:
> Greg Wooledge [2021-07-15 07:00:40] wrote:
> > On Thu, Jul 15, 2021 at 12:55:11PM +0300, Reco wrote:
> >> "nofail" is really needed for removable devices, because whoever
> >> designed systemd made an "interesting" decision to halt the boot process
> >> (i.e. host is inaccessible by network, console access only) even if a
> >> single filesystem mentioned in fstab fails to mount.
> > This was the traditional behavior before systemd, so one can't really
> > fault systemd for continuing the practice.
> 
> That's not my recollection.  AFAIK before systemd, you'd just get an
> error message and the boot would just (try to) continue.

My words exactly.

> I don't think systemd's decision is bad.

You have a remote server.
You modify fstab on that server.
You reboot a server after that, and maybe a lot of time had passed since
fstab modification.

Now you have a system that's inaccessible via SSH/VNC/whatever network
protocol you're using for remote access. Good luck unbricking this
system, especially if it does require a road trip. Or paying for renting
KVM. Or soldering UART, because manufacturer haven't exposed it to the
end user.

I cannot call that an improvement, because I do remember how it used to
work in Debian before systemd. To systemd's defence - RedHat version of
sysvinit did exactly the same in this regard.

Could be worse, I guess. One can render modern AIX unbootable by simply
adding inaccessible NFS mount to /etc/filesystems (they call /etc/fstab
this way). At least systemd is "smart" enough to avoid such pitfall.

> But I think it's implementation is not good enough: it should offer
> some kind of simple "continue y/n?" prompt.
> [ "Simple" for the user: the implementation might be not so simple.  ]

That'd change nothing important, really.
You'd have to be at the console to answer such question, you cannot just
boot somehow and fix things after via SSH.

> To be honest, I've added the `nofail` pretty much everywhere and hence
> haven't faced this problem recently, so for all I know, the
> implementation has already been improved.

Nope, it did not. I've faced similar problem just two days ago.
>From the upstream POV the current behaviour is correct, so there's
nothing to improve.

Reco

[toc] | [prev] | [next] | [standalone]

#237480 — Re: [Misstänkt skräppost] Re: How do I mount the USB stick containing the installer in Rescue Mode?

From	"xtra-kaj@telia.com" <xtra-kaj@telia.com>
Date	2021-07-17 09:30 +0200
Subject	Re: [Misstänkt skräppost] Re: How do I mount the USB stick containing the installer in Rescue Mode?
Message-ID	<CBMVP-5JJ-1@gated-at.bofh.it>
In reply to	#237444

[Multipart message — attachments visible in raw view] — view raw

[toc] | [prev] | [next] | [standalone]

#237437

From	Stella Ashburne <rewefie@gmx.com>
Date	2021-07-15 14:00 +0200
Message-ID	<CB8c1-4MY-1@gated-at.bofh.it>
In reply to	#237429

Hi

> Sent: Thursday, July 15, 2021 at 9:55 AM
> From: "Reco" <recoverym4n@enotuniq.net>
> To: debian-user@lists.debian.org
> Subject: Re: How do I mount the USB stick containing the installer in Rescue Mode?
>
> 	Hi.
>
> On Thu, Jul 15, 2021 at 11:43:26AM +0200, Stella Ashburne wrote:
> > Next, I entered Executive a shell in /dev/perfect-vg/root
>
> It's Superuser shell actually, not Supervisor/Executive one.
>
Thanks for pointing out my typo.
>
> Something has mounted your device elsewhere already.

I guess that when I used the USB-installer to boot my machine into Rescue Mode, the USB stick is mounted, yes?

> A usual thing with the modern desktop environments.
> Check the output of "mount" and "df -Th" and /dev/sdb1 will probably be
> there. I'd like to see the output of these commands too, btw.
>
Output of mount is

root@perfect:/# mount
/dev/mapper/perfect--vg-root on / type ext4 (rw,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=8137669k,nr_inodes=2034417,mode=755)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
tmpfs on /run type tmpfs (rw,nosuid,relatime,size=1629756k,mode=755)
root@perfect:/#

Output of dh -Th is

root@perfect:/# df -Th
Filesystem                Type        Size    Used    Avail    Use%   Mounted on
/dev/perfect-vg/root      ext4        36G     773M    33G      3%     /
devtmpfs                  devtmpfs   7.8G        0   7.8G      0%     /dev
tmpfs                     tmpfs      1.6G      96K   1.6G      1%     /run
root@perfect:/#

> If these are the full contents of /etc/fstab, it's incorrect.
> In addition to the mountpoint you should specify a block device (or its
> equivalent), filesystem type, mount points, dump/pass and that's the
> least.

Thanks for the mini instruction. I really appreciate it.

> I.e. this line is wrong:
>
> /media/myusb
>
> This line is correct:
>
> /dev/sdb1 /media/usb auto defaults,nofail 0 0
>
> "nofail" is really needed for removable devices, because whoever
> designed systemd made an "interesting" decision to halt the boot process
> (i.e. host is inaccessible by network, console access only) even if a
> single filesystem mentioned in fstab fails to mount.
> You may want to add "noauto" as well, see fstab(5).
>
I read fstab(5). Unfortunately such man pages don't contain examples to illustrate the arguments and options.
>
>

[toc] | [prev] | [next] | [standalone]

#237438

From	Reco <recoverym4n@enotuniq.net>
Date	2021-07-15 14:00 +0200
Message-ID	<CB8c2-4MY-5@gated-at.bofh.it>
In reply to	#237437

	Hi.

On Thu, Jul 15, 2021 at 01:52:12PM +0200, Stella Ashburne wrote:
> > A usual thing with the modern desktop environments.
> > Check the output of "mount" and "df -Th" and /dev/sdb1 will probably be
> > there. I'd like to see the output of these commands too, btw.
> >
> Output of mount is
> 
> root@perfect:/# mount
> /dev/mapper/perfect--vg-root on / type ext4 (rw,relatime)
> devtmpfs on /dev type devtmpfs (rw,relatime,size=8137669k,nr_inodes=2034417,mode=755)
> proc on /proc type proc (rw,relatime)
> sysfs on /sys type sysfs (rw,relatime)
> tmpfs on /run type tmpfs (rw,nosuid,relatime,size=1629756k,mode=755)
> root@perfect:/#

And yet it fails to mount /dev/sdb1. Interesting.

Ok, how about this (I'm assuming that the USB stick in question is
plugged in):

lsblk

fdisk -l /dev/sdb

file -sL /dev/sdb1

ls -al /media/usbdisk

mountpoint /media/usbdisk

Reco

[toc] | [prev] | [next] | [standalone]

#237442

From	David Wright <deblis@lionunicorn.co.uk>
Date	2021-07-15 17:50 +0200
Message-ID	<CBbMB-7mu-1@gated-at.bofh.it>
In reply to	#237438

On Thu 15 Jul 2021 at 14:59:36 (+0300), Reco wrote:
> On Thu, Jul 15, 2021 at 01:52:12PM +0200, Stella Ashburne wrote:
> > > A usual thing with the modern desktop environments.
> > > Check the output of "mount" and "df -Th" and /dev/sdb1 will probably be
> > > there. I'd like to see the output of these commands too, btw.
> > >
> > Output of mount is
> > 
> > root@perfect:/# mount
> > /dev/mapper/perfect--vg-root on / type ext4 (rw,relatime)
> > devtmpfs on /dev type devtmpfs (rw,relatime,size=8137669k,nr_inodes=2034417,mode=755)
> > proc on /proc type proc (rw,relatime)
> > sysfs on /sys type sysfs (rw,relatime)
> > tmpfs on /run type tmpfs (rw,nosuid,relatime,size=1629756k,mode=755)
> > root@perfect:/#
> 
> And yet it fails to mount /dev/sdb1. Interesting.
> 
> Ok, how about this (I'm assuming that the USB stick in question is
> plugged in):

It was probably plugged in for booting, and so it's likely /dev/sda,
demoting the system drive to /dev/sdb.

> lsblk
> 
> fdisk -l /dev/sdb
> 
> file -sL /dev/sdb1
> 
> ls -al /media/usbdisk
> 
> mountpoint /media/usbdisk

I think I saw in a previous post of yours in June that you have not
only an encrypted system but also physical volumes and that lvm stuff.
Perhaps you might post the contents of the first menuentry stanza in
your grub.cfg, and confirm that your volumes are contained in an
outer encrypted partition (if I expressed that correctly). This
might help the OP boot the system manually and recover the blue
Grub menu.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#237448

From	Stella Ashburne <rewefie@gmx.com>
Date	2021-07-15 20:40 +0200
Message-ID	<CBer8-Bs-3@gated-at.bofh.it>
In reply to	#237442

> Sent: Thursday, July 15, 2021 at 3:49 PM
> From: "David Wright" <deblis@lionunicorn.co.uk>
> To: debian-user@lists.debian.org
> Subject: Re: How do I mount the USB stick containing the installer in Rescue Mode?
>
> This
> might help the OP boot the system manually and recover the blue
> Grub menu.
>
That's very nice of you, David.

[toc] | [prev] | [next] | [standalone]

#237455

From	David Wright <deblis@lionunicorn.co.uk>
Date	2021-07-15 21:10 +0200
Message-ID	<CBeUa-12b-5@gated-at.bofh.it>
In reply to	#237448

On Thu 15 Jul 2021 at 20:29:53 (+0200), Stella Ashburne wrote:
> > Sent: Thursday, July 15, 2021 at 3:49 PM
> > From: "David Wright" <deblis@lionunicorn.co.uk>
> > To: debian-user@lists.debian.org
> > Subject: Re: How do I mount the USB stick containing the installer in Rescue Mode?
> >
> > This
> > might help the OP boot the system manually and recover the blue
> > Grub menu.
> >
> That's very nice of you, David.

Best I can do. (And I see that your kernel's naming of sda/sdb
is more stable than on at least a couple of my machines.)

It might be worth posting a request for the stanza I asked for,
but as a new topic with a specific Subject line. I can't see
why you shouldn't be able to boot your system with manual Grub
commands. I was surprised how easy it was with an encrypted root
filesystem, needing no more than just the usual three lines:
set root=, linux and initrd. The only unusual thing was that
the foo in linux root=foo … is not visible with Grub>
commands (because it's still locked inside the encryption).

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#237458

From	Stella Ashburne <rewefie@gmx.com>
Date	2021-07-15 22:20 +0200
Message-ID	<CBfZT-1F8-1@gated-at.bofh.it>
In reply to	#237455

Hello David

> Sent: Thursday, July 15, 2021 at 7:08 PM
> From: "David Wright" <deblis@lionunicorn.co.uk>
> To: debian-user@lists.debian.org
> Subject: Re: How do I mount the USB stick containing the installer in Rescue Mode?
>
>
> Best I can do. (And I see that your kernel's naming of sda/sdb
> is more stable than on at least a couple of my machines.)
>
What did you mean by "more stable"?

> It might be worth posting a request for the stanza I asked for,
> but as a new topic with a specific Subject line.

What "stanza" were you referring to? Was it Reco who posted it? And you wrote that it was posted some time in June?

> I can't see
> why you shouldn't be able to boot your system with manual Grub
> commands.

I thought so too. GRUB developers would and should have built a "Rescue Mode" by just entering the commands.

[toc] | [prev] | [next] | [standalone]

#237461

From	Greg Wooledge <greg@wooledge.org>
Date	2021-07-15 22:30 +0200
Message-ID	<CBg9z-1HW-1@gated-at.bofh.it>
In reply to	#237458

On Thu, Jul 15, 2021 at 10:15:59PM +0200, Stella Ashburne wrote:
> > From: "David Wright" <deblis@lionunicorn.co.uk>

> > Best I can do. (And I see that your kernel's naming of sda/sdb
> > is more stable than on at least a couple of my machines.)
> >
> What did you mean by "more stable"?

The reason we strongly discourage the use of /dev/sda1 (and similar
device names) in the /etc/fstab file is because those device names
are not stable.  This means they are not guaranteed to remain the same
each time you boot.  The disk that is called "sda" right now might be
called "sdb" next time you boot.

This can happen due to kernel changes, hardware changes, or simply race
conditions even if *nothing* has changed.

Because of this unreliable naming, various alternatives are suggested.
On most Debian installs, the fstab file is populated using the UUID of
each file system that's known at installation time.  That looks something
like this:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda7 during installation
UUID=c4691ccb-2090-491e-8e82-d7cc822db04a /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sda1 during installation
UUID=4C30-7972  /boot/efi       vfat    umask=0077      0       1
# /home was on /dev/sda8 during installation
UUID=19fb397b-a113-4536-a03d-d60e176cbfdf /home           ext4    defaults        0       2
# /stuff was on /dev/sda9 during installation
UUID=95058c4a-44e2-4a90-87b5-2a5fe40d3cdb /stuff          ext4    defaults        0       2
# swap was on /dev/sda6 during installation
UUID=08c87bdb-17f4-40ab-9b2f-5cb2f29149fb none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0

Another method is to put "labels" on each file system, and then use those
labels in the fstab file.  That works great for some people, especially
people who are very organized, and like to take charge of the details
themselves.

Another method is to identify some unique device that will always refer to
the device in question, and use that in the fstab file.  For example, you
might decide that on your particular system,

/dev/disk/by-path/pci-0000:00:17.0-ata-1-part9

is a reliable name, and will always refer to the partition that you want to
mount, and you may choose to use that in your fstab file.  (This is a
device that I pulled at random from my desktop PC, and it's referring to
a partition by referencing the PCI ID of the disk controller.  This is
actually *not* a stable name.  It's a very bad name.  PCI IDs change all
the time, and should not be relied upon.  *cough* network interface naming.)

Anyway, that's what "stable" means in this context.

[toc] | [prev] | [next] | [standalone]

#237464

From	David Wright <deblis@lionunicorn.co.uk>
Date	2021-07-16 06:50 +0200
Message-ID	<CBnXs-6Cc-5@gated-at.bofh.it>
In reply to	#237458

On Thu 15 Jul 2021 at 22:15:59 (+0200), Stella Ashburne wrote:
> > Sent: Thursday, July 15, 2021 at 7:08 PM
> > From: "David Wright" <deblis@lionunicorn.co.uk>
> >
> > Best I can do. (And I see that your kernel's naming of sda/sdb
> > is more stable than on at least a couple of my machines.)
> >
> What did you mean by "more stable"?

(Greg covered this.)

> > It might be worth posting a request for the stanza I asked for,
> > but as a new topic with a specific Subject line.
> 
> What "stanza" were you referring to? Was it Reco who posted it? And you wrote that it was posted some time in June?

The /full/ stanza is next, but Grub probably makes this look more
complicated by adding more flexibility than any one user could
ever need. (It's GRand Unified …, after all.)

menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-80318fa0-5915-4cc3-bc7c-99af2cfbfda9' {
	load_video
	insmod gzio
	if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
	insmod part_gpt
	insmod ext2
	set root='hd0,gpt2'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  700b607c-ffa6-4435-a4b6-10894928c764
	else
	  search --no-floppy --fs-uuid --set=root 700b607c-ffa6-4435-a4b6-10894928c764
	fi
	echo	'Loading Linux 5.10.0-7-amd64 ...'
	linux	/vmlinuz-5.10.0-7-amd64 root=UUID=80318fa0-5915-4cc3-bc7c-99af2cfbfda9 ro  quiet
	echo	'Loading initial ramdisk ...'
	initrd	/initrd.img-5.10.0-7-amd64
}

That boots the encrypted root installation that I made the other day,
but I can boot the system manually just by typing C at the grub menu,
and then:

Grub> set root='hd0,gpt2'
Grub> linux /vmlinuz-5.10.0-7-amd64 ro quiet root=UUID=80318fa0-5915-4cc3-bc7c-99af2cfbfda9
Grub> initrd /initrd.img-5.10.0-7-amd64

or the second line can be shortened to:

Grub> linux /vmlinuz-5.10.0-7-amd64 ro quiet root=LABEL=viva05

or even:

Grub> linux /vmlinuz-5.10.0-7-amd64 ro quiet root=/dev/dm-0

because, once the disk's 5th partition has been unlocked,¹ any of
these properties describes the filesystem inside².

> > I can't see
> > why you shouldn't be able to boot your system with manual Grub
> > commands.
> 
> I thought so too. GRUB developers would and should have built a "Rescue Mode" by just entering the commands.

They have, and you're using it. No, what I meant was that you should
be able to boot it, just giving the correct raw commands. The problem
is knowing what those correct commands are.

¹ Skip this; it's just for the record. Before I made this encrypted
  installation, I posted that you might need to load Grub modules
  like crypto, cryptodisk and luks. However, I now think that these
  modules may exist for unlocking /boot (which would have to be done
  by Grub) rather than / (which can be left for initrd to do).

² root=UUID=80318fa0-5915-4cc3-bc7c-99af2cfbfda9 was copied from grub.cfg,
  root=LABEL=viva05 was a LABEL set in the screen dialogue already posted,
  root=/dev/dm-0 was the device mapper I observed when I first booted the
  system (using Grub's menu).

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#237445

From	Stella Ashburne <rewefie@gmx.com>
Date	2021-07-15 20:10 +0200
Message-ID	<CBdY5-rl-5@gated-at.bofh.it>
In reply to	#237438

> Sent: Thursday, July 15, 2021 at 11:59 AM
> From: "Reco" <recoverym4n@enotuniq.net>
> To: debian-user@lists.debian.org
> Subject: Re: How do I mount the USB stick containing the installer in Rescue Mode?
>
> > Output of mount is
> >
> > root@perfect:/# mount
> > /dev/mapper/perfect--vg-root on / type ext4 (rw,relatime)
> > devtmpfs on /dev type devtmpfs (rw,relatime,size=8137669k,nr_inodes=2034417,mode=755)
> > proc on /proc type proc (rw,relatime)
> > sysfs on /sys type sysfs (rw,relatime)
> > tmpfs on /run type tmpfs (rw,nosuid,relatime,size=1629756k,mode=755)
> > root@perfect:/#
>
> And yet it fails to mount /dev/sdb1. Interesting.
>
I suppose the reason is that the USB stick is already mounted for booting into Rescue Mode.

> Ok, how about this (I'm assuming that the USB stick in question is
> plugged in):
>
Yes, it's always plugged in because I need it in Rescue Mode.

> lsblk
>
root@perfect:/# lsblk

NAME                     MAJ:MIN      RM   RO    TYPE    MOUNTPOINT
sda                      8:0          0    0     disk
  sda1                   8.1          0    0     part
  sda2                   8:2          0    0     part
  sda3                   8:3          0    0     part
    sda3_crypt           253:0        0    0     crypt
      perfect--vg-swap   253:1        0    0     lvm
      perfect--vg-root   253:2        0    0     lvm     /
sdb                      8:16         1    0     disk
  sdb1                   8:17         1    0     part
  sdb2                   8:18         1    0     part
sr0                      11:0         1    0     rom
root@perfect:/#

> fdisk -l /dev/sdb
>
root@perfect:/# fdisk -l /dev/sdb
Disk /dev/sdb

Device           Boot    Start     End      Sectors        Size      Id    Type
/dev/sdb1        *       0         7677919  7677920        3.7G      0     Empty
/dev/sdb2                24260     29443    5184           2.5M      ef    EFI (FAT-12/16/32)
root@perfect:/#

> file -sL /dev/sdb1
>
root@perfect:/# file -sL /dev/sdb1
bash: file: command not found
root@perfect:/#


> ls -al /media/usbdisk
>
root@perfect:/# ls -al /media/usbdisk
ls: cannot access '/media/usbdisk' : No such file or directory

> mountpoint /media/usbdisk
>
root@perfect:/# mountpoint /media/usbdisk
mountpoint: /media/usbdisk : No such file or directory
root@perfect:/#

[toc] | [prev] | [next] | [standalone]

#237447

From	Brian <ad44@cityscape.co.uk>
Date	2021-07-15 20:30 +0200
Message-ID	<CBehr-xP-5@gated-at.bofh.it>
In reply to	#237445

On Thu 15 Jul 2021 at 20:01:05 +0200, Stella Ashburne wrote:

> root@perfect:/# file -sL /dev/sdb1
> bash: file: command not found
> root@perfect:/#

File is a standard utilty. It should be on your system.

 apt install file

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#237449

From	Stella Ashburne <rewefie@gmx.com>
Date	2021-07-15 20:40 +0200
Message-ID	<CBer8-Bs-5@gated-at.bofh.it>
In reply to	#237447

> Sent: Thursday, July 15, 2021 at 6:26 PM
> From: "Brian" <ad44@cityscape.co.uk>
> To: debian-user@lists.debian.org
> Subject: Re: How do I mount the USB stick containing the installer in Rescue Mode?
>
> On Thu 15 Jul 2021 at 20:01:05 +0200, Stella Ashburne wrote:
>
> > root@perfect:/# file -sL /dev/sdb1
> > bash: file: command not found
> > root@perfect:/#
>
Nope, apparently it isn't available in Rescue Mode.

Entered encryption passphrase -> Choose a device to use as root file system -> /dev/perfect-vg/root -> Execute a shell in /dev/perfect-vg/root


> File is a standard utilty. It should be on your system.

It isn't available in Rescue Mode.
>
>  apt install file
>
Unable to install now as I'm in Rescue Mode without an internet connection. The only way for me to install packages is to use the USB-installer (Debian 11) and I can't mount it.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3 [1] 2 3 Next page →

csiph-web

How do I mount the USB stick containing the installer in Rescue Mode?

Contents

#237428 — How do I mount the USB stick containing the installer in Rescue Mode?

#237429

#237431

#237433

#237434

#237440

#237441 — Re: How do I mount the USB stick containing the installer in Rescue Mode?

#237444

#237480 — Re: [Misstänkt skräppost] Re: How do I mount the USB stick containing the installer in Rescue Mode?

#237437

#237438

#237442

#237448

#237455

#237458

#237461

#237464

#237445

#237447

#237449