Difference between revisions of "Talk:Installing Arch Linux on a USB key"

From ArchWiki
Jump to: navigation, search
m
(Before creating the initial RAM disk (mkinitcpio))
 
(18 intermediate revisions by 6 users not shown)
Line 1: Line 1:
Just a note that I'm hesitant to add to the main page, but probably should be there: the media name must match its expected name (something like ARCH_YEARMN, i.e., ARCH_201207 with a current image). Took me a bit to figure out why mine wasn't working, it did the "waiting 30 seconds" thing, couldn't find the volume, and dropped to emergency shell. --[[User:Mathwizard1232|Mathwizard1232]] ([[User talk:Mathwizard1232|talk]]) 16:43, 23 July 2012 (UTC)
+
== Before creating the initial RAM disk (mkinitcpio) ==
  
Oh, and source for the above: https://bbs.archlinux.org/viewtopic.php?id=144246 . Good thing I looked it up, my first post had the wrong format...changed above. --[[User:Mathwizard1232|Mathwizard1232]] ([[User talk:Mathwizard1232|talk]]) 01:59, 24 July 2012 (UTC)
+
The correct custom configuration of the initial RAM disk is a step that very few users of arch need to do so is a thing that needs to be highlighted for this use case. Also the placement of this information in Installation tweaks makes it appear that is optional so i think that it will be better if the information is moved to configuration.
 +
 
 +
[[User:Monty programador|Monty programador]] ([[User talk:Monty programador|talk]]) 22:15, 22 November 2017 (UTC)
 +
 
 +
== I/O errors ==
 +
 
 +
I am experiencing serius I/O errors after suspending / resuming with arch on a usb key. These issues have been described in several bugreports:
 +
https://bugzilla.kernel.org/show_bug.cgi?id=30912
 +
 
 +
I tried following the steps in
 +
https://www.kernel.org/doc/Documentation/usb/persist.txt
 +
 
 +
but to no avail. The usb persist feature was already activated on my USB deve but I/O errors kept coming on resume
 +
 
 +
I also found this post in ubuntuforums
 +
 
 +
http://askubuntu.com/questions/505779/suspending-with-root-on-usb
 +
 
 +
which explains the issue as follows
 +
 
 +
"...during resume there will be a race between the USB system on one hand trying to detect media and syslog on the other hand trying to write log messages from suspend and resume to disk.
 +
 
 +
If syslog happens to attempt a write before the USB device has been detected ext4 gets an error, which for some reason isn't handled cleanly and eventually the file system will need fsck to be run manually."
 +
 
 +
The author suggest patching the kernel to give kernel threads a head start on resume. Intuitively, I feel there must be an easier way!
 +
 
 +
{{unsigned|20:37, 30 November 2015‎|A1runa}}

Latest revision as of 22:15, 22 November 2017

Before creating the initial RAM disk (mkinitcpio)

The correct custom configuration of the initial RAM disk is a step that very few users of arch need to do so is a thing that needs to be highlighted for this use case. Also the placement of this information in Installation tweaks makes it appear that is optional so i think that it will be better if the information is moved to configuration.

Monty programador (talk) 22:15, 22 November 2017 (UTC)

I/O errors

I am experiencing serius I/O errors after suspending / resuming with arch on a usb key. These issues have been described in several bugreports: https://bugzilla.kernel.org/show_bug.cgi?id=30912

I tried following the steps in https://www.kernel.org/doc/Documentation/usb/persist.txt

but to no avail. The usb persist feature was already activated on my USB deve but I/O errors kept coming on resume

I also found this post in ubuntuforums

http://askubuntu.com/questions/505779/suspending-with-root-on-usb

which explains the issue as follows

"...during resume there will be a race between the USB system on one hand trying to detect media and syslog on the other hand trying to write log messages from suspend and resume to disk.

If syslog happens to attempt a write before the USB device has been detected ext4 gets an error, which for some reason isn't handled cleanly and eventually the file system will need fsck to be run manually."

The author suggest patching the kernel to give kernel threads a head start on resume. Intuitively, I feel there must be an easier way!

—This unsigned comment is by A1runa (talk) 20:37, 30 November 2015‎. Please sign your posts with ~~~~!