On Fri 16 Jul 2021 at 07:31:41 (-0400), Greg Wooledge wrote: > On Thu, Jul 15, 2021 at 11:43:15PM -0500, David Wright wrote: > > I presume you type /etc/fstab into your post, both because of the > > missing # for the comment, and because the /dev/sr0 line has too > > many fields. It should contain udf,iso9660 user,noauto > > without spaces after the commas. > > The space between iso9660 and user should *also* be a comma.
Eh? Attached is the virgin fstab from my experimental encrypted root installation. I think it's self-evident why there's a space separating the two alternative filesystem types from the mount options. > The > original post was a mess, and I agree, she probably typed it by > hand (with multiple errors -- *all* of the comments were missing their > pound signs, for instance, not just the one you mentioned). Yes, should have pointed it out. At first reading, I assumed they'd missed the first character when dragging the mouse, but on rereading, I saw the other errors, and corrected only those. Of course, there'd be no mouse pointer to drag in Rescue, so you really can only transcribe or photograph the text. > Anyway, this thread has gone on for a ridiculously long time. She > just needs to identify the correct device name, and create a new > directory in which to mount it. AIUI the device /dev/sdb1 is already mounted. However, by selecting "execute shell in /d/m/sda-whatsit", the /cdrom mountpoint gets hidden in the Alt-F1 shell. > It's sad that people always somehow think they need to use existing > directories for their mount points. You can just "mkdir /stella" and > use that, and voila -- no conflicts. It's an ephemeral system, so you > aren't even "polluting" a "pristine" root file system with your new > directory. It's all temporary. Been there, done that. Strictly, the answer to the Subject line is: "You don't. It's already mounted. It's on /cdrom." Unfortunately, the other two shells weren't obvious to the OP (or, perhaps, to anyone else who replied). Taking a step back, I would have wished that the OP could have booted the installed system and fixed Grub from there, and never opened this new topic at all. Having taken this step back, I see that it hasn't been mentioned that one of the menu alternatives to "execute shell in /d/m/sda-whatsit" is "Reinstall Grub". I'm not inclined to go there, as I've been learning about this Rescue business on a system with a perfectly good Grub installation that I'm happy to copy bits out of but not change. Taking two steps back, and looking at the thread "How do I get back the GRUB menu with the blue background?", I'm at a loss to know why nobody else has posted what the Grub commands are to boot a system with encrypted root *and* LVM. (Actually I think it's an encrypted partition with LVM inside it.) I've posted how to boot a system with an encrypted root filesystem using raw Grub commands so they can fix up Grub, but I can't help with their LVM, never having used it. So many people here say, "Use LVM", "You should be using LVM", "LVM should be the mainstream default". And yet, no replies are forthcoming. Cheers, David.
# /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # systemd generates mount units based on this file, see systemd.mount(5). # Please run 'systemctl daemon-reload' after making changes here. # # <file system> <mount point> <type> <options> <dump> <pass> /dev/mapper/sda5_crypt / ext4 errors=remount-ro 0 1 # /boot was on /dev/sda2 during installation UUID=700b607c-ffa6-4435-a4b6-10894928c764 /boot ext2 defaults 0 2 /dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0