FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 08-19-2011, 11:50 AM
"tv.debian@googlemail.com"
 
Default UUID updates for dmcrypt/luks

Le 19/08/2011 11:24, Christian Jaeger a écrit :
> Hi
>
> I've used the Debian installer (Sarge) for installing a system onto an
> SSD, using this layout:
>
> /dev/sda1 /boot
> /dev/sda5 luks, -> sda5_crypt with "/"
> /dev/sda6 /usr
>
> After the installation finished, I realized that I should have aligned
> the partition boundaries. So I booted into GRML, backed up the file
> systems with tar, created a new partition table + filesystems
> manually, mounted, extracted the tars. Mounted in correct nesting plus
> /proc /sys /dev and chroot'ed inside, "grub-setup -d /boot/grub
> /dev/sda".
>
> Now, the difficult part is figuring out all the locations where the
> system is using UUIDs (d'oh!), and maybe other information that has
> changed by me recreating the partition table.
>
> I've updated /etc/fstab and /etc/crypttab and ran update-grub from
> within the chroot (while running GRML).
[cut]

Hi, maybe you should have updated the initramfs too (update-initramfs).
But from the beginning you could have reverted the newly created
partitions uuid's to the old ones, for instance with "tune2fs -U
old_uuid /new/partition", this way no need to modify fstab, grub,
initramfs and whatnot.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4E4E4E13.4090706@googlemail.com">http://lists.debian.org/4E4E4E13.4090706@googlemail.com
 
Old 08-19-2011, 03:36 PM
Christian Jaeger
 
Default UUID updates for dmcrypt/luks

2011/8/19 tv.debian@googlemail.com <tv.debian@googlemail.com>:
> Hi, maybe you should have updated the initramfs too (update-initramfs).

I've done that, too, just forgot to mention it. So there's still some
other problem.

Well, found the problem now:

I've been using "file -s /dev/XXX" to get the UUID. But that truncates
the UUID (in cases where output would exceed n characters?). *Sigh*.
Works now.

> But from the beginning you could have reverted the newly created
> partitions uuid's to the old ones, for instance with "tune2fs -U
> old_uuid /new/partition", this way no need to modify fstab, grub,
> initramfs and whatnot.

Ah, thanks; good to know for next time (if I'll remember; I've started
using Linux long before uuids were being used, so my brain is wired
the old way where my doing would have worked without issue; note to
self: need to change wiring).

Christian.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAEjYwfUzazBSdkYKCOAVnLpF8iBGDoXcARk2Tw0dyZhnqOsT5 A@mail.gmail.com">http://lists.debian.org/CAEjYwfUzazBSdkYKCOAVnLpF8iBGDoXcARk2Tw0dyZhnqOsT5 A@mail.gmail.com
 
Old 08-19-2011, 04:16 PM
Christian Jaeger
 
Default UUID updates for dmcrypt/luks

PS. some random observations from my time spent with the above:

- busybox (which is used in initrd) *does* respect "set -x", but
(unlike bash) it does *not* pass it on to subshells. Could that be
fixed?

- because of this, you need to first add "set -x" just to ./init in
the initrd, then you see the last script that ran, then add "set -x"
to that script, too. Needless to say that since each change requires a
reboot into GRML (and opening crypt loops and filesystems) each time,
that's time intensive.

- the "debug" kernel option (mentioned in some of the manpages related
to initrd, advertised as creating a file in the dev tmpfs) actually
increases kernel verbosity to the console, too (to the point of
loosing the set -x messages, so I had to boot without "debug")

- actually I seem to have been wrong about the initrd hanging
'indefinitely' and ctl-c getting me to a shell: ctl-c does not work,
but seems in both cases I booted I just waited +- exactly as long as
to time out, which is about 5 minutes. (In older installations (when
Sarge was sid) the timeout was shorter somehow.) Why doesn't ctl-c
stop the wait? Could that be fixed, please?

It would be awesome if the first and last of these things could be
improved. Maybe I should file bug reports.

Christian.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAEjYwfXJ01qiw-JJnkrN=PWvPh5uoHOcL=Yv4jhrFsVZNmGb9w@mail.gmail.co m">http://lists.debian.org/CAEjYwfXJ01qiw-JJnkrN=PWvPh5uoHOcL=Yv4jhrFsVZNmGb9w@mail.gmail.co m
 

Thread Tools




All times are GMT. The time now is 12:16 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org