Boot openSuse from flash drive? Also, bug report.

I would like to do the following, don’t know if it is possible, but I’ve got at least part way there (this is with openSuse 11.3 for 64-bit machines). I just wanted to post about this and report the bug before I forget it. I will do some digging around afterward to see if someone has posted about a similar situation.

I want to be able to carry my OS and data around on an encrypted flash drive, to plug into any computer and boot it and use it (ideally). I realize many computers won’t be able to handle USB boot devices so a boot CD to get the process going is acceptable. I now am able to boot on my laptop with the help of a cd with grub on it.

Question 1: Is openSuse on a flash drive viable? I have been running Puppy Linux; when that is installed on a flash drive the OS only writes back to the drive once in 30 minutes so not to wear the drive out with excessive writes. Is there any such consideration when Suse is on a flash drive? I have disabled swap as one way to cut down on writes; I realize the drawbacks of this.

Question 2: I tried booting my setup on my wife’s computer. It works just fine on my laptop but on her machine the display was just black. I wonder if there is any kind of concept in Suse of different computer profiles that can handle different display hardware, wireless, etc, and recognize a particular system when it boots? Or some other way to handle this?

Now for the bug report. I installed on an 8GB flash drive with a small /boot partition and everything else in an encrypted lvm volume group.

Question 3: When one encrypts the volume group, everything within it is automatically encrypted, right? I noticed the partitioner had the option to encrypt devices within an already encrypted volume group, but my guess is this makes no sense, unless I enjoy typing passwords in!

When I went through the partitioner, I went for a smaller /boot partition than standard, 47MB, although not so small as it allowed. However, when I later started the software updater, there were a couple of items to update the kernel. When those were being installed, I ran out of room on /boot! And not only that, it left my system in an unbootable state, as I discovered when I tried to reboot. I was unable to recover from this by fixing /boot, so I resorted to a full dd backup that I had saved just before starting this process (thank heaven!), and that worked OK. The error message I got on reboot was:
[1.238329]Kernel panic - not syncing: VFS: Unable to mount root fs on unknown - block(0,0)

The problem of course was using /boot for storing downloaded kernel update files. These should be stored in /tmp or somewhere like that, and then when the update is completed, the updated kernel should only then be copied over the old one on /boot, so you don’t run out of room there. There should also be some way to restore the previous condition if there is an error in the process.

I now have to figure out how to get this update done with my 47MB /boot. There is no way to enlarge it since the rest of the flash drive is filled with the lvm volume group. I may be able to temporarily get the grub stuff out of there while the update happens.

Question 4: Are there any other non-crucial files that can be moved out of /boot during this kernel update?

Oh, here is fdisk -l if you want to see it:

Disk /dev/sda: 8011 MB, 8011120640 bytes
247 heads, 62 sectors/track, 1021 cylinders
Units = cylinders of 15314 * 512 = 7840768 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xe623bab3

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1           6       40162   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2               6        1022     7781376   8e  Linux LVM
Partition 2 does not end on cylinder boundary.

That is funny, I thought Partitioner reported sda1 was 47MB, but here it looks like 40MB. It shouldn’t have made that small a partition? (It was partitioned by Partitioner).

<later> I just checked again and now it reports 39MB. Not sure what is going on here…

Just to throw in some bits and pieces.

Seeing this is your first post here: Welcome to these Forums.

The amount of space used within my /boot directory (I do not have it as a seperate filesystem, but that does not matter of course) is about 26 MB. I have two kernels there. Normaly you only have one kernel and thus installing a second kernel temporary alongside it should be possble imho with 47 MB.

You can discuss things here you think are worth a bug report. This discussion may then lead to you either finding that it is no bug after all, or that it is not only you that see it as a bug, but you have support in that idea. Then when you wantt to file the bug, you should go to openSUSE:Submitting bug reports - openSUSE. The members of these Forums are just users like you and not openSUSE developers.

Thanks Henk, that’s what I figured - that we’d have to chew it over to see if it really is a bug.

My software update lists two fixes for the kernel, Kernel-3038 and Kernel-3315, both 42.6MB. It is possible they were both being processed at the same time, or downloads overlapped, I suppose.

As to kernel size, my memory is not that reliable, so I’ll just assume I asked for it that size. As you say, 40MB should be sufficient.


I must add that I have a 32-bit system here, but I would think it a strange coincidence if a 64-bit kerenl would be twice as big. :stuck_out_tongue:

You’re looking at the size of the kernel packages, Henk is talking about the size of the kernel-image in /boot

glosscomputer@Knurpht:/boot> ls -lh
totaal 30M
-rw------- 1 root root  512 jun 30 21:32 backup_mbr
lrwxrwxrwx 1 root root    1 jul 12 12:28 boot -> .
-rw-r--r-- 1 root root 1,3K sep 30 02:41 boot.readme
-rw-r--r-- 1 root root 109K okt  8 11:19 config-
drwxr-xr-x 2 root root 4,0K okt 19 16:10 grub
lrwxrwxrwx 1 root root   27 okt 16 12:59 initrd -> initrd-
-rw-r--r-- 1 root root 8,3M okt 16 12:59 initrd-
-rw-r--r-- 1 root root 415K jul 12 12:22 message
-rw-r--r-- 1 root root 182K okt  8 11:10 symsets-
-rw-r--r-- 1 root root 180K okt  8 11:33 symsets-
-rw-r--r-- 1 root root 179K okt  8 11:21 symsets-
-rw-r--r-- 1 root root 519K okt  8 11:09 symtypes-
-rw-r--r-- 1 root root 516K okt  8 11:32 symtypes-
-rw-r--r-- 1 root root 508K okt  8 11:20 symtypes-
-rw-r--r-- 1 root root 184K okt  8 11:21 symvers-
-rw-r--r-- 1 root root 2,0M okt  8 11:06
-rw-r--r-- 1 root root 4,4M okt  8 11:03 vmlinux-
-rw-r--r-- 1 root root 4,6M okt  8 11:19 vmlinux-
-rw-r--r-- 1 root root 4,0M okt  8 11:12 vmlinux-
lrwxrwxrwx 1 root root   28 okt 16 12:59 vmlinuz -> vmlinuz-
-rw-r--r-- 1 root root 4,0M okt  8 11:06 vmlinuz-



glosscomputer@Knurpht:/boot> du -h
388K    ./grub
31M     .

glosscomputer@Knurpht:/boot> du -h
388K ./grub
31M .

See, there’s only 31 MB in /boot on a default 64bit install.

My du shows 21MB (I don’t have those default.gz things you have) but at the time it choked there were two of everything, part of the kernel patch process I guess. And don’t forget there are two kernel patches coming out. Anyway, what’s the point of going on about this? 40MB was too small for the update; that I know. The error message said it ran out of room. Doing a df showed 100% usage of /boot.

Anyone want to take a try at answering the 4 questions in my original post?