Accessing usb in text

[Richard Vickery]

Hi gang,

I'm stuck in a text environment. I want to save stuff in /home to a USB
drive but I forget how it is mapped / how the GUI accesses it; I know that
it is under /run, and after this I am lost.

Thanks for any help,

Richard

[Joe Zeff]

On 09/21/2013 06:17 PM, Richard Vickery wrote:
> I'm stuck in a text environment. I want to save stuff in /home to a USB
> drive but I forget how it is mapped / how the GUI accesses it; I know
> that it is under /run, and after this I am lost.

It will be in /run/media/$USER/$DEVICE where $DEVICE is the drive's 
label if you set it, or whatever the OEM set up if you haven't.  BTW, 
/run/media itself only exists when there's need for it, so looking there 
ahead of time won't work.

[Tim]

Allegedly, on or about 22 September 2013, Joe Zeff sent:
> It will be in /run/media/$USER/$DEVICE where $DEVICE is the drive's 
> label if you set it, or whatever the OEM set up if you haven't.  BTW, 
> /run/media itself only exists when there's need for it, so looking
> there ahead of time won't work.

Does automounting even work in text mode?  I thought Gnome or KDE stuck
their oars in to do automounting.

If it doesn't, one could always manually mount it.  Find out what it's
device is (e.g. dmesg|tail), then mount /dev/sdb1 /media (or mount point
of your own choice).

[Richard Vickery]

On Sep 22, 2013 5:59 PM, "Tim"  wrote:
> Allegedly, on or about 22 September 2013, Joe Zeff sent:
> > It will be in /run/media/$USER/$DEVICE where $DEVICE is the drive's
> > label if you set it, or whatever the OEM set up if you haven't.  BTW,
> > /run/media itself only exists when there's need for it, so looking
> > there ahead of time won't work.
>
> Does automounting even work in text mode?  I thought Gnome or KDE stuck
> their oars in to do automounting.
>
> If it doesn't, one could always manually mount it.  Find out what it's
> device is (e.g. dmesg|tail), then mount /dev/sdb1 /media (or mount point
> of your own choice).

Automount works well on this machine in text, but then, why would it not
work in text and work in GUI? What's the difference?

[Joe Zeff]

On 09/23/2013 04:50 PM, Richard Vickery wrote:
> Automount works well on this machine in text, but then, why would it not
> work in text and work in GUI? What's the difference?

If the DE is doing the mounting, it has to be running, even in the 
background.  Try booting, moving to a CLI and logging in there, so that 
X isn't active, and inserting a drive.  I'm sure it will be detected, 
but I don't honestly know if it will be automounted or if that only 
happens when your DE activates.

[Richard Vickery]

On Sep 24, 2013 11:27 AM, "Joe Zeff"  wrote:
> On 09/23/2013 04:50 PM, Richard Vickery wrote:
> > Automount works well on this machine in text, but then, why would it not
> > work in text and work in GUI? What's the difference?
>
> If the DE is doing the mounting, it has to be running, even in the

background.  Try booting, moving to a CLI and logging in there, so that X
isn't active, and inserting a drive.  I'm sure it will be detected, but I
don't honestly know if it will be automounted or if that only happens when
your DE activates.
> --

I can't see anything until the encription password, and after this, with an
external monitor I get X until I pass user log in. After that I have to go
back to text. I think I had access to X for a moment a few days ago, and
lost it very quickly.

I believe that I would need access to the computer's OS tomove to a CLI

[Joe Zeff]

On 09/24/2013 09:32 PM, Richard Vickery wrote:
> I believe that I would need access to the computer's OS tomove to a CLI

At boot, edit the kernel line in Grub, adding a 3 to the end.  This will 
boot you into a CLI one time.

[poma]

On 23.09.2013 02:59, Tim wrote:
> Allegedly, on or about 22 September 2013, Joe Zeff sent:
> > It will be in /run/media/$USER/$DEVICE where $DEVICE is the drive's 
> > label if you set it, or whatever the OEM set up if you haven't.  BTW, 
> > /run/media itself only exists when there's need for it, so looking
> > there ahead of time won't work.
>
> Does automounting even work in text mode?  I thought Gnome or KDE stuck
> their oars in to do automounting.

For such a thing in the background has to be some kind of the
automounter, certainly.
e.g. devmon & udisks
http://igurublog.wordpress.com/downloads/script-devmon/
> If it doesn't, one could always manually mount it.  Find out what it's
> device is (e.g. dmesg|tail), then mount /dev/sdb1 /media (or mount point
> of your own choice).

And the 'bashmount' is a quite nice tool to mount, also.
http://sourceforge.net/projects/bashmount/
http://koji.fedoraproject.org/koji/packageinfo?packageID=13272

poma

[Richard Vickery]

On Sep 25, 2013 2:44 PM, "Joe Zeff"  wrote:
> On 09/24/2013 09:32 PM, Richard Vickery wrote:
> > I believe that I would need access to the computer's OS tomove to a CLI
>
> At boot, edit the kernel line in Grub, adding a 3 to the end.  This will

boot you into a CLI one time.
> --

I forget how to edit Grub: I thought editing was in /boot/grub and tried to
vi grub.cfg finding an empty page...

[Reindl Harald]

Am 26.09.2013 05:48, schrieb Richard Vickery:
> On Sep 25, 2013 2:44 PM, "Joe Zeff" <[e-mail] > wrote:
> > On 09/24/2013 09:32 PM, Richard Vickery wrote:
> > > I believe that I would need access to the computer's OS tomove to a CLI
> >
> > At boot, edit the kernel line in Grub, adding a 3 to the end.  This will boot you into a CLI one time.
>
> I forget how to edit Grub: I thought editing was in /boot/grub and tried to vi grub.cfg finding an empty page...

besides what Joe meant was at the *boot menu* selecting the entry and press "e"
"/boot/grub" is *before* switch to GRUB2 with F17

/boot/grub2/grub.cfg

that's why "vi /boo<TAB>gr<TAB><TAB<TAB>" does auto-completion

https://www.google.at/search?q=fedora+grub+config
first hit: https://fedoraproject.org/wiki/GRUB_2

[Tim]

Allegedly, on or about 25 September 2013, Richard Vickery sent:
> I forget how to edit Grub: I thought editing was in /boot/grub and
> tried to vi grub.cfg finding an empty page...

That was the old version.  Now, the /etc/default/grub file,
and /etc/grub.d/ files are used for generating the grub config file.

But that wasn't what Joe was talking about.  Rather than edit the
configuration files, he suggested temporarily changing the options that
grub will use as it boots.  Start booting, pick a kernel to boot from,
but choose the edit rather than boot option.  Then change the kernal
commands line it'll boot from.

[Richard Vickery]

On Sep 26, 2013 9:38 PM, "Tim"  wrote:
> Allegedly, on or about 25 September 2013, Richard Vickery sent:
> > I forget how to edit Grub: I thought editing was in /boot/grub and
> > tried to vi grub.cfg finding an empty page...
>
> That was the old version.  Now, the /etc/default/grub file,
> and /etc/grub.d/ files are used for generating the grub config file.
>
> But that wasn't what Joe was talking about.  Rather than edit the
> configuration files, he suggested temporarily changing the options that
> grub will use as it boots.  Start booting, pick a kernel to boot from,
> but choose the edit rather than boot option.

/cut

I'm not at the computer, but I am sure that I don't get to see that option.
I believe the kernels to boot into comes up before the encription password.
Given this, I will give it a try when I have it.

I don't bring it with me anymore as it is hard to navigate without X. I do
like the idea as I learn to navigate in text given that it is extremely
challenging being so used to X, but it becomes rather useless since I
forget much because of disuse.

Something someone in Development ought to create is the ability to
multitask in the text environment.

Thanks for the tips,

Richard

[Tim]

Tim:
> > But that wasn't what Joe was talking about.  Rather than edit the
> > configuration files, he suggested temporarily changing the options
> > that grub will use as it boots.  Start booting, pick a kernel to boot
> > from, but choose the edit rather than boot option.

Richard Vickery:
> I'm not at the computer, but I am sure that I don't get to see that
> option.

If you have one of those dratted hidden menus, often toodling around
with the cursor keys may be enough to unhide the menu before it
automatically starts booting the default choice.  And the cursor keys
are less likely to upset other things, such as accidentally getting into
the BIOS, on those few PCs which use peculiar hotkeys for it.
> I believe the kernels to boot into comes up before the encription
> password.

Yes.  The boot partition (or bootstrapping code at the start of a
partition), isn't encrypted.  It lets you choose what you can boot from.
If the thing you choose is encrypted, that's when passwords come into
the fray.
> I don't bring it with me anymore as it is hard to navigate without X.
> I do like the idea as I learn to navigate in text given that it is
> extremely challenging being so used to X, but it becomes rather
> useless since I forget much because of disuse.

You can reacquaint yourself with the command line, while in X.  Just
open a terminal, and learn the few things that you may need to use in
text mode to get a computer back up and running.  e.g. The very basics
of VI, or make sure that you install some other editor that you prefer,
so that it's ready and waiting for the day your computer doesn't boot.
> Something someone in Development ought to create is the ability to
> multitask in the text environment.

There are things that allow it.  I'm not sure about how convenient they
are to use, though.

[Ian Malone]

On 2 October 2013 14:02, Tim  wrote:
> > Something someone in Development ought to create is the ability to
> > multitask in the text environment.
>
> There are things that allow it.  I'm not sure about how convenient they
> are to use, though.

Screen, bash job control, x windows virtual consoles.

[Rick Stevens]

On 10/02/2013 07:16 AM, Ian Malone issued this missive:
> On 2 October 2013 14:02, Tim  wrote:
> > > Something someone in Development ought to create is the ability to
> > > multitask in the text environment.
> >
> > There are things that allow it.  I'm not sure about how convenient they
> > are to use, though.
>
> Screen, bash job control, x windows virtual consoles.

Tim has it. In the text environment, multiple text consoles work 
(ALT-F1, ALT-F2, etc.), the "screen" virtual console system works, job
control works. There's lots of tools already out there if you research
it.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital    [e-mail] -
- AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
-                                                                    -
-              "Swap memory error: You lose your mind"               -
----------------------------------------------------------------------