[arch-general] community/vlock vs core/kbd vlock
Hi, I used to rely on xautolock + community/vlock for locking my X session, core/kbd however removed community/vlock in favor of its own vlock which lack the functionality I need. Besides -a -a,--all Lock all console sessions and disable VC switching. not working This tty (pts/5) is not a virtual console. The entire console display cannot be locked. I also used -n and -s -n,--new Switch to a new virtual console before locking all console sessions. -s,--disable-sysrq Disable the SysRq mechanism while consoles are locked. This option only works if the -a,--all option given. that the new vlock is lacking. Not wanting to revert to slock I reworked community/vlock into my system in a foul manner I'm not going to mention here. I've also read https://bugs.archlinux.org/task/33134 http://www.spinics.net/lists/util-linux-ng/msg07153.html https://bbs.archlinux.org/viewtopic.php?id=156308 http://forums.fedoraforum.org/archive/index.php/t-203953.html :D I'm not sure what my question should be, really, but I would like to be able to use the 2.2.3 functionality (-ans) without having an ugly hacky setup. Regards, -- Fredrik
Re: [arch-general] broken system after today upgrade
On Thu, Jan 24, 2013 at 11:32 AM, Dennis Herbrich wrote:
> On Thu, Jan 24, 2013 at 10:21:12AM +0100, arnaud gaboury wrote:
> > I was thereafter happy to log into my system, with no kernel panic !
> > I decided to reinstall all packages from the "broken" upgrade.
> >
> > Nevertheless, everything is not fine. Somme apps are broken, and do not
> > know why. I guess it is because of the /usr/lib64 issue.
> > For example, offlineimap and log are broken with no reasons, as they used
> > to work perfectly.
>
> Hello Arnaud.
>
> When you system is thought to be inconsistent, the recommended course of
> action
> is to bring it back into a well-known state. Yeah, I know, stating the
> obvious.
>
> A consistent state can be reached by reinstalling, of course, but we do not
> want to take this option. ;)
>
> Alternatively, consistency really boils down to "1) all files that are
> supposed to
> be installed must be installed, and 2) nothing should be installed that is
> not
> either part of one of the installed packages, or willfully and correctly
> installed manually by the admin."
>
> To check both, some pacman and scripting magic makes life easier:
>
> 1)
> pacman -Qk should have checked that already. A "historic" alternative was
> to
> simply explicitly reinstall all currently installed packages. Get a list
> of all
> packages with pacman -Q, munge the output, and use pacman -S to install
> each
> package again, with it's version explicitly given as "="
> to
> pacman.
>
> 2)
> All files that SHOULD be installed (through package management) can be
> listed
> by pacman -Ql|cut -d' ' -f2. Pipe this (sorted) to a file, and you've got
> your
> list to check against. Then run find on /, excluding directories like
> /home,
> /dev, /proc and /sys, and diff/comm both results to get an idea if there
> may be
> extra files on your disk where they shouldn't be. Honorable mention goes to
> rogue or missing libraries in /usr/lib, which may cause all kinds of
> annoying
> failures. The 'comm' tool is especially useful here.
>
> At the very least you should recursively check /bin, /boot, /opt, /sbin,
> /usr
> and /var for stray files, with /etc coming next. Be aware that /opt and
> /etc
> may very well include "stray files" that are supposed to be there. That's
> really something you must know and decide for yourself, though.
>
> Did I mention that pacman is awesome? Combined with the Arch Rollback
> Machine,
> it's insanely powerful and flexible. :)
>
> Good luck!
> Dennis
> --
> "Den Rechtsstaat macht aus, dass Unschuldige wieder frei kommen."
> Dr. Wolfgang Schäuble, Bundesinnenminister (14.10.08, TAZ-Interview)
>
> 0D21BE6C - F3DC D064 BB88 5162 56BE 730F 5471 3881 0D21 BE6C
>
Dennis,
thank you so much for your full and detailed explanations.
I totally agree it is a very bad idea to let a system in an inconsistent
state. It will certainly lead to huge problems in the future.
Here is what I did :
-1 #pacman -Qk -> no missing files
-2-#pacman -Qq | grep -vxFf <(pacman -Qqm) | sudo pacman -S ->
reinstall ALL packages excepted AUR
-3- #pacman -U each AUR one by one (ouf !!)
-4 run this script found in the wiki:
#!/bin/sh
tmp=${TMPDIR-/tmp}/pacman-disowned-$UID-$$
db=$tmp/db
fs=$tmp/fs
mkdir "$tmp"
trap 'rm -rf "$tmp"' EXIT
pacman -Qlq | sort -u > "$db"
find /bin /etc /lib /sbin /usr \
! -name lost+found \
\( -type d -printf '%p/\n' -o -print \) | sort > "$fs"
comm -23 "$fs" "$db"
$ pacman-disdowned > non-db.txt
Then carefully rm OR rename when in doubt all uneeded files.
My system is working not bad, but still two obvious issues:
-log files do not log anymore. Maybe not so important as $journalctl seems
our new friend.
-I use offlineimap + msmtp + mutt on a gmail accound.
[gabx@magnolia:~]$ offlineimap
OfflineIMAP 6.5.4
Licensed under the GNU GPL v2+ (v2 or any later version)
Account sync Gmail:
*** Processing account Gmail
Establishing connection to imap.gmail.com:993
Creating new Local Status db for Gmail_local:INBOX-journal
ERROR: While attempting to sync account 'Gmail'
file is encrypted or is not a database
*** Finished account 'Gmail' in 0:01
ERROR: Exceptions occurred during the run!
ERROR: While attempting to sync account 'Gmail'
file is encrypted or is not a database
I do not understand what has changed about my ~/Mail/gmail database. Is it
on my side, or gmail side? I will investigate deeper.
NOW next step is to buy a new HD, install a fresh Archlinux without testing
and dual boot. My box has changed from the "to hobby" status to "working
tool" due to a radical change in my job (from trader to developper !). I
can not any more afford break, as a lot of Java dev and a big website are
ahead.
Thank you again for your support. Once more, the open source model proved
to be efficient.
Re: [arch-general] broken system after today upgrade
On Thu, Jan 24, 2013 at 11:32:43AM +0100, Dennis Herbrich wrote: > by pacman -Ql|cut -d' ' -f2. --quiet is our friend pacman -Qlq
Re: [arch-general] [arch-dev-public] Drop VI from [core] (was Re: Winter Cleanup of [community])
On 24 January 2013 16:27, Paul Gideon Dann wrote: > On Thursday 24 Jan 2013 11:05:22 Stéphane Gaudreault wrote: > > +1 to drop vi. I cannot imagine why someone would want to use this crap > ... > > > > We already have nano in [core], so I think that vim could stay in > > [extra] (do we really need 2 text editors in [core] ?). > > Vi is the standard UNIX text-editor. Many admins rely on the fact that vi > is > available everywhere. It really should be in core. > > Also, I know you might be referring to "plain vi", which is a completely > different beast to Vim, but the latter (which provides "vi" too) has a > *huge* > userbase. Calling it crap is just bizarre... > > Paul > What about stuff like visudo? Maybe make it an optdepend or something? -- Jason Steadman
Re: [arch-general] Drop VI from [core] (was Re: Winter Cleanup of [community])
Stéphane Gaudreault wrote: > Le 2013-01-24 07:21, Allan McRae a écrit : >> On 24/01/13 22:08, Alexander Rødseth wrote: >>> === [core] === >>> >>> For [core], there are two uneeded orphans, that also aren't make >>> dependencies for any other [core] packages: >>> >>> openldap >>> vi >>> >>> If I may be so bold, maybe vim or another editor (still providing the >>> "vi" command) could take over for the vi package? >> I agree with just dumping vi and moving [vim] to core... But we can not >> put split packages across repos and gvim and deps are not going there so >> that is a no... > > Moving to another thread for clarity. > > +1 to drop vi. I cannot imagine why someone would want to use this crap > ... > > We already have nano in [core], so I think that vim could stay in > [extra] (do we really need 2 text editors in [core] ?). > FWIW this is the original discussion which brought this crippled vi upon us https://bugs.archlinux.org/task/13109 but more importantly https://bugs.archlinux.org/task/13239 Do vim and gvim really have to share the same PKGBUILD? I would be in favour of having a proper modern vim implementation in core no matter what its name would be. The only downside is that vim would need signoffs. I think that if a different PKGBUILD is used for gvim then gvim wouldn't need those as well. Greg
Re: [arch-general] [systemd] udevd and udevadm not found in initramfs when using systemd-git
On Thu, Jan 24, 2013 at 12:32:46PM -0600, William Giokas wrote: > All, > > I rebooted my computer today to test some boot flags only to be greeted > with an unbootable machine. Here is a transcript of the boot messages: > > > /init: line 9: systemd-timestamp: not found > :: running early hook [udev] > /init: line 21: udevd: not found > :: running hook [udev] > :: Triggering uevents... > /init: line 21: udevadm: not found > /init: line 21: udevadm: not found > /init: line 21: udevadm: not found > Waiting 10 seconds for device /dev/sda2... > ERROR: device '/dev/sda2' not found. Skipping fsck. > ERROR: Unable to find root device '/dev/sda2'. > > > And then I am dropped to a root shell. Attached is my mkinitcpio.conf[1]. > This only happens when using an initramfs generated with systemd-git. > I built this this image[1] using mkinitcpio 0.12.0.15.g1fb6722. I am also > using linux-mainline, but that does not seem to have any effect when > downgrading or using a different kernel. If I downgrade systemd to 197, > however, rebuild the image and reboot, it goes smoothly. Shutting down > my computer cleanly is also an impossibility, as `systemctl poweroff` > just hangs with no messages printed. This does not happen with 197. > > Also attached are the pacman -Ql outputs of my systemd-git[3] and [core]s > systemd[4], as well as the mkinitcpio -v output[5]. > > [1] http://ix.io/46o > [2] http://ompldr.org/vaDdobQ/initramfs-linux-mainline.img > [3] http://ix.io/46n > [4] http://ix.io/46m > [5] http://ix.io/46l > > Thank you, > -- > William Giokas | KaiSforza > GnuPG Key: 0xE99A7F0F > Fingerprint: F078 CFF2 45E8 1E72 6D5A 8653 CDF5 E7A5 E99A 7F0F The interpreter has moved. It has little to do with the versions of anything but glibc. If you look in /lib64 inside your image, you'll see a broken symlink. This kind of sucks.
Re: [arch-general] [arch-dev-public] Drop VI from [core] (was Re: Winter Cleanup of [community])
On Thu, Jan 24, 2013 at 11:35:29AM -0500, Dave Reisner wrote: > On Thu, Jan 24, 2013 at 11:27 AM, Paul Gideon Dann wrote: > > > On Thursday 24 Jan 2013 11:05:22 Stéphane Gaudreault wrote: > > > +1 to drop vi. I cannot imagine why someone would want to use this crap > > ... > > > > > > We already have nano in [core], so I think that vim could stay in > > > [extra] (do we really need 2 text editors in [core] ?). > > > > Vi is the standard UNIX text-editor. Many admins rely on the fact that vi > > is > > available everywhere. It really should be in core. > > > > Also, I know you might be referring to "plain vi", which is a completely > > different beast to Vim, but the latter (which provides "vi" too) has a > > *huge* > > userbase. Calling it crap is just bizarre... > > > > Paul > > > > Incorrect -- ed is the standard unix editor. > > http://www.gnu.org/fun/jokes/ed-msg.html > > More seriously, POSIX says vi is optional for us: > > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html > > Please remember that dropping it from [core] makes it in no way any less > available. > > I've no problems with moving vi as long as it doesn't disappear from the > install media. It's useful to have around long enough until you can pacman > -S vim. This does raise the question of whether we should have nano in [core] in the first place. At least vi is referenced by POSIX. -- David J. Haines djhai...@gmx.com
[arch-general] Partition/Data rescue
Hi You know the moment where you would turn back the time some seconds only? Well here we are... I got a perfectly running arch on ssd (6 partitions) and an internal hdd (1partition) with a backup usb disk (1partition) connected at a very genious moment! Having done a SD-multiboot setup with several distros I just wanted to test that the last distro added (DBAN Dariks Boot and nume) boots fine. Only little thing to mention was that --autonuke setting at boot loader. Don't ask me what was riding me, maybe tiredness, stupidness, something evil or altogether! As fast as I swiched the system off it erased at least some sectors on each and every disk! Well, DBAN worked. But how can I get back to something running? At least I would like the backup disk running but I am not sure what is the correct way. I don't have another backup and uploading to Amazon S3 was not yet finished, so disaster recovery would have worked only later How I hate Murphy today! For the procedure: Testdisk showed me at least 6 possible partitioning (having had one on this disk!) schemes and just creating the partition with fdisk and not touching the filesystem wouldn't give me my TOC back, no? Using gparted would recreate the filesystem resulting in overwritten data? Do I need to use an ext-restoring rool or what is best to try? First copying the data off to a second external disk with "dd"? And then? I would really appreciate some experienced users feedback as some of the missing data means a lot to me although knowing that there are more important things lime health etc. Thanks in advance! emak
[arch-general] [systemd] udevd and udevadm not found in initramfs when using systemd-git
All, I rebooted my computer today to test some boot flags only to be greeted with an unbootable machine. Here is a transcript of the boot messages: /init: line 9: systemd-timestamp: not found :: running early hook [udev] /init: line 21: udevd: not found :: running hook [udev] :: Triggering uevents... /init: line 21: udevadm: not found /init: line 21: udevadm: not found /init: line 21: udevadm: not found Waiting 10 seconds for device /dev/sda2... ERROR: device '/dev/sda2' not found. Skipping fsck. ERROR: Unable to find root device '/dev/sda2'. And then I am dropped to a root shell. Attached is my mkinitcpio.conf[1]. This only happens when using an initramfs generated with systemd-git. I built this this image[1] using mkinitcpio 0.12.0.15.g1fb6722. I am also using linux-mainline, but that does not seem to have any effect when downgrading or using a different kernel. If I downgrade systemd to 197, however, rebuild the image and reboot, it goes smoothly. Shutting down my computer cleanly is also an impossibility, as `systemctl poweroff` just hangs with no messages printed. This does not happen with 197. Also attached are the pacman -Ql outputs of my systemd-git[3] and [core]s systemd[4], as well as the mkinitcpio -v output[5]. [1] http://ix.io/46o [2] http://ompldr.org/vaDdobQ/initramfs-linux-mainline.img [3] http://ix.io/46n [4] http://ix.io/46m [5] http://ix.io/46l Thank you, -- William Giokas | KaiSforza GnuPG Key: 0xE99A7F0F Fingerprint: F078 CFF2 45E8 1E72 6D5A 8653 CDF5 E7A5 E99A 7F0F pgpaylReI7RIY.pgp Description: PGP signature
Re: [arch-general] broken system after today upgrade
On Thu, 24 Jan 2013 10:21:12 +0100 arnaud gaboury wrote: > On Wed, Jan 23, 2013 at 11:44 AM, Ralf Mardorf > wrote: > > > On Wed, 23 Jan 2013 11:25:16 +0100, Thomas Bächler > > wrote: > > > >> Am 23.01.2013 11:10, schrieb arnaud gaboury: > >> > >>> Let me clarify a few things. > >>> 1- I didn't correctly understand the post from Allan about toolchain, > >>> thus > >>> my brocken update when #pacman - S filesystem > >>> > >> > >> Then why do you use testing? > >> > >> 2- As a newbye, > >>> > >> > >> Then why do you use testing? > >> > > > > Perhaps the OP needs a clarification. Arch Linux is a rolling release, you > > usually get latest software versions for a regular Arch install. For my > > taste sometimes the versions come to the repository too fast (at the moment > > I take a rest from Arch Linux, but I still recommend to use it and will use > > it in the future myself again). It's not comparable to testing of "release > > distros", were for stable releases software sometimes is outdated for the > > needs of some users and developers. > > > > When you are experienced using testing is helpful, to test new packages, > > since this would help the community. As long as you're a novice, you very > > unlikely will benefit from using testing. > > > > pacman -Syuu ;) > > > > Regards, > > Ralf > > > > Thank you Ralf, but this is my first ever serious issue when upgrading, so > I will stick with dev enabled. > > Following Allan instructions, on Archiso, I #pacman -Qk and no missing > files were returns. > Then #mkinitcpio -p linux > > I was thereafter happy to log into my system, with no kernel panic ! > I decided to reinstall all packages from the "broken" upgrade. > > Nevertheless, everything is not fine. Somme apps are broken, and do not > know why. I guess it is because of the /usr/lib64 issue. > For example, offlineimap and log are broken with no reasons, as they used > to work perfectly. There is always a reason... but it's not /usr/lib64. > > Allan, I think this upgrade is worth a news, as you mentioned it this > morning. > > I am always scare each time I run #pacman -Syu, as I know it could be > tricky. I usually pay very much attention, and this particular upgrade was > my first real issue leaving me with a broken system. > I may think breaking/fixing our system is the only way we learn. > > Thank you for your great work to the Arch community. > > Regards. -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] [arch-dev-public] Drop VI from [core] (was Re: Winter Cleanup of [community])
On Thu, Jan 24, 2013 at 11:27 AM, Paul Gideon Dann wrote: > On Thursday 24 Jan 2013 11:05:22 Stéphane Gaudreault wrote: > > +1 to drop vi. I cannot imagine why someone would want to use this crap > ... > > > > We already have nano in [core], so I think that vim could stay in > > [extra] (do we really need 2 text editors in [core] ?). > > Vi is the standard UNIX text-editor. Many admins rely on the fact that vi > is > available everywhere. It really should be in core. > > Also, I know you might be referring to "plain vi", which is a completely > different beast to Vim, but the latter (which provides "vi" too) has a > *huge* > userbase. Calling it crap is just bizarre... > > Paul > Incorrect -- ed is the standard unix editor. http://www.gnu.org/fun/jokes/ed-msg.html More seriously, POSIX says vi is optional for us: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html Please remember that dropping it from [core] makes it in no way any less available. I've no problems with moving vi as long as it doesn't disappear from the install media. It's useful to have around long enough until you can pacman -S vim.
Re: [arch-general] [arch-dev-public] Drop VI from [core] (was Re: Winter Cleanup of [community])
On Thursday 24 Jan 2013 11:05:22 Stéphane Gaudreault wrote: > +1 to drop vi. I cannot imagine why someone would want to use this crap ... > > We already have nano in [core], so I think that vim could stay in > [extra] (do we really need 2 text editors in [core] ?). Vi is the standard UNIX text-editor. Many admins rely on the fact that vi is available everywhere. It really should be in core. Also, I know you might be referring to "plain vi", which is a completely different beast to Vim, but the latter (which provides "vi" too) has a *huge* userbase. Calling it crap is just bizarre... Paul
Re: [arch-general] broken system after today upgrade
Accidentally sent this too soon; keyboard-shortcut-fail! On Thursday 24 Jan 2013 10:37:55 you wrote: > I'm pretty confident I could tackle breakage, but I still avoid [testing] > because I use my system for work, and troubleshooting these problems will > usually take time that I can't justify. Breakage in the stable repositories > is pretty rare, but manual intervention is required often enough that you > gradually build skills and understanding, so you don't miss out on the > learning experience. It sounds to me like it would be best for you to > avoid [testing] until you feel more confident ... in your understanding of the Archlinux tools and the system as a whole. It certainly doesn't mean you're missing out or not as 1337 or anything like that. > > Paul
Re: [arch-general] broken system after today upgrade
On Thursday 24 Jan 2013 10:21:12 arnaud gaboury wrote: > I am always scare each time I run #pacman -Syu, as I know it could be > tricky. I usually pay very much attention, and this particular upgrade was > my first real issue leaving me with a broken system. > I may think breaking/fixing our system is the only way we learn. I'm pretty confident I could tackle breakage, but I still avoid [testing] because I use my system for work, and troubleshooting these problems will usually take time that I can't justify. Breakage in the stable repositories is pretty rare, but manual intervention is required often enough that you gradually build skills and understanding, so you don't miss out on the learning experience. It sounds to me like it would be best for you to avoid [testing] until you feel more confident Paul
Re: [arch-general] broken system after today upgrade
On Thu, Jan 24, 2013 at 10:21:12AM +0100, arnaud gaboury wrote: > I was thereafter happy to log into my system, with no kernel panic ! > I decided to reinstall all packages from the "broken" upgrade. > > Nevertheless, everything is not fine. Somme apps are broken, and do not > know why. I guess it is because of the /usr/lib64 issue. > For example, offlineimap and log are broken with no reasons, as they used > to work perfectly. Hello Arnaud. When you system is thought to be inconsistent, the recommended course of action is to bring it back into a well-known state. Yeah, I know, stating the obvious. A consistent state can be reached by reinstalling, of course, but we do not want to take this option. ;) Alternatively, consistency really boils down to "1) all files that are supposed to be installed must be installed, and 2) nothing should be installed that is not either part of one of the installed packages, or willfully and correctly installed manually by the admin." To check both, some pacman and scripting magic makes life easier: 1) pacman -Qk should have checked that already. A "historic" alternative was to simply explicitly reinstall all currently installed packages. Get a list of all packages with pacman -Q, munge the output, and use pacman -S to install each package again, with it's version explicitly given as "=" to pacman. 2) All files that SHOULD be installed (through package management) can be listed by pacman -Ql|cut -d' ' -f2. Pipe this (sorted) to a file, and you've got your list to check against. Then run find on /, excluding directories like /home, /dev, /proc and /sys, and diff/comm both results to get an idea if there may be extra files on your disk where they shouldn't be. Honorable mention goes to rogue or missing libraries in /usr/lib, which may cause all kinds of annoying failures. The 'comm' tool is especially useful here. At the very least you should recursively check /bin, /boot, /opt, /sbin, /usr and /var for stray files, with /etc coming next. Be aware that /opt and /etc may very well include "stray files" that are supposed to be there. That's really something you must know and decide for yourself, though. Did I mention that pacman is awesome? Combined with the Arch Rollback Machine, it's insanely powerful and flexible. :) Good luck! Dennis -- "Den Rechtsstaat macht aus, dass Unschuldige wieder frei kommen." Dr. Wolfgang Schäuble, Bundesinnenminister (14.10.08, TAZ-Interview) 0D21BE6C - F3DC D064 BB88 5162 56BE 730F 5471 3881 0D21 BE6C
Re: [arch-general] broken system after today upgrade
On Wed, Jan 23, 2013 at 11:44 AM, Ralf Mardorf wrote: > On Wed, 23 Jan 2013 11:25:16 +0100, Thomas Bächler > wrote: > >> Am 23.01.2013 11:10, schrieb arnaud gaboury: >> >>> Let me clarify a few things. >>> 1- I didn't correctly understand the post from Allan about toolchain, >>> thus >>> my brocken update when #pacman - S filesystem >>> >> >> Then why do you use testing? >> >> 2- As a newbye, >>> >> >> Then why do you use testing? >> > > Perhaps the OP needs a clarification. Arch Linux is a rolling release, you > usually get latest software versions for a regular Arch install. For my > taste sometimes the versions come to the repository too fast (at the moment > I take a rest from Arch Linux, but I still recommend to use it and will use > it in the future myself again). It's not comparable to testing of "release > distros", were for stable releases software sometimes is outdated for the > needs of some users and developers. > > When you are experienced using testing is helpful, to test new packages, > since this would help the community. As long as you're a novice, you very > unlikely will benefit from using testing. > > pacman -Syuu ;) > > Regards, > Ralf > Thank you Ralf, but this is my first ever serious issue when upgrading, so I will stick with dev enabled. Following Allan instructions, on Archiso, I #pacman -Qk and no missing files were returns. Then #mkinitcpio -p linux I was thereafter happy to log into my system, with no kernel panic ! I decided to reinstall all packages from the "broken" upgrade. Nevertheless, everything is not fine. Somme apps are broken, and do not know why. I guess it is because of the /usr/lib64 issue. For example, offlineimap and log are broken with no reasons, as they used to work perfectly. Allan, I think this upgrade is worth a news, as you mentioned it this morning. I am always scare each time I run #pacman -Syu, as I know it could be tricky. I usually pay very much attention, and this particular upgrade was my first real issue leaving me with a broken system. I may think breaking/fixing our system is the only way we learn. Thank you for your great work to the Arch community. Regards.
Re: [arch-general] failed to set xfermode on multiple disks SOLVED
On Tue, Jan 22, 2013 at 2:50 PM, Jameson wrote: > On Mon, Jan 21, 2013 at 6:11 PM, Jameson wrote: >> On Mon, Jan 21, 2013 at 12:38 AM, Martín Cigorraga wrote: >>> On Mon, Jan 21, 2013 at 12:33 AM, Jameson wrote: >>> I hope someone can help me. I have a server with two SSDs that contain a mirrored btrfs volume holding /, and multiple HDDs that are in a btrfs RAID10 array. I updated to linux 3.7.3 in testing, and it failed to boot. I booted from a USB drive, and reinstalled 3.6.?, and I still get failed to set xfermode (err_mask=0x40). I don't see anything in dmesg that makes a difference. The only thing that changed was the kernels, back and forth. Does anyone have an idea, or am I going to have to re-install? Thanks. >>> >>> Hi Jameson, a blind shot here since I'm not familiar yet with SSD setups: >>> did you tried running a fsck? In the past I had a similar situation with >>> conventional hard disks and the problem was some corrupted data in /boot. >>> >>> Hope you have your beast up soon! >> >> Yes. I had actually forgotten that I had a separate ext4 boot >> partition. I've ran fsck on it as well as btrfsck on my mirrored >> root, and my raid10 array. All return fine. During boot, between >> some of the xfermode errors, I can see the message where it is looking >> for btrfs file systems, and then a repair console which says that the >> root filesystem can't be found which doesn't respond for some reason. >> I'll try to find another keyboard to see if it will make a difference. >> I did another install of of the old 3.6 kernel, and noticed that it >> threw an error about not being able to find the root filesystem at >> that point also. Any further diagnostic advice will be appreciated. > > Also, it turns out changing USB keyboards makes no difference. I > don't think I have a PS/2 keyboard, anymore. I've currently copied > all of my data from my SSD array to a HDD, and plan on trying to get > it to boot. I've successfully ran mkinitcpio and grub-mkconfig from a > chroot on the HDD which did not return the error about not finding the > root filesystem, so I'm hopeful it will at least get me back up and > running. I forgot to grub-install, though, so I'll have to wait until > I get home to test it. In case anyone else runs into this, I needed to patch the kernel with the patch provided in this bug: https://bugzilla.kernel.org/show_bug.cgi?id=51881
